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
_______________________________________________
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
