[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Diversity - existence, value, and pursuit.

On Saturday, December 1, 2001, at 01:27 PM, Adam Turoff wrote:

> On Sat, Dec 01, 2001 at 09:10:02AM -0800, Terrence Brannon wrote:
>> Given that there are Scheme implementations which execute as fast
>> a C and given that Scheme is much more readable that it appears
>> that Parrot will be, what is wrong with Scheme serving as the
>> "virtual machine" for Ruby, Perl, Python?
> Um, nothing.  Are you interested in writing that VM?  :-)

I certainly can see the advantages of it... it will be much 
easier to generate Scheme code than Parrot code.

Also, I just finished going thru Simon's perl.com article on Parrot:


and am wondering how an interpreted virtual machine will execute 
as fast as C. One of Larry's design goals was to have Perl 6 run 
as fast as C.

> However, Parrot isn't expected to be the only platform that 
> Parrot-targeted
> languages can run on -- Java's VM and the CLR also come quickly 
> to mind.

What is CLR?

> If you're seriously interested in having a VM for 
> Perl/Python/Ruby, there's
> nothing preventing you from writing a Parrot VM in Scheme.

That is not what I am suggesting. I am suggesting that all the 
efficiency, readability, and hand-tunability that one would want 
in a virtual machine is already present in Scheme interpreters. 
And to meet the "fast as C" objective, compile to C with Bigloo 
and you are done.

 From what I have seen/read of Parrot, it will have to work hard 
to equal the efficiency of Scheme. It will not be as readable or 

> The advantage is that's *all* you'd need to write.  
> Reimplementing Perl,
> Python or Ruby in Scheme *today* would be much more difficult 
> proposition.

I'm not quite clear on what Parrot is going to buy the 
Perl/Python/Ruby/Java people. Is it so that large programs can be 
constructed out of bits of each of these by coordinating their 
interaction via the Parrot virtual machine?

And Perl 6 is going to be a rewrite from the ground up. At this 
stage, it is still feasible to generate Scheme instead of Parrot 
and save yourself some trouble. Or hell, what is wrong with RTL, 
the "bytecode" created by gcc? And have the Python and Ruby 
people bought into changing their backend to generate Parrot 
code? And why would they want to generate code for some alpha 
(read: "bug-prone") framework when it offers no advantages over 
Scheme for the same purpose?

> (I note that there aren't any JVMs written in Scheme, either.)

Clearly Bigloo scheme has Java and C connectivity but I guess 
this not what you are talking about. And Perl already has Java 
connectivity too. Perhaps you can clue me in on what Parrot is 
going to achieve that has never been achieved before *and* at the 
same time tell me why such an effort must be undertaken from the 
ground up instead of leveraging Scheme for that effort's purposes.