User: Password:
Subscribe / Log in / New account

Parrot - the way

Parrot - the way

Posted Mar 25, 2004 18:39 UTC (Thu) by johnjones (subscriber, #5462)
In reply to: GNOME Platform Stormclouds by raytd
Parent article: GNOME Platform Stormclouds

ok so

sun does not want to open its stack machine
Microsoft CLI is closed and only part of it submited

python and perl run VERY BADLY on both of these

parrot is a register based Virtual Machine that...

o In My Humble Opinion will run Perl Python Very well

o java compiler could target

o C# compiler could target

o portable

this is a no brainer if you thinking about architecture...


John Jones

p.s. people who want to write things now should do so in python C or java
(mono is still under heavy dev and they just have what amounts to alot of demo programs and people who think they can get win32 coders into the gnome fold... really it would be nice if QT C++ AND GTK C could target parrot...)

(Log in to post comments)

Parrot - the way

Posted Mar 26, 2004 0:28 UTC (Fri) by hinoue (guest, #6949) [Link]

The operative word is "WILL". Parrot is very far from being finished and has yet to prove that it is going to replace the current Perl/Python/Ruby VMs. However, you are right that the fight over languages and libraries is a bit silly -- the fight should be over the VM.

The VM ultimately chosen should be decent target for any language. This precludes using a Java VM, IMO. CLR allows for a larger set of languages, but still isn't infinitely flexible. It has the advantage that the runtime is probably unencumbered by IP issues. The .NET libraries are a different story, but presumably people writing applications for GNOME will using GNOME bindings.

However, what is actually needed is really a subset of a VM - a portable intermediate representation along with a well-defined runtime model. This is not an new idea -- I recall that GCC people tried something similar a long time ago. It is an idea that is gaining ground among VM people today, though. VMs on modern systems are no longer seen an interpreters -- good VMs compile code, and the instruction sets of Java, CLR, and even Parrot aren't really great representations to do the kind of analysis for optimization that you would want. (Incidentally, there's only a tiny advantage in using a register based instruction set over a stack one. You've got to put the values in real registers at some point). Redefining the problem to this allows one to dismiss language support and library issues. It would also allow greater amount of modularity -- compilers would then be naturally split between the front end, which target the IR, and the backends, which target the native machines.

Unfortunately, I know of no suitable portable IR, so we are stuck with things that already exist -- Java or Mono.

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds