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.
I'm not entirely convinced yet that there *isn't* 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. Louis Wasserman wasserman.lo...@gmail.com On Sun, Feb 15, 2009 at 9:20 PM, Dan Doel <dan.d...@gmail.com> wrote: > On Sunday 15 February 2009 9:44:42 pm Louis Wasserman wrote: > > Hello all, > > > > I just uploaded stateful-mtl and pqueue-mtl 1.0.1. The ST monad > > transformer and array transformer have been removed -- I've convinced > > myself that a heap transformer backed by an ST array cannot be > > referentially transparent -- and the heap monad is now available only as > a > > basic monad and not a transformer, though it still provides priority > queue > > functionality to any of the mtl wrappers around it. stateful-mtl retains > a > > MonadST typeclass which is implemented by ST and monad transformers > around > > it, allowing computations in the the ST-bound heap monad to perform ST > > operations in its thread. > > > > Since this discussion had largely led to the conclusion that ST can only > be > > used as a bottom-level monad, it would be pretty uncool if ST > computations > > couldn't be performed in a monad using ST internally because the ST > thread > > was hidden and there was no way to place ST computations 'under' the > outer > > monad. Anyway, it's essentially just like the MonadIO typeclass, except > > with a functional dependency on the state type. > > > > There was a question I asked that never got answered, and I'm still > > curious: would an ST *arrow* transformer be valid? Arrows impose > > sequencing on their operations that monads don't... I'm going to test > out > > some ideas, I think. > > Your proposed type: > > State (Kleisli []) x y = (s, x) -> [(s, y)] > > is (roughly) isomorphic to: > > x -> StateT s [] y = x -> s -> [(s, y)] > > The problem with an ST transformer is that the state parameter needs to be > used linearly, because that's the only condition under which the > optimization > of mutable update is safe. ST ensures this by construction, as opposed to > other languages (Clean) that have type systems that can express this kind > of > constraint directly. However, with STT, whether the state parameter is used > linearly is a function of the wrapped monad. You'd have to give a more > fleshed > out version of your proposed state arrow transformer, but off the top of my > head, I'm not sure it'd be any better. > > -- Dan >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
