80/20 programming language interoperability?

[Shelby Moore]

Thank you very much for the feedback, my comments follow.

[...]
>> There seems to be no priority design focus
>> on interoperability between languages?  Nor any priority design focus on
>> the performance of interoperability with native C code?
[...]
> Parrot developers care *greatly* about language interop, what we refer
> to as HLL (High Level Language) interop. You can find the draft Parrot
> Developer Doc (PDD) here [0] and you may also want to check out the
> draft PDD on our HLL interface [1]. As for our native code/FFI, you
> probably want to read the NCI (Native Call Interface) PDD [2].
[...]
> [0] -
> http://docs.parrot.org/parrot/latest/html/docs/pdds/draft/pdd31_hll_interop.pod.html
> [1] -
> http://docs.parrot.org/parrot/latest/html/docs/pdds/draft/pdd31_hll.pod.html
> [2] -
> http://docs.parrot.org/parrot/latest/html/docs/pdds/draft/pdd16_native_call.pod.html

I am unable to thoroughly wrap my mind around all the intricacies of those
above linked PDD documents without becoming much more knowledgeable about
Parrot.  However, perhaps I can make some fundamental conclusions and
correct my prior questions above.

The point I wanted to make was that Parrot's design goal appears to
maximize the diversity of HLL support, and thus HLL interoperability will
inherently incur complexity.  This is inherent in supporting HLLs which
have data types which are not directly mappable to the "Plain Parrot
Semantics" types.  This design focus is both a strength and a weakness. 
Hypothetically (and an oversimplification), Parrot would thus be favored
when one chooses to maximize their HLL choice, at the cost of complexity
of interoperability.  Ultimately this complexity could deadlock
composeability (mathematically given when there is not an invertible,
lossless mapping), but not after much composeability was obtained which
would have otherwise been impractical to attain.

I had recently approached the NekoVM discussion list to get feedback on
the idea/concept (or lets say "niche" market) that for some applications,
the priority focus is on a dynamic language (HLL) for coding efficiency
and C for performance optimization.  Diverse HLLs interoperability (and
the inherent complexity) may be a lower priority for such applications,
e.g. real-time online gaming.  In that case, my posts at the NekoVM
discussion list are pondering whether representing the VM data types
internally as binary interoperable with C, would provide 80/20 rule
optimization for interoperability and composeability.  And still diverse
HLLs could target this common denominator, albeit with some losses as
compared to Parrot's open PMC design.

I am starting to think the NekoVM's design strength was directed towards
the above genre of conceptual advantage, but perhaps it is "half-baked"
relative to the specific advantages I am pondering.  I am not sure about
that nor yet fully versed on what advantages NekoVM has obtained, and I am
still trying to get feedback and learn as much as I can about these
matters.  I am not posting to start any ill feelings.  I am merely trying
to learn about the tradeoffs and have interesting discussions.  I will
reply to your other post to elaborate my thoughts:

http://lists.parrot.org/pipermail/parrot-dev/2010-January/003675.html