Parrot and GCC (Was: Re: Perl, Python and noo perl SEC: UNCLASSIFIED)

Jeremy jepri at webone.com.au
Sat Apr 6 03:26:49 EST 2002


> > Some of the tricks that perl does can only be done with some kind of
> > virtual machine backend.
> 
> Just to prove my cluelessness about this, so how does gcj work then?
> Surely Java requires a virtual machine also?  Hence, something similar
> could be done for Parrot if it was truly necessary.

Java is a statically typed language.  If I have my compiler theory 
right, this means that the compiler can plan how to allocate memory for 
variables before the program is run.

However Perl and Python are dynamically typed.  The perl compiler has 
no way of knowing how many, if any variables the program will use, or 
what type they are.  So memory-management routines that would normally 
be in the compiler have to be in the run-time libraries.

Any attempt to write a compiler for perl (or python) will result in a 
compiler that produces programs that are really just an interpreter 
with the program included in the file somewhere.  Although it would 
annoy you no end to admit it, perl (and python) are very advanced 
languages, and there is no direct C translation of many perl programs.


> 
> > The other reason is that the parrot team want to be able to have
> > frontends for Python, Java and C#.
> 
> GCC has the goal of supporting multiple languages also.  So why not
> join
> forces and create the one development suite that can deal with
> anyone's
> language of choice?

because gcc just can't cope with all languages.  If you can't translate 
a language into C, you can't compile it with gcc.  Perl doesn't even 
have a context free grammar to work with.



> > There is an archive of relevent discussions at perl.org where the
> > design team defend things like their choice of VM, etc.
> 
> I think that's more to do with the choice of moving to Parrot in perl6
> over not doing it at all, and plugging along with the current system.

It's important to note that from a usrs perspective, perl will not 
change at all.  The changes are all about how perl works, how it is 
ported, etc.  Perl6 will have a full compatibilty layer for perl5.

There will also be a new language, called perl6, but you don't have to 
use that if you don't want to.






More information about the linux mailing list