qforeign-0.62

[Marcin 'Qrczak' Kowalczyk]

On Tue, 28 Nov 2000, Simon Marlow wrote:

> arguably, withObject and newObject should be named with and new
> ("Object" is awfully vague and seems redundant anyway).

Indeed, but "with" is a keyword in -fglasgow-exts and Hugs :-(

I'm not happy with the fact that some with* functions look inside
the named thing (withForeignObj, also withHandle in ghc's internals)
and some do the reverse: build a temporary object of the said type.

I tried allocaPoke* and mallocPoke* but they are quite ugly
(allocaPokeCString is the most basic way to pass strings to C functions).

Good ideas are welcome.

> Admittedly the functions above are C-specific and should probably go
> into a C-specific library on top of Foreign.  CForeign anyone?

Unfortunately it's hard to completely separate C-specific things. Is
malloc C-specific? Theoretically yes, but I doubt that we want a generic
allocation function which does not necessarily match C's malloc in the
generic part, and additionally C's malloc in the C-specific part.

I'm afraid that given the reality we live in, the basic part must refer to
C sometimes. E.g. we should guarantee that function pointers obtained from
foreign export dynamic using the default calling convention are compatible
with standard C function pointers, and that foreign import uses C's name
mangling by default.

We may separate some truly C-specific things to make the generic module
smaller (e.g. errno translation), but it's not going to be a pure
separation of only generic things vs. things having something common with
C.

It will bite when trying to interface to C++'s object allocation. But
there are bigger problems there anyway - allocation is normally coupled
with initialization, and destructors should be run by default before
freeing - so let's stick with C's malloc in the generic part, and we will
need other mechanisms for more complex languages.

> Meanwhile we should have some non-C-specific error-handling utilities
> in Foreign.

IMHO there is little or nothing to place there, assuming that the module
Exception is available. The hard-to-do-portably thing is to convert all
errno values to exceptions, which is C-specific. The only possible generic
things are really primitive and would be not used directly anyway: each
common error code convention creates the need of wrappers specific to that
convention. It would be good to provide specific wrappers in specialized
modules, e.g. handling some common Windows error codes.

-- 
Marcin 'Qrczak' Kowalczyk