[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Cardinal-dev] RubyInRuby parser/compiler
|
From: |
Dan Sugalski |
|
Subject: |
Re: [Cardinal-dev] RubyInRuby parser/compiler |
|
Date: |
Fri, 3 Jan 2003 17:36:08 -0500 |
At 10:10 AM +0100 1/3/03, Erik Bågfors wrote:
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??
Oh, you do. While the addition is of two constants, they're ruby
integer constants, with whatever behaviour is appropriate for them,
so the Fixnum addition method will get called. (I assume Ruby doesn't
do constant folding)
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.
Never said they wouldn't be. There won't be one forced universal
constant type, since that's untenable for all the languages we're
looking at. Ruby code will have different constant types than
perl/python/java/C#/whatever does, which is fine.
> 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 :)
Heh. Now I just have to follow through. :)
> >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.
Ah, but in the Parrot case, this is universally:
b->vtable->add(b, c, a)
All the overloadable operators have a slot in the PMC vtable. Each
language has its own name to vtable slot mapping for its classes, so
when you add a method that matches the language's overload list, it
fills in the right vtable slot.
> 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?
You can change the vtable methods in a PMC's class at any time.
There's a 1-to-1 mapping of language classes to PMC classes.
Also, don't confuse vtable methods with general object methods.
vtable methods are a fixed set of methods that we cache for speed
reasons, while general object methods are looed up in a more general
but slower way. It's a speed thing. :)
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 :) )
I think I'm not explaining things well. I better put together a
bigger document on this.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
address@hidden have teddy bears and even
teddy bears get drunk