Fergus Henderson wrote:

On 14-May-2001, Alastair Reid <reid@cs.utah.edu> wrote:

...

[...] What's the advantage of putting the information in a string? [...] This is useful for tools that parse Haskell source code but which are not compilers -- e.g. documentation generators.

That's not really an argument, because if we slightly change the grammar, a "catch-all" production is easily specified: ------------------------------------------------------------------------ topdecl : 'foreign' 'import' callconvC impspecC var '::' type | 'foreign' 'export' callconvC cid var '::' type -- "Don't know the callconv"-production | 'foreign' ['import'|'export'] (var|string)* var '::' type callconvC : 'ccall' | 'stdcall' impspecC : ['static'] ['unsafe'] cid include -- former f.i. | 'dynimp' ['unsafe'] -- former f.i.d. | 'dynexp' -- former f.e.d. | 'label' cid include -- former f.l. -- contents automagically wrapped into double quotes if they don't start -- with either '"' or '<' include : string -- could default to var of production topdecl cid : string ------------------------------------------------------------------------ Personally, I'd prefer something like the above syntax, too, restricting oneself syntactically to (var|string)* for any future calling convention's import/export specification is not that hard. Completely switching to string land is a little bit of hack IMHO, but perhaps the advocates of this solution could explain their preference a little bit. Just a side note: The above syntax is quite close to the current one, and defaulting (even of callconvC) can be done without ambiguity: foreign import puts :: CString -> IO CInt *sigh* At least there seems to be some consensus regarding the syntax of the import/export specification for C, within a string or not... Cheers, Sven P.S.: Still no better naming suggestions for 'dynimp' and 'dynexp'? -- 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