(It would be nice to have some concurrency in nhc98, of course, but
I don't foresee that happening soon.)
I remember implementing cooperative concurrency in Hugs as being
rather easy. Of course, that was building on a base which already used
a continuation passing IO monad...
If you want to
What hasn't been required is for the various data structures to be
in a consistent state at that point, and Haskell finalizers might
trip over those if run after GC. SimonM's patch ran them at a
different point, though.
It calls them in eval doesn't it?
eval is called by nearly every
However even if Haskell finalizers + MVars are impossible in NHC, I
don't think Haskell finalizers + mutable state have to be. For
example another mutable variable we could have would be a PVar which
is always full and has functions [snip]
updatePVar (PVar ioRef) updateFn =
do
[snip] I don't see that it's necessary for us to come to a decision
right now about PVars unless we want to put them in the FFI
standard.
But what if we can't agree on something like PVars or we decide that
Haskell finalizers plus yet another synchronization mechanism is worse
than C
For the record, I am strongly in favor of Haskell finalizers, if a
Mutable State extension were to be written, then it will have to
address the issue with one of the solutions mentioned in this
thread,
We already have a perfectly good Mutable State extension. We know
exactly what it looks
Dear Sir or Madam
In the past you have requested information on discounted products. If you are not a
smoker, and find this email offensive, then we sincerely apologise. We will be only
too happy to take you off our database.
If you are a smoker, however, you are probably fed up with paying
On Sat, Oct 12, 2002 at 06:03:07PM +0100, Alastair Reid wrote:
For the record, I am strongly in favor of Haskell finalizers, if a
Mutable State extension were to be written, then it will have to
address the issue with one of the solutions mentioned in this
thread,
We already have a
