"Manuel M. T. Chakravarty" wrote:
Like so
foreign import ccall "libgtk.so" "gtk_widget_destroy" gtk_widget_destroy :: Addr -> IO ()
I still don't understand the dynamic library stuff related to "fname". Is it a hint for a compiler to link against a given library? Any compiler surely has some kind of option/pragma for this already. What should it mean when there is a corresponding static lib, but not a dynamic one? Most of the time one doesn't really care about this. What should it mean for an interpreter? dlopen-ing? How should the condition "... if the external entity has to be obtained from a dynamically loaded library ..." be implemented, i.e. when does "fname" simply denote the header to #include and when does it denote something related to a DLL? It looks like mixing two unrelated concepts here.
The current idea is to make the syntax of the FFI extension independent of the supported languages. This requires to stuff everything into `extent'. [...]
OK, this makes sense, too.
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. [...]
I just wanted to make sure that legacy syntax is *possible* with my proposal, not that it should find its way into the FFI spec proper. It's quite easy to design things in such a way that legacy support is almost impossible, so we should keep this in mind.
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.
Hmmm, but there are still side conditions, e.g. the safe/unsafe distinction only makes sense for imports (and only for those which are not "label" imports), not for exports. This should be reflected in the syntax. And the whole modifier story looks a little bit like overkill. Let's try to be not too general initially. Even when we introduce more modifiers, I'm quite sure that they don't make sense equally in imports and exports. So here's my next try: ------------------------------------------------------------------------ topdecl : 'foreign' impexp [callconv] [extent] var '::' type impexp : 'import' ['unsafe'] | 'export' callconv : 'ccall' -- default | 'stdcall' | 'cplusplus' | 'jvm' | 'dotnet' extent : string -- default: the string rep. of var? ------------------------------------------------------------------------ BTW, we should better rename "extent" to something more unambiguous.
[...] 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. [...] 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.
But for exactly this reason we should re-think the static/dynamic story. I'm with Marcin here, a "foreign export dynamic" *is* an import, although the resulting function is used for exporting other functions to C land. Any suggestions for the "mode" part of the import's extent? Cheers, Sven