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