I am not a developer for, nor highly knowledgeable about, either Parrot or NekoVM. I recently approached the discussion lists for both to learn more about what you developers have learned about interoperability and composeability, and to share my ideas and research on the matters.
Cross-link: http://lists.parrot.org/pipermail/parrot-dev/2010-January/003675.html [...] > I would say that the Parrot VM is > written in C-with-sugar while the Parrot compiler interface uses NQP. So far, my limited understanding is that Parrot is a more complex and diverse: http://lists.parrot.org/pipermail/parrot-dev/2010-January/003678.html NekoVM apparently targets a common data type layer, which the HLL can abstract to its higher level types: http://nekovm.org/doc/misc/multilang This apparently should optimize interoperability on types which can be invertibly mapped to the common data type layer, but it provides no infrastructure for handling higher level types which can not map: http://docs.parrot.org/parrot/latest/html/docs/pdds/draft/pdd31_hll_interop.pod.html (see Plain Parrot Semantics section) The focus of my posts recently in both the NekoVM and Parrot discussion lists, has been on the 80/20 rule, and to optimize the realm of seamless interoperability, which seems to coincide with NekoVM's design of focusing on a common data type layer. I am proposing to take this one step further, to optimize the binary interoperability with native C code (why not? no cost and 80/20 gains, as per my prior posts) for static (final) object cases (which could be declarative and/or detected dynamically), and to develop a universal interface declaration syntax for the interoperability of dynamic HLLs on this common data type layer. I explained in my prior posts why virtual/prototype/base class inheritance breaks "Liskov Substition Principle" and is a semantic obfuscation "can of worms", and should be replaced by orthogonal+composeable interface declarations: http://lists.motion-twin.com/pipermail/neko/2010-January/002691.html http://www.haskell.org/pipermail/haskell-cafe/2009-November/068432.html So in short I guess (and don't judge me please, because I am still learning and open-minded) I am saying that I don't want the full feature sets of Perl, Python, PHP, Java, C#, etc.. Haskel's OOP model is mathematically preferable. And I am saying I want to maximize interoperability, not maximize the conflation with languages that have features that I do not want. I realize there may be some libraries that I could use in those other languages, but I also have the thought that the most sustained effort gets poured into those paradigms which generate the greatest results. I am also trying to foster a interoperability and composebility paradigms where libraries are not developed monolithically, but unsynchronized by many diverse actions. Thus more granular the survival-of-the-fittest, so that entire libraries don't die, but individual interfaces deprecate/spawn and/or the opaque underlying implementations. For example, Common Lisp COMPLEX data type could be represented as classes with overloaded operators (interfaces), instead of proliferating and conflating at the data type layer. And I think that may be the point the the NekoVM is making in its FAQ comparison to Parrot. Layers should have natural boundaries wherein they can focus on 80% of the potential functionality of the layer, and not reach out (conflate) into other layers to chase the 20%. Seems to me that the interoperability of at the common data type layer of NekoVM could be modified seamlessly to reach into binary compatibility with native C, with 20% effort. But that needs more study. -- Neko : One VM to run them all (http://nekovm.org)
