"Manuel M. T. Chakravarty" wrote:
[loading dynamic libs problem] This is just like the library object specification that we have now also.
Huh? What? I've never seen a lib object spec... (or completely forgot it %-)
[static/dynamic + callconv] Meanwhile, I think, you are right, we cannot make a clean language-independent static/dynamic distinction.
The callconv already prescribes the syntax of ext_ent and the typing, so it could prescribe the possibilities for mode, too. And static/dynamic makes sense e.g. for cplusplus and jvm at least, with a slight reinterpretation of the actual meaning, but that's not very crucial. I'm against stuffing everything into ext_ent in a string form, which would mean a mini-language within Haskell (TCL is lurking! :-). My proposal: -- allowed for import/export mode : 'static' -- allowed for ccall/stdcall/cplusplus/jvm/..., default then | 'dynamic' -- allowed for ccall/stdcall/cplusplus/jvm/... | 'interface' -- allowed for jvm | ... And for legacy reasons we have to keep dynamic for some time, anyway.
Also should 'label' be there? Doesn't make sense for Java, does it?
Hmm, not really. So, also into `extent'...
But it *makes* sense for some calling conventions, and it the actual translation will need the callconv (name mangling!), so the only change I propose here is a comment: fkind : 'import' | 'export' | 'label' -- allowed for stdcall/ccall/cplusplus Hmmm, looking at the whole foreign beast gives me a slightly uneasy feeling now. There are loads of strongly interconnected side conditions, but I fear we can't avoid this because of the complexity of the whole topic. But at least we should strive for an ext_ent with minimum complexity when we go the "special id" way, like we did in the past. Another extreme route would be: topdecl : 'foreign' string var '::' type with a separate syntax for the string contents. Is there some "standard" or at least widely accepted way of describing a multi-language FFI? We could re-use this here, but I'm not aware of anything like this... Cheers, Sven