extent strings

[Simon Marlow]

> 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