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 ;) Groetjes, Remi -- Nobody can be exactly like me. Even I have trouble doing it. _______________________________________________ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
