Sven Panne <Sven.Panne@informatik.uni-muenchen.de> wrote,
"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 %-)
Like so foreign import ccall "libgtk.so" "gtk_widget_destroy" gtk_widget_destroy :: Addr -> IO ()
[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 | ...
The current idea is to make the syntax of the FFI extension independent of the supported languages. This requires to stuff everything into `extent'. Sure, this will make the `extent' string complex for some languages, but that's inevitable for anything but C anyway. The old design really benefitted from that we basically considered C only. The goal now is to bring the whole thing into better shape for supporting multiple languages and being open for addition of new calling conventions later.
And for legacy reasons we have to keep dynamic for some time, anyway.
Let's forget about the legacy stuff for the FFI definition. The systems have to support the legacy syntax, but that's really of no concern for the definition.
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.
The other design, which I believe is cleaner (and which I understand as the consensus at the HIM meeting), is to get rid of all the side conditions and put all the calling convention dependent stuff into `extent'. The latter is calling convention dependent and complicated (for everything but C) anyway. So, let's at least keep the rest simple. In fact, any system supporting a calling convention like jvm, will have to have a parser for extent strings anyway.
Another extreme route would be:
topdecl : 'foreign' string var '::' type
with a separate syntax for the string contents.
Yes that's going into the right direction, but it makes sense to leave both the calling convention as well as import/export out of the string. The calling convention defines which parser to use in the string. That's good for implementers, because then, the parser can be chosen before parsing starts. The import/export information is needed by the name analysis, which we better leave independent of the whole extent mess. In other words, having the calling convention and import/export seperate facilitates more modular compiler support. Cheers, Manuel