Rite vs Parrot: rationale?

ruby-talk
1

I’m been looking for the rationale of implementing Ruby’s own bytecode
engine (Rite) instead of using Parrot.

Here’s a summary of the information I’ve found:

[18657] (Jul 2001): first reference to Rite, 100% vapourware.
[34594] (23 Feb): <<EOF
Rite will have some kind of VM. It would NOT be Parrot, but I hope I
can prepare backend API that makes Parrot backend possible.

						matz.

EOF
It seems no development had started as of Feb 2002.
[41360] (30 May): Rite still vapourware, the API will change
[41522] (01 Jun): Rite’s development is going “pretty slow” :slight_smile:
[43967] (08 Jul): there’s a prototype implementation however
→ it’s been done between in June…
[45991] (02 Aug): its C API will not be compatible with the one in
1.6 & 1.7 (to be 1.8)

We can feel Rite is beginning to become something, but I have been
unable to find the rationale for some of the mayor design decisions
already taken; particularly the reasons behind [34594] (which was
acknowledged by Dan Sugalski as being correct without any further
explanation).

Could someone please point me to the pertinent sources? Is there
anything like the Perl Design Documents (PDDS) included in Parrot’s
source?

Thanx

···

–
_ _

__ __ | | ___ _ __ ___ __ _ _ __
'_ \ / | __/ __| '_ _ \ / ` | ’ \
) | (| | |__ \ | | | | | (| | | | |
.__/ _,|_|/| || ||_,|| |_|
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com

Sex, Drugs & Linux Rules
– MaDsen Wikholm, mwikholm@at8.abo.fi

2

I can only address part of this.

Rite is not just a bytecode engine. Rite, as I understand it, is
simply Ruby 2.0 – a significant rewrite rather than our usual
incremental change.

The addition of bytecode compilation is only one aspect of Rite.

As for Parrot, Dan Sugalski is certainly a Ruby fan and is making
sure that Parrot plays well with Ruby.

As for the VM built into Rite, I don’t know whether it has even
been specified at all. In my uninformed opinion, conceivably it
could generate Parrot code by default.

Hal

···

----- Original Message -----
From: “Mauricio Fernández” batsman.geo@yahoo.com
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Thursday, August 08, 2002 4:48 PM
Subject: Rite vs Parrot: rationale?

I’m been looking for the rationale of implementing Ruby’s own bytecode
engine (Rite) instead of using Parrot.

3

While I can’t give you Matz’s rationale for it, I can tell you why I
think it’s a good idea to not have Parrot be the back end for Ruby
2.0.

It’s not done.

If Parrot were fully functional, it’d be reasonable to talk to Matz
about having it potentially be the engine for Ruby 2.0, but it’s not,
and it definitely wasn’t at the time Matz was starting in designing
and developing Rite. He’d have been foolish to bet that what we were
building would meet his needs and the needs of Ruby based only on
some design documentation, a bit of source, and a conversation or two
with someone he’s never met.

Heck, I wouldn’t be comfortable if Matz was counting on Parrot
being Ruby 2.0’s back end at this point–we aren’t done, and the
thought that something that we screwed up in parrot development would
impact someone else is rather unpleasant. (I’d hate to think that if
I got hit by a bus before we were done that ruby’d be in serious
trouble) I don’t mind being an alternate implementation, I just don’t
want to be the primary implementation, certainly not when we aren’t
finished.

Also, while Matz is responsible soley for Ruby, I can’t be, and that
means that I may end up making decisions for the core that aren’t
necessarily in Ruby’s best interest. (Nor Python’s, nor Perl’s, nor
Scheme’s for that matter) With any engineering project of any size
there are inevitable tradeoffs, and my (self-chosen) problem scope is
larger than Matz’s so the chances that there’ll be an unfavorable
decision for some Ruby feature is greater.

Maybe when we’re done things’ll be better–I certainly have some
rather compelling reasons to get a 100% full ruby implementation
working on Parrot. When we’re done then it’ll be different since we
can look at an existing project and judge it on its merits, rather
than look at some plans and guess how things will turn out, and
perhaps at that point the decisions may change, but that’s not really
something worth worrying about now.

Finally, don’t forget the important question: “Who the heck is this
Dan guy anyway, and why should we trust him to make Ruby work?” :slight_smile:

Reasonable caution is, I think, in order. That’s only prudent.

···

At 6:48 AM +0900 8/9/02, Mauricio Fernández wrote:

I’m been looking for the rationale of implementing Ruby’s own bytecode
engine (Rite) instead of using Parrot.

[34594] (23 Feb): <<EOF
Rite will have some kind of VM. It would NOT be Parrot, but I hope I
can prepare backend API that makes Parrot backend possible.

  					matz.

EOF

We can feel Rite is beginning to become something, but I have been
unable to find the rationale for some of the mayor design decisions
already taken; particularly the reasons behind [34594] (which was
acknowledged by Dan Sugalski as being correct without any further
explanation).

–
Dan

--------------------------------------“it’s like this”-------------------
Dan Sugalski even samurai
dan@sidhe.org have teddy bears and even
teddy bears get drunk