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