<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.3492" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=529163408-16022009><FONT face=Arial
color=#800000 size=2>Well, I think a type system like Clean's that had
linear/uniqueness types could "fix" the issue by actually checking that the
state is single-threaded (and thus stop you from applying it to a "forking"
monad). But there's a fundamental operational problem that ST makes destructive
updates, so to support it as a monad transformer in general you'd need a type
system that actually introduced fork operations (which "linear implicit
parameters" used to do in GHC , but they were removed because they were quite
complicated semantically and noone really used them).</FONT></SPAN></DIV><BR>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> haskell-cafe-bounces@haskell.org
[mailto:haskell-cafe-bounces@haskell.org] <B>On Behalf Of </B>Louis
Wasserman<BR><B>Sent:</B> 16 February 2009 03:31<BR><B>To:</B> Dan
Doel<BR><B>Cc:</B> Henning Thielemann;
haskell-cafe@haskell.org<BR><B>Subject:</B> Re: [Haskell-cafe] ANNOUNCE:
pqueue-mtl, stateful-mtl<BR></FONT><BR></DIV>
<DIV></DIV>Okay, I tested it out and the arrow transformer has the same
problem. I realized this after I sent the last message -- the point is
that at any particular point, intuitively there should be exactly one copy of a
State# s for each state thread, and it should never get duplicated; allowing
other monads or arrows to hold a State# s in any form allows them to hold more
than one, violating that goal.<BR><BR>I'm not entirely convinced yet that there
<I>isn't</I> some really gorgeous type system magic to fix this issue, like the
type-system magic that motivates the type of runST in the first place, but
that's not an argument that such magic exists...it's certainly an interesting
topic to mull.<BR><BR clear=all>Louis Wasserman<BR><A
href="mailto:wasserman.louis@gmail.com">wasserman.louis@gmail.com</A><BR><BR><BR>
<DIV class=gmail_quote>On Sun, Feb 15, 2009 at 9:20 PM, Dan Doel <SPAN
dir=ltr><<A
href="mailto:dan.doel@gmail.com">dan.doel@gmail.com</A>></SPAN> wrote:<BR>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">
<DIV class=Ih2E3d>On Sunday 15 February 2009 9:44:42 pm Louis Wasserman
wrote:<BR>> Hello all,<BR>><BR>> I just uploaded stateful-mtl and
pqueue-mtl 1.0.1. The ST monad<BR>> transformer and array transformer
have been removed -- I've convinced<BR>> myself that a heap transformer
backed by an ST array cannot be<BR>> referentially transparent -- and the
heap monad is now available only as a<BR>> basic monad and not a
transformer, though it still provides priority queue<BR>> functionality to
any of the mtl wrappers around it. stateful-mtl retains a<BR>>
MonadST typeclass which is implemented by ST and monad transformers
around<BR>> it, allowing computations in the the ST-bound heap monad to
perform ST<BR>> operations in its thread.<BR>><BR>> Since this
discussion had largely led to the conclusion that ST can only be<BR>> used
as a bottom-level monad, it would be pretty uncool if ST computations<BR>>
couldn't be performed in a monad using ST internally because the ST
thread<BR>> was hidden and there was no way to place ST computations
'under' the outer<BR>> monad. Anyway, it's essentially just like the
MonadIO typeclass, except<BR>> with a functional dependency on the state
type.<BR>><BR>> There was a question I asked that never got answered,
and I'm still<BR>> curious: would an ST *arrow* transformer be valid?
Arrows impose<BR>> sequencing on their operations that monads
don't... I'm going to test out<BR>> some ideas, I
think.<BR><BR></DIV>Your proposed type:<BR><BR> State (Kleisli []) x y =
(s, x) -> [(s, y)]<BR><BR>is (roughly) isomorphic to:<BR><BR> x ->
StateT s [] y = x -> s -> [(s, y)]<BR><BR>The problem with an ST
transformer is that the state parameter needs to be<BR>used linearly, because
that's the only condition under which the optimization<BR>of mutable update is
safe. ST ensures this by construction, as opposed to<BR>other languages
(Clean) that have type systems that can express this kind of<BR>constraint
directly. However, with STT, whether the state parameter is used<BR>linearly
is a function of the wrapped monad. You'd have to give a more fleshed<BR>out
version of your proposed state arrow transformer, but off the top of
my<BR>head, I'm not sure it'd be any better.<BR><FONT color=#888888><BR>--
Dan<BR></FONT></BLOCKQUOTE></DIV><BR>
<P><pre wrap>==============================================================================
Please access the attached hyperlink for an important electronic communications disclaimer:
http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==============================================================================
</pre></P></BODY></HTML>