qforeign-0.62

[Marcin 'Qrczak' Kowalczyk]

On Tue, 28 Nov 2000, Simon Peyton-Jones wrote:

> Simon and I noticed this morning that ForeignObj should
> really be parameterised.

I was considering it too and IMHO it does not need to be parametrized.

Values implemented as foreign objects are often exposed to the user of the
module. For this reason they are usually wrapped in newtypes to make them
truly abstract. So we don't worry for the external interface - it is safe
anyway, the objects will not be mistaken for something from a different
library.

Values kept under foreign objects are usually C structs which don't have a
Haskell equivalent. If the type was simple (e.g. struct RGB {double r, g,
b;};), it would be represented as a Haskell record. Since the type needs a
finalizer, it usually means that it's complex enough to be not exported
concretely by a C library, so there is no appropriate Haskell type to make
a Storable instance - it will be accessed only through functions imported
from C. And since it's complex enough, it will not be marshalled as a
whole - instead its fields will be extracted as needed. And since it's
finalized, it usually means that its lifetime is important because it
represents some external resource, so it will really not be ever
marshalled!

I am sure that in most cases in practice there is no appropriate type to
use as ForeignObj's argument, and it will be used as ForeignObj ().
We should not support such fiction.

It is very different from raw pointers which are often used for simple
types which do have Storable instances. And there are more kinds of
pointers used in an average library than kinds of foreign objects. Since
pointers are not usually exported and there are many library functions
operating on pointers, they will not be wrapped in newtypes, so they must
carry the type information themselves.

-- 
Marcin 'Qrczak' Kowalczyk