Alastair Reid <[EMAIL PROTECTED]> wrote,
> > It's awkward because it requires a subtle side condition on what is
> > a valid finaliser that is going to trip up users and cause strange
> > errors.
>
> It is the same side condition we place on unsafe calls.
Safe calls are the default. If somebody explicitly
specifies an unsafe call, I expect the person knows what
s/he is doing.
> > This awkwardness is tolerable if it simplifies the implementation a
> > lot (as in avoids having to implement pre-emptive concurrency).
>
> See my other posting this morning on why Haskell finalizers are of no
> practical use without adding concurrency primitives which support
> blocking.
This point is orthogonal to my motivation of wanting Haskell
finalizers.
(1) Haskell finalizers fit better into the rest of the
system, where we do in Haskell whatever we can.
(2) C finalzers have this awkward side condition on
re-entering the Haskell system - see above.
Moreover, if a system supports concurrency primitives and
blocking, Haskell finalizers fit smoothly in. If we have C
finalizers, we need to add Haskell finalizers in such a
system and have two redundant mechanisms (otherwise, we
force people to write a superflous C function re-entering
Haskell for each Haskell finalizer they need). It's just
yucky.
> > It is not tolerable if it is just a matter of verifying that an
> > existing implementation proposal does indeed work (or even if it
> > requires tweaking that proposal).
>
> Another valid goal is portability.
>
> We can specify a low bar now and raise the spec later. For example,
> at present the spec is that the finalizer is equivalent to an unsafe
> ccall, we can strengthen that spec to allow safe ccalls too later (and
> once we can do that we can extend the spec with convenience functions
> which allow naked Haskell finalizers).
To be honest, I don't understand why you are so opposed to
this. Why not find out whether SimonM's patch works? If it
does, the problem is solved, we can use the nicer
definition, and everybody is happy.
Manuel
_______________________________________________
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
