extent strings

[Simon Peyton-Jones]

A process comment:

  This FFI discussion is dragging.  I really want to
   get a conclusion because I want to implement it
   for .NET.  Manuel --- you are are Tzar.  Whip us
  into order!

(I don't think that any of the issues are do-or-die ones; i.e.
compromise is possible!)

| > > [...] What's the advantage of putting the information in a string?
| > [...] This is useful for tools that parse Haskell source code but 
| > which are not compilers -- e.g. documentation generators.
| 
| That's not really an argument, because if we slightly change 
| the grammar, a "catch-all" production is easily specified:

But only if the catch-all production catches all. For example,
suppose we wanted to specify the full type signature of a Java
function. In principle we could specify a grammar that would
describe

	foreign import jvm 
		static int Java.Lang.foo( int x ) 
		foo :: Int -> IO Int

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

	foreign import jvm 
		"static int Java.Lang.foo( int x )"
		foo :: Int -> IO Int

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)

Haskell functions that are *used* must be in scope already;
those that are being *defined* are brought into scope by the 
foreign decl.

Unfortunately, 'foreign export dynamic' defines a function, so
one cannot just look at the import/export keyword.

Maybe we need
	foreign import
	foreign export
	foreign dynexport
?

(Dynamic import is quite different; it's still an import, but there's
one more argument.)


Simon