extent strings
Sven Panne
Sven_Panne at BetaResearch.de
Fri May 18 06:03:42 EDT 2001
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
More information about the FFI
mailing list