extent strings

[Sven Panne]

Fergus Henderson wrote:
> On 14-May-2001, Alastair Reid <reid at 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 at BetaResearch.de    http://www.betaresearch.de