Proposal: Pooled memory management

Sven Panne Sven_Panne at BetaResearch.de
Mon Jan 20 04:43:38 EST 2003


Manuel wrote:
> [...]
> * I want to get v1.0 of the spec fixed.  We are really only
>   in bug fix mode for quite a while and only the finalizer
>   problems held us back from finishing the spec.

That's OK and I understand your motivation. Let's finish v1.0 first.

> * I am sure there are plenty more useful FFI-related
>   libraries.  However, the initial plan was to define basic
>   functionality on top of which more elaborate schemes can
>   be implemented.  We need to draw the line somewhere. [...]

But I strongly disagree here: The initial plan was to make a very small,
but sufficient addition to the language (=> foreign import/export), which
can be implemented easily on existing systems. In this respect, we have
reached our goal quite elegantly IMHO.

The related libraries are a totally different beast: Minimality is *not*
a design goal here. Otherwise we might be happy with e.g.

   Foreign.Marshal.Alloc.mallocBytes
   Foreign.Marshal.Alloc.allocaBytes
   Foreign.Marshal.Alloc.reallocBytes
   Foreign.Marshal.Alloc.free
   Foreign.Marshal.Util.copyBytes
   Foreign.Marshal.Util.moveBytes

alone. Or another example: Why should we include such trivialities like

   Foreign.Marshal.Error.void

or

   Foreign.Marshal.Util.toBool

in the FFI spec? Minimality? Possibility of a lightning-fast special
implementation? Definitely not. The basic task of a library (or a
collection of related libraries) is to establish a common "language" and
make common notions (like scoped or pooled allocations) explicit. Looking
at the OO world, that's the reason for all this pattern hype.

In a nutshell: Let's include as many useful "patterns" in the next FFI spec
versions as possible! Otherwise we might talk the same language without
recognizing it...

Cheers,
   S.



More information about the FFI mailing list