On Fri, 20 Feb 2009, Louis Wasserman wrote:
Hmmm. That's probably a better framework to draw on for the general array
interface.
For a list of all such low-level arrays, see:
http://www.haskell.org/haskellwiki/Storable_Vector
StorableVectors can also be manipulated in ST
Yeah, I totally forgot about arrays.
But if you're interested in pure computations that use arrays for
intermediate results, maybe uvector[1] is what you are looking for
instead?
-- ryan
[1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/uvector
On Thu, Feb 19, 2009 at 2:14 PM,
Hmmm. That's probably a better framework to draw on for the general array
interface.
The real goal, though, was to be able to abstract out the array usage:
specifically: stateful-mtl provided MonadST and then an ArrayT that drew on
the state thread from a MonadST to hold its own STArray (which I
Henning Thielemann wrote:
On Mon, 16 Feb 2009, Louis Wasserman wrote:
Overnight I had the following thought, which I think could work
rather well. The most basic implementation of the idea is as
follows:
class MonadST s m | m - s where
liftST :: ST s a - m a
instance MonadST s (ST
It does. In the most recent version, the full class declaration runs
class MonadST m where
type StateThread m
liftST :: ST (StateThread m) a - m a
and the StateThread propagates accordingly.
Louis Wasserman
wasserman.lo...@gmail.com
On Thu, Feb 19, 2009 at 2:10 AM, Sittampalam, Ganesh
So, why not use this definition? Is there something special about ST
you are trying to preserve?
-- minimal complete definition:
-- Ref, newRef, and either modifyRef or both readRef and writeRef.
class Monad m = MonadRef m where
type Ref m :: * - *
newRef :: a - m (Ref m a)
readRef
Oh, sweet beans. I hadn't planned to incorporate mutable references -- my
code uses them highly infrequently -- but I suppose that since mutable
references are really equivalent to single-threadedness where referential
transparency is concerned, that could be pulled off -- I would still want a
Ryan, I didn't get your question after the first read, so here's an actual
answer to it --
What I want to preserve about ST is the existence of a guaranteed safe
runST, really. I tend to do algorithms and data structures development,
which almost never requires use of IO, or references of any
On Mon, 16 Feb 2009, Louis Wasserman wrote:
Overnight I had the following thought, which I think could work rather well.
The most basic
implementation of the idea is as follows:
class MonadST s m | m - s where
liftST :: ST s a - m a
instance MonadST s (ST s) where ...
instance MonadST s m
On Mon, 16 Feb 2009, Louis Wasserman wrote:
I just posted stateful-mtl and pqueue-mtl 1.0.2, making use of the new approach
to
single-threaded ST wrapping. I discovered while making the modifications to
both packages that
the MonadSTTrans type class was unnecessary, enabling a cleaner
Yes, it really is like MonadIO -- just capable of being used to produce
guaranteed purely functional results ^^
Louis Wasserman
wasserman.lo...@gmail.com
On Wed, Feb 18, 2009 at 5:43 PM, Henning Thielemann
lemm...@henning-thielemann.de wrote:
On Mon, 16 Feb 2009, Louis Wasserman wrote:
I
: haskell-cafe-boun...@haskell.org
[mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Louis Wasserman
Sent: 16 February 2009 03:31
To: Dan Doel
Cc: Henning Thielemann; haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] ANNOUNCE: pqueue-mtl, stateful-mtl
Okay, I tested it out and the arrow
On Mon, Feb 16, 2009 at 2:30 AM, wren ng thornton w...@freegeek.org wrote:
Louis Wasserman wrote:
I follow. The primary issue, I'm sort of wildly inferring, is that use of
STT -- despite being pretty much a State monad on the inside -- allows
access to things like mutable references?
2009/2/16 Josef Svenningsson josef.svennings...@gmail.com:
On Mon, Feb 16, 2009 at 2:30 AM, wren ng thornton w...@freegeek.org wrote:
Louis Wasserman wrote:
I follow. The primary issue, I'm sort of wildly inferring, is that use of
STT -- despite being pretty much a State monad on the inside
*Subject:* Re: [Haskell-cafe] ANNOUNCE: pqueue-mtl, stateful-mtl
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
: Louis Wasserman [mailto:wasserman.lo...@gmail.com]
Sent: 16 February 2009 16:01
To: Sittampalam, Ganesh
Cc: Dan Doel; Henning Thielemann; haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] ANNOUNCE: pqueue-mtl, stateful-mtl
Overnight I had the following thought, which I think could work rather
.
--
*From:* Louis Wasserman [mailto:wasserman.lo...@gmail.com]
*Sent:* 16 February 2009 16:01
*To:* Sittampalam, Ganesh
*Cc:* Dan Doel; Henning Thielemann; haskell-cafe@haskell.org
*Subject:* Re: [Haskell-cafe] ANNOUNCE: pqueue-mtl, stateful-mtl
Overnight I had
: [Haskell-cafe] ANNOUNCE: pqueue-mtl, stateful-mtl
But the m - s dependency will have been removed by the time runST gets
a hold of it! It works, I just tested it.
*Control.Monad.Array.ArrayM :t runST (runArrayT 5 Nothing getContents)
runST (runArrayT 5 Nothing getContents) :: [Maybe
somewhere.
--
*From:* Louis Wasserman [mailto:wasserman.lo...@gmail.com]
*Sent:* 16 February 2009 16:17
*To:* Sittampalam, Ganesh
*Cc:* Dan Doel; Henning Thielemann; haskell-cafe@haskell.org
*Subject:* Re: [Haskell-cafe] ANNOUNCE: pqueue-mtl, stateful-mtl
Don't use the
data (context) = type = constructors
syntax, it doesn't do what you want.
All it does is add the context to the constructor B while not
providing it to any of the functions that use it.
A better solution is
data Bar a = forall b. Foo a b = B a b
or, equivalently, using GADT
On Monday 16 February 2009 8:44:21 am Josef Svenningsson wrote:
On Mon, Feb 16, 2009 at 2:30 AM, wren ng thornton w...@freegeek.org wrote:
Louis Wasserman wrote:
I follow. The primary issue, I'm sort of wildly inferring, is that use
of STT -- despite being pretty much a State monad on the
Dan Doel wrote:
Someone already mentioned using Dynamic as an alternate base (for
instance, use a Map of dynamics for underlying storage). Of course,
the implementation of Dynamic in GHC uses unsafeCoerce, just like ST,
so you may not count that.
However, using GADTs, you can implement
Hello all,
I just released two new packages on Hackage, stateful-mtl and pqueue-mtl.
Stateful-mtl provides an ST monad transformer, several useful operations on
generic monad transformers, and a monad transformer intended to cleanly
externally wrap operations on a mutable array (including
Stateful-mtl provides an ST monad transformer,
Is this safe? e.g. does it work correctly on [], Maybe etc?
If not this should be flagged very prominently in the documentation.
Cheers,
Ganesh
==
Please access the
On Sun, Feb 15, 2009 at 09:59:28PM -, Sittampalam, Ganesh wrote:
Stateful-mtl provides an ST monad transformer,
Is this safe? e.g. does it work correctly on [], Maybe etc?
If not this should be flagged very prominently in the documentation.
It is not safe: it has the same problem as
I follow. The primary issue, I'm sort of wildly inferring, is that use of
STT -- despite being pretty much a State monad on the inside -- allows
access to things like mutable references?
More serious question: The issue of nondeterministic branching and the State
monad is something that's
On Sun, 15 Feb 2009, Louis Wasserman wrote:
I follow. The primary issue, I'm sort of wildly inferring, is that use of STT
-- despite being
pretty much a State monad on the inside -- allows access to things like mutable
references?
I assume that ST must always be the most inner monad, like
Well, it makes me sad, I guess. pqueue-mtl provides an array-backed heap
monad transformer that is supposed to keep its own ST thread, if only for
the sake of retaining a purely functional interface without any externally
visible forall'd types, which is perfectly fine in most cases, but I'd have
You can roll your own pure STT monad, at the cost of performance:
-- Do not export any of these constructors, just the types STT and STTRef.
data W = forall a. W !a
data Heap s = Heap !Int !(IntMap W)
newtype STT s m a = STT (StateT (Heap s) m a) deriving (Monad,
MonadTrans, MonadIO, insert other
The module I put together already has everything I'd need to do it in terms
of an IntMap with much less work than that -- the generic MonadArray type
class has implementations both in terms of ST and in terms of an IntMap
already. Only three changes in the Heap implementation would be needed: two
Louis Wasserman wrote:
I follow. The primary issue, I'm sort of wildly inferring, is that use of
STT -- despite being pretty much a State monad on the inside -- allows
access to things like mutable references?
That's exactly the problem. The essential reason for ST's existence are
STRefs
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
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
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
34 matches
Mail list logo
