Re: [Cardinal-dev] RubyInRuby parser/compiler

[Erik Bågfors]

On Thu, 2003-01-02 at 08:55, Dan Sugalski wrote: 
> 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

Well.. what happens if we have the following code then??

class Fixnum
  def +(val)
    puts val
  end
end

a=1+2

that will acctually output "2" in ruby.  How can that be done without
creating objects and looking up the "+"-method??

Also, the following code is not strange in ruby
a = -1.abs()

So we need to view constants as full objects.

The fact that the JRuby-guys did it this way also convinces me.


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

Really?? That's too cool :)


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

Please explain this for me again!

In the ruby example
a=b+c

is exactly the same thing as
a=b.+(c)

the python example:
a=b+c
is exactly the same as
a=b.__add__(c)

So if I call a python-object from ruby I need to use the __add__ method
instead of the +-method.

So.. in this case the ruby-compiler needs to know how to call the python
__add__ method when it sees a + used with a python-object.  That's
messy.

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

But can you override methods in a pmc anytime?  I thought PMCs where
somewhat static.  Also, can you add methods to a PMC?  Will PMC's be the
only objects that exists in parrot?

I think I'm missing out on something obvious since Dan seams to have a
different view on things (and he knows parrot alot better than I do :) )


/Erik

-- 
Erik Bågfors               | address@hidden
Supporter of free software | GSM +46 733 279 273
fingerprint: 6666 A85B 95D3 D26B 296B 6C60 4F32 2C0B 693D 6E32