Re: [Cardinal-dev] RubyInRuby parser/compiler

[Dan Sugalski]

At 1:29 PM +0100 1/4/03, Erik Bågfors wrote:
> On Fri, 2003-01-03 at 23:36, Dan Sugalski wrote:
>
> >  >>  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)
>
> Don't know about constant folding...

I'll go ask Matz.

For those following along at home who have some question as to what
"constant folding" is, it's when the compiler looks at constant
expressions and evaluates them at compile time. If Ruby allows
constant folding, it would mean that the compiler could turn

   a = 1 + 2

into

   a = 3

since 1 and 2 are both constants, and thus the addition can be
evaluated at compile time, since 1 + 2 normally equals 3. Now,
whether this is valid in Ruby is a separate issue, since the integer
constant classes could potentially be thumped at runtime, before the
expression is gotten to.

This is a common optimization in more static languages, such as C,
but may not be valid for Ruby.

>  > 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.
>
>
> Ok, but what happens to language-level objects. I assume that all
> objects are not PMC's? And vtables are only for PMC's right? (as you can
> see I know too little about this)

Same thing. Each language-level class is a separate PMC type, with an
associated vtable that goes with it. So all language level objects
are PMCs, and all language-level classes are PMC classes.

>  > >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.
>
> Wait until the "normal" objects are in parrot.  Then I'd love a document
> on this :)

Will do, promise.
--
                                        Dan

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