extent strings

[Sven Panne]

Simon Peyton-Jones wrote:
> A process comment:
> 
>  This FFI discussion is dragging.  [...]

Exactly.

> But it's hard to parse without the newline, and it's going to
> be hard to specify a catch-all syntax that enables the documentation
> generator to skip all the jvm-specific junk.
> 
> I think we should stuff it into a execution-platform-specific string,
> thus [...]

That's exactly conforming to my proposed catch-all production, so I
see no problem here.

> What should be visible "outside" the string.  I think:
> 
>         a) what Haskell function is being defined or used
>         b) what the Haskell type of that function is
>         c) whether the function is being *defined*
>                 (like foreign import or foreign export dynamic)
>             or *used*
>                 (like foreign export) [...]

          d) The calling convention

> Unfortunately, 'foreign export dynamic' defines a function, so
> one cannot just look at the import/export keyword.

One *can*: The compiler/interpreter just needs to look at the keyword
specifying the kind of import (static, dynamic, dynamic export, label).

> Maybe we need
>         foreign import
>         foreign export
>         foreign dynexport [...]

We really should not introduce a third kind of foreign declaration. With
my last proposal the roles a clearly defined:

   * import/export distinguishes between definition and usage.

   * callconv specifies, well, the calling convention

   * The combination of import/export and callconv specifies the syntax
     of the import/export specifier (be it a string or not).

   * var specifies the Haskell function being defined/used.

   * The combination of import/export, callconv, and specifier determine
     the typing rules.

But after all, I don't think our opinions differ very much. The main
topic remaining seems to be the question: How much should we stuff into
the extent string? Alastair, Fergus, and I seem to prefer the rule "As
few as possible", while others prefer the opposite. Personally, I don't
care about this that much (although I still consider the string solution
a hack :-), an agreement would be more important than lexical Jihads.
Manuel to the rescue!

I'd like to close with my latest "strings are evil"-proposal, which is
not very much different from my last one. It's only slightly restructured,
two keywords have been renamed, and it's hopefully more typo-free:

------------------------------------------------------------------------
topdecl   : 'foreign' 'import' impspec var '::' type
          | 'foreign' 'export' expspec var '::' type

impspec   : callconvC impspecC
          | unknowncc

expspec   : callconvC expspecC
          | unknowncc

impspecC  : ['static'] ['unsafe'] c_entity              -- former f.i.
          | 'dynamic'  ['unsafe']                       -- former f.i.d.
          | 'dynexport'                                 -- former f.e.d.
          | 'label'               c_entity              -- former f.l.

expspecC  : <empty> -- former f.e., cid defaults to var of prod. topdecl
          | cid     -- former f.e.

callconvC : 'ccall'
          | 'stdcall'

c_entity  : <empty>              -- cid defaults to var of prod. topdecl
          | cid
          | cid include

cid       : string

include   : string  -- contents automagically wrapped into double quotes
                    -- if they don't start with either '"' or '<'

unknowncc : (var'|string)*       -- "Don't know the callconv"-production

var'      : <every var which is not a known callconv>
------------------------------------------------------------------------

This can easily be extended to be almost completely backwards compatible,
with one exception: Two strings mean cid plus include now, while it meant
DLL plus cid in elder times. The only solution I see here is a flag like
-fold-ffi.

Cheers,
   Sven

P.S.: Anybody out there with an URL for "Wadler's Law of Language Design"...?
:-}
-- 
Sven Panne    Fon: +49/89/99567000    Fax: +49/89/99567461
BetaResearch GmbH,    Betastr. 1,    D-85774 Unterfoehring
mailto:Sven_Panne at BetaResearch.de    http://www.betaresearch.de