Re: Parrot and Neko

19 views
Skip to first unread message

Autrijus Tang

unread,
Aug 20, 2005, 1:09:43 AM8/20/05
to Nicolas Cannasse, perl6-i...@perl.org, perl6-c...@perl.org
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.

> 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.

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.

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.

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.

> 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/

Nicolas Cannasse

unread,
Aug 20, 2005, 9:39:45 AM8/20/05
to perl6-c...@perl.org
> 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

Leopold Toetsch

unread,
Aug 22, 2005, 10:26:07 AM8/22/05
to Nicolas Cannasse, perl6-c...@perl.org
Nicolas Cannasse <ncan...@motion-twin.com> wrote:

> 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).

These opcodes will be removed and replaced by library functions.

> Thanks,
> Nicolas

leo

Reply all
Reply to author
Forward
0 new messages