Re: [Cardinal-dev] RubyInRuby parser/compiler

[Dan Sugalski]

At 4:54 PM +0100 1/1/03, Erik Bågfors wrote:
> Hi All!
>
> during the holidays I played around with the ruby-parser that can be
> found in the ruby cvs under lib/metaruby/ruby-parser.
>
> My experiences so far has been great!  I really think we can use this
> baby to write the parrot compiler.  If we only had objects working in
> parrot I think we could get very far in a short time.
>
> One think I noticed when started to think about what it means that
> EVERYTHING is an object is that everything has to be objects :)
>
> For example, the following ruby code
> a=1+2
>
> Will have to be quite long.  What we have to do here is
> * Create a object of type "Fixnum"
> * Set that object to the value 1
> * Create another object of type "Fixnum"
> * Set that object to the value 2
> * lookup the subrutine "+" in the first object (or maybe it's enough to
> look that up in the class "Fixnum")
> * put the objects on the stack
> * call the sub
> * pop the answer into "a"
>
> Am I correct so far?

I bet it's more like:

* Add constant 1 and constant 2
* Put the result into a

You don't want to create empty objects and assign values into them at
runtime to do constants, as you'll run into problems if the class
you're assigning into has overridden assignment operators. (Assuming,
of course, that it's not supposed to happen that way) This does mean
that we have to get Parrot's PMC constants working, but... :)

Does Ruby allow constant folding by chance?

> Anyway, I really feel that we can't do very much more than play with
> compilers/pmcs/whatever until parrot has real object support.  Ruby is a
> very oo language :)

Soon. By next thursday.

> Operator overriding also needs a standard naming convention for all
> languages.

Nope, actually, it doesn't. Operator overloading is a compile-time
thing, as it only happens at compile time, so as long as the compiler
for the language you're working on knows what overloading operators
look like, you're fine. (And if it doesn't you're in huge trouble...
:) Not, mind, that I would mind a standard, it's just not necessary.

The one potential spot this could be an issue is if you're doing
runtime method assignment, changing a method by name at runtime. In
that case, it'd probably be best to have the class namespace be an
active hash, and when you assign into it the class namespace does the
right thing based on the rules of the language owning the class.
(This does have issues when there are multiple languages with
different rules contributing methods, but we can deal with that later)

> I for one wants to be able to use the operators in a python-object from
> a ruby-object.  Of course. this is way into the future right now.

This is definitely going to happen--when you do:

   c = a + b

it'll do the right thing if the add method is overridden in a (or
potentially b) regardless of what language created a's class, or is
executing that statement. That's what the vtables for PMCs buy us,
which is a Good Thing.
--
                                        Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
address@hidden                         have teddy bears and even
                                      teddy bears get drunk