Re: [Cardinal-dev] RubyInRuby parser/compiler

[David Robins]

> 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.

I prefer ruth, but maybe I didn't look at that parser.  What's it written
in?  Ruby or C?  Does it generate an AST?

I have written some code using Ruth that generates IMCC code, and I stopped
precisely because I needed to clarify some issues with operators and needed
OO support (see perl6-internals).

> 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")

Well, actually I don't think it's that bad, since if we invoke the Parrot
"add" operation, then it can call the PMC's add function and provide various
shortcuts, perhaps not having to do a method lookup if the lhs is, say, a
RubyFixnum or a RubyInteger.  Only the RubyObject PMC need invoke a '+'
method.

> 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 :)

True.

> Operator overriding also needs a standard naming convention for all
> languages. In ruby it's simply done like this

When IMCC adds object support one would hope it wouldn't place any
restrictions on method names, so that everything is legal (except embedded
nuls), including '+' etc.

> 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.

Unfortunately which '+' operator is used is going to be dependent on the
lhs, and typically it'll call get_whatever on the RHS to add/concatenate it.

This leads to problems like: RubyInteger + RubyFloat = RubyFloat (since we
can make it a special case and check the vtable), but RubyInteger +
SomeOtherUnknownExtensionFloat = RubyInteger (since by default RubyInteger's
add will call get_integer and the other float will return an integer
representation).  Of course if the float is on the lhs all is well... which
sort of messes up the idea of '+' being commutative.

It might be a good idea to have PMC flags for "has native integer value"
"has native float value" and "has native string value" (or "is integer" "is
float" "is string" "is object") etc.  Realistically, there are going to be a
very small number of "basic" (non-aggregate) types, but each language will
need to define its own with their own nuances (such as RubyInteger _never_
being logically false).

Dave
Isa. 40:31