extent strings

[Manuel M. T. Chakravarty]

Sven Panne <Sven_Panne at BetaResearch.de> wrote,

> > 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.

Heh?  Did you earlier say that you don't want a
``execution-platform-specific string''?

> > 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

Exactly.

> > 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 :-), 

I don't think it is a hack.  If nothing else, it is a
visual cue as to what information is needed by the front-end
(and maybe tools) and what is only interesting for the code
generator.  In particular, this facilitates offloading the
handling of all/part of the foreign declarations to a
pre-processor (something Alastair proposed once for Hugs
IIRC).