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