> Hmmm, that's an opinion, but not a technical reason. What I
> was hoping for
> is a real rationale for the extent string, i.e. why neither
> the one extreme
>
> topdecl : 'foreign' string var '::' type
>
> nor my last suggestion (the opposite extreme) would fit.
> Currently we seem
> to draw a rather arbitrary line between "real" Haskell syntax and the
> extent string, while my last suggestion only used strings for entities
> where nothing Haskell-like would fit syntactically, i.e. C identifiers
> and #include paths. So I'm with Alastair and Fergus, but I'm
> still ready
> to be convinced otherwise...
I think the rule of thumb which we've been using so far is
* the information outside the string is enough for a compiler
to statically analyse and typecheck the foreign declaration,
which includes checking whether the type of a f.e.d. has the
right form, etc.
* the information inside the string is required only by a
compiler back-end that needs to generate the actual call
(in the case of an import) or definition (in the case of an
export).
One reason for keeping the back-end info inside a string is because it
is likely to be specified using syntax from the foreign language: eg. C
identifiers don't have the same lexical syntax as Haskell identifiers,
and C++/Java identifiers have to include a type to be uniquely
specified.
It's hard to say how well this generalises without working though all
the issues for 2 or 3 different languages, but I guess we already know
that ceratin foreign declarations don't make sense for Java (f.i.d.), so
the upshot seems to be that each language will need its own foreign
declaration syntax.
I buy the argument that introducing new syntax for each new language is
OK as long as it generalises to a list of vars/strings, for tools that
don't need to understand any more than that. This looks like a
reasonable compromise that should keep everyone happy.
Cheers,
Simon
