Alastair Reid <[EMAIL PROTECTED]> wrote, > > I have to say that, given Simon's patch, I am inclined to revert > > back to the old API for foreign pointers. > > I don't think such a change should be made unless Malcolm and I are > able to implement it. > > I'm not yet convinced that Simon's patch is as easy or correct as it > seems and will not be until it has been heavily tested and until I > have a chance to look carefully at the consequences of the change > elsewhere in the system. > > Also, Malcolm reported using a similar trick but that he couldn't get > it to work reliably (i.e., it was ok if the finalizer did nothing but > call out to C but not otherwise).
I won't change anything until we have finished discussing the issue, but I got the impression that I probably rushed the last change. So, I wouldn't consider the current definition the default either. > > The restriction on pure C land finalizers *is* awkward, and as we > > have already seen implies further changes (ie, adding something like > > `finalizerFree'). > > We missed a small detail in specifying the change and fixed it when we > went to implement it. This happens with most design changes and > doesn't seem like evidence of awkwardness to me. Fair enough. However, I still think that the current definition is awkward. It is awkward as it goes against the spirit of the rest of the spec, which strives to accomplish as much as possible in Haskell, not in C land. It's awkward as a user with a fairly big application (namely George) is inconvenienced by it. 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. This awkwardness is tolerable if it simplifies the implementation a lot (as in avoids having to implement pre-emptive concurrency). 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). At least, this is my understanding of good language design. Cheers, Manuel _______________________________________________ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
