Proposal: Pooled memory management

[Sven Panne]

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.