[snip] >> 2) In particular, it is difficult to differenciate beetween the >> language and the libraries >> >> Could the Neko community expand on this? I find our core and our >> libraries well differentiated. We even have an infrastructure like >> Perl 5's CPAN, called Plumage [3], which allows you to install and >> download any Parrot plugin/library from the net. > > Maybe we should have tell "standard" libraries. As for as I know all PMC > are pretty core structures which have their own API which cannot be > easily modified. > > Neko provides only "raw types" as part of its specification, with a very > limited core API (http://nekovm.org/doc/view/builtins), everything else > being made in separate optional libraries.
IMHO, this is the most important difference and needs to be elaborated and explained better: http://lists.motion-twin.com/pipermail/neko/2010-January/002703.html http://lists.parrot.org/pipermail/parrot-dev/2010-January/003679.html Point being that conflation of sub-typing-- e.g. implementing a COMPLEX type as a PMC in the VM layers instead of as an interface (class) at the HLL layer-- fights against nature's ability to form complex diverse systems from orthogonal ("simple", "raw", "core") building blocks: http://lists.motion-twin.com/pipermail/neko/2010-January/002709.html And I am also proposing that NekoVM should add support for interface declarations on builtins. Then HLLs can scalably interopt, by exposing their interfaces in common data type layer. I do not see how you can possibly get scalable interoption without? Otherwise, either interfaces are not used (and thus runtime exceptions complexity profileration and interoption failure) or HLL need to write N^2 translation layers to each others' higher level interface/types. Do we have any experience or is HaXe the only HLL that outputs Neko in the wild? HLL = high level language -- Neko : One VM to run them all (http://nekovm.org)
