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.