| * 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