> On Fri, Aug 19, 2005 at 07:37:41PM +0200, Nicolas Cannasse wrote: >> I released a few days ago the Neko intermediate language at >> http://nekovm.org . In the FAQ I'm comparing Neko to LLVM / C-- and Parrot. >> According to a mail sent to me by Leopold Toetsch I got some points wrong >> when trying to generalize theses three frameworks in the same category, >> which of course is true since Parrot is more "high-level" than the two >> others and still I guess more "low-level" than Neko. > > I'm not sure how you mean by Neko being of higher level than Parrot; for all > I can see they offer pretty similiar abstractions, with Parrot additionally > providing an object model (including RTTI for user-defined types), > namespaces, and first-class continuations.
My knowledge on Parrot is not very big, but looking and PIR samples on the website I can see registers, register types, goto loops and the syntax seems like it doesn't allow nested expression. PASM is even lower level since you write directly "opcodes". Also, I don't like the fact that the whole standard library is inside the bytecode language (having IO opcodes does not really make sense for me). Neko OTOH is making a clear distinction between source code, builtins and libraries. >> I would like to know if some people would be interested in studying a way >> to run Perl6 programs on Neko, or which would be the problems in trying to >> do so, since Neko - as Parrot - is intended to provide a common runtime for >> several languages. > > Cool. I'd like to direct further perl6-on-neko mails to perl6-compiler > (Cc'ed), if that is okay with you. Thanks, I subscribed to both so I should get all emails. > The most crucial thing I see from Parrot is the built-in support of full > continuations; most other things Perl 6 needs can be faked one way or > another, but a CPS-transformed runtime on another VM is more difficult to > reason about than a VM that is built around CPS. Yes I agree with you, continuations should be handled directly on the VM side. Neko have true closures but not yet continuations, I'm planning to add them soon. > Also, while to me PIR is much more primitive and considerably harder to work > with than the Neko language (which at least has nested expressions), at least > the builtin types and functions are enumerated (with documentations), which > makes a code generator much easier to write. You mean you have documentation and builtin list at runtime ? > It would be great if some kind of documentation can be generated > automatically, akin to how Parrot generates .pod files from ops/*.op, about > the semantics of various builtin (neko/vm/builtins.c) and library (neko/lib/) > primitives. Without that information it is not feasible for us to > source-dive constantly to target the runtime. Yes what is needed is a literate programming tool. If I follow your thoughts, it might be interesting to extract type informations from C sources and build a kind of "type library" that would be accessible for generators. That's an cool project, but it's orthogonal to Neko design, although the regularity of the Neko API helps here to extract useful informations. >> I guess that some LambdaCamels here will be interested to know that the >> Neko compiler is written in OCaml and than I'm planing to add the NekoML >> language that would bring a ML type system language running on the Neko >> runtime, the goal being to be able to rewrite the Neko compiler in NekoML. > > That would be great. It would be even better if F-sub can be translated to > NekoML in a type-directd fashion somehow, since that will safe a lot of time > here. AbsIL-to-NekoML would be useful, too. > > Thanks, /Autrijus/ I'm not planning F-sub rightnow, but in house we currently have Motion-Types running on Neko, which is already quite nice ( see http://ncannasse.free.fr/index.php?m=200412 ). I don't know about AbsIL, could you tell me more about it ? Thanks, Nicolas
