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@BetaResearch.de http://www.betaresearch.de