FFI Definition

[Sven Panne]

"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