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