Sven Panne <[EMAIL PROTECTED]> 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).
>From a conceptual point of view, it defines exactly where
the extensible bit of the syntax is (ie, that which is
altered by addition and omission of calling conventions).
And moreover, having the syntax of the extent directly
depend on the calling convention leads to a context
sensitive grammar. Sure, the parsing within the string is
going to depend on the calling convention anyway, but then
we have a kind of two-stage grammar. That seems nicer to me
than the alternative.
> an agreement would be more important than lexical Jihads.
> Manuel to the rescue!
Ok. All but (a) - (d) from above is in the string.
You asked for it ;-)
Cheers,
Manuel
_______________________________________________
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
