Sven says:
> I'd like to finish discussion around the low-level aspects of the
> FFI, so I propose the following: If none of the implementors yells
> loudly that the ForeignObj FFI rule is costly to implement, this
> lifetime rule should be left as it is. (It can't be hard to implement,
> because as a fallback the StablePtr "trick" could be used.) We all
> agree that it is easy and safe to use, and captures a common case.
As the implementor of the primitive FFI in nhc98, I'm sitting here
somewhat baffled. For us, the ForeignObj rule is not only easy to
implement - it requires no implementation whatsoever! It would be far
more difficult to try to get ForeignObjs to deallocate themselves
randomly whilst they are still live. I remember this discussion of a
so-called "special rule" for ForeignObjs from previously, and I still
don't understand why it is "special" rather than the obvious and only
way to do things.
> > Should memory allocated for passing Strings be deallocated after
> > a foreign call or not?
Errm, the primitive FFI doesn't currently allow Strings to be passed at
all, so of course this can only belong in a library.
Regards,
Malcolm
