I'll admit I sometimes can't think that far ahead to see all of the problems, but when I have problems sitting in front of me, I can usually solve them.
The situation we have now is: Parrot is a VM, and technically we could just punt the whole calling convention issue to a high level languages forum (parrot-languages if there was one) or something, but sadly that wouldn't work, because currently there aren't enough people to go around.
What we really need is for some languages group to step up and start a working paper on the possible high level constructs that will present potential issues for Parrot, and show some potential solutions for compiling them, and look at those issues when related to maintaining backwards compatibility for old bytecodes. The paper should probably be language specific.
I do like Tim's suggestion of multiple entry points for a given sub in a module, but rather than discuss it much further, I'd like to be presented with a clear sample and clear requirements beforehand.
I also do not think the Parrot core developers should have to take responsibility of every possible issue because one language's issues are not an issue for another. The questions is, how much do we specify as a "Parrot Standard" as opposed to a language specific standard.
I see 2 possible paths, both equally viable for us to take.
a) Parrot Standard specifies that all bytecodes will be compatible with both prototyped calls and non-prototyped calls, and all high level languages on Parrot will just magically work together, even though the code will probably be a lot fatter.
b) Parrot Standard specifies what conventions are _available_, but not which to use. If a high-level language lends itself to prototypes and high levels of optimization, it should not have to suffer. Let library writers write "glue" code, as they do now, if they wish to interact between languages. Glue code might be as simple as defining certain entry points (subs) as "unprototyped."
As far as requirements, I don't know whether it is (a) or (b) or neither. Sometimes requirements are a luxury, but its hard for a group of open source developers to get much done without any, and in this case I think we really need them.
I like (b) because it is more flexible, and actually accomplishes the same goal in (a), but lets the developer decide when and where it makes sense to "work together".
-Melvin
