FFI Definition

[Simon Peyton-Jones]

|  * I'm not very happy with the fact that static/dynamic are 
| only viewed
|    as modifiers, like unsafe/safe. They almost completely change the
|    meaning of a foreign declaration, including the typing rules. In my
|    view, we have *5* different language constructs: `foreign import',
|    `foreign import dynamic', `foreign export', `foreign 
| export dynamic',
|    and `foreign label'. 

|  * How will we differentiate between virtual vs. non-virtual 
| methods in
|    the cplusplus calling convention? What about class methods vs.
|    instance methods? Will these distinctions have influence on the
|    typing rules? If yes, coding this into the extent would be wrong.
| 
|  * The JVM has *4* different instructions for method invocation
|    (invokeinterface, invokespecial, invokestatic, and 
| invokevirtual), so
|    our static/dynamic distinction seems a bit inflexible here. And the
|    introduction of the "new" prefix looks like a hack, which doesn't
|    even handle all situations.


These are good questions.  

I think it's inevitable that the form of type of the foreign thing is
going to depend on per-language details.  For C we have

	call
	call indirect
	label

For Java we have

	4 different invocations
	new

For C++ we have 

	call virt
	call non-virt
	new

Etc.  Each of these implies a particular form for the type.

I think we have to bite the bullet and put this stuff in the language
specific string, including our current static/dynamic thing.  The
compiler
has to be able to parse this string in order to generate an appropriate
call, so it's no big deal for this parse info to feed into the type
checker too.

This is moving in exactly the opposite of what Sven suggests, but I
don't
see any alternative.  My criterion is

	language specific stuff inside the "..." string
	language independent stuff outside

Simon