Malcolm Wallace [EMAIL PROTECTED] wrote,
Wolfram Kahl suggested to add functions isNullPtr and
isNullFunPtr (with the expected semantics) to the Ptr
module. Opinions?
Ptr and FunPtr are already instances of Eq, so which is easier to type?
isNullPtr x
or
x==nullPtr
So I
Simon Marlow [EMAIL PROTECTED] wrote,
The FFI Addendum actually doesn't commit to which operations
are in the class. It just says defines all these ops to
have a context `Bits a', which is definitely the case. In
other words, you proposed implementation is valid by the
spec and your
Alastair Reid wrote:
[snip]
What you're asking Hugs and NHC to do is: add a function to a list
whenever you have a finalizer to run; make sure the interpreter will
test that bit whenever it is in a position to perform a context
switch.
Am I really asking that much? In that paper you wrote
I confess that I have not followed the twists and turns of this
discussion, but it seems to have gotten more complicated than necessary.
There are several separate issues.
1. Can a finaliser for a Haskell value be an arbitrary Haskell
computation? For GHC, yes. For Hugs, no (and for good
I'm afraid George's questions have also rekindled my curiosity about
whether implementing Haskell finalizers is really as hard as it sounds.
Much has been written, but I still don't think we've got to the nub of
the issue.
On the face of it, if you can implement 'foreign import ccall safe',
then
Manuel M T Chakravarty wrote:
[snip]
BTW, having two languages with separated heaps interact is a
big mess as soon as you can have cycles, which you usually
cannot exclude. Alastair already pointed that out and
Martin Odersky also has nice stories to tell about this.
[snip]
Yeah yeah I know,
Manuel M T Chakravarty [EMAIL PROTECTED] writes:
Sure, but there is also
null = (== [])
in the Prelude and `Maybe.isNothing'.
No, the definition of null is
null [] = True
which is quite different from (==[]) because it has a less-constrained type.
null :: [a] - Bool
(==[])
BTW, having two languages with separated heaps interact is a big
mess as soon as you can have cycles, which you usually cannot
exclude. Alastair already pointed that out and Martin Odersky also
has nice stories to tell about this.
Hmmm, way back in '94, my thought was that the only thing
Do you want a stronger wording on what kind of garbage collection is
to be performed or do we want to keep it deliberately unspecified
(ie, leave it to the individual Haskell system)?
It'd be nice to say that it has to be a full GC - but I've no idea how
to specify that in a non-operational
Alastair wrote about performGC (snipped)
It'd be nice to say that it has to be a full GC - but I've no idea how
to specify that in a non-operational (i.e., implementation dependent)
way.
I certainly don't think you should constrain implementations to be able to perform
a full GC in any sense.
Alastair wrote about performGC (snipped)
It'd be nice to say that it has to be a full GC - but I've no idea
how to specify that in a non-operational (i.e., implementation
dependent) way.
George Russell [EMAIL PROTECTED] writes:
I certainly don't think you should constrain implementations to
Alastair Reid [EMAIL PROTECTED] wrote,
George Russell [EMAIL PROTECTED] writes:
Also there are probably hard-real-time GC algorithms (like Baker's
treadmill) or algorithms which are close to being hard-real-time
(like the train algorithm) where doing a full GC would be a major
pain.
I agree with SimonM that the proposed routines have useful
applications. Furthermore, it is trivial for Haskell
systems to implement these routines. Hence, I will include
them into the spec unless there are serious objections.
Cheers,
Manuel
___
FFI
13 matches
Mail list logo
