Module Initialisation? (was Re: [Haskell] (no subject))
rturk at science.uva.nl
Sun Oct 17 14:50:56 EDT 2004
On Sun, Oct 17, 2004 at 07:20:28PM +0100, Ben Rudiak-Gould wrote:
> Remi Turk wrote:
> > On Sun, Oct 17, 2004 at 05:11:02PM +0100, Ben Rudiak-Gould wrote:
> >> I don't think there's any problem with
> >> type MVar = STMVar RealWorld
> >> newMVar :: a -> ST s (STMVar s a)
> >> withMVar :: STMVar s a -> (a -> ST s b) -> ST s b ...
> >> For that matter it seems like we could (should?) have
> >> forkST :: ST s () -> ST s (STThreadId s) forkIO = forkST
> > But what semantics would they have? It cannot be the normal
> > concurrency as AFAIK runST is supposed to be deterministic.
> Okay, so I'm being silly. Forget forkST then. But STMVar is still okay,
> isn't it? The only MVars you could use in a state thread would be those
I won't ever remind you of your being silly if you tell me about
the current state of your implicit-(parameter|return)-IO story ;)
STMVar does indeed still seem okay, except that I have no idea if
it actually makes any sense outside of IO.
(That is: newSTMVar x = unsafeIOToST (newMVar x) seems a bit
pointless and might be the actual way it needs to be implemented.
Has a vague feeling of being silly too now...)
By the way, I'm still in favour of `type IO a = ST RealWorld a':
It just seems wrong to either "let's just make it IO" or having
to sprinkle stToIO's around...
> you'd created in the same state thread, and without forkST they can't be
> accessed in a nondeterministic way. Their presence is pointless, true,
> but at least not unsafe.
> It does seem a bit of a hack, but it still seems preferable to the other
> alternatives currently on the table (namely unrestricted IO, a new
> SafeIO, or unsafeIOToST.newMVar).
> -- Ben
I'm waiting to be convinced either way ;)
Nobody can be exactly like me. Even I have trouble doing it.
More information about the Haskell