Re: [Fwd: Re: more parrot-questions..]

>Sorry to send this mail to you in private but I did send it to the
>ruby-talk-mailinglist and hoped that you would answer it. Feel free to
>ignore this mail if I'm taking up your time.

Not a problem, and I've Cc'd it back to ruby-talk. It's been a busy 
few days--got DownSized (tm)--and I'm digging out of a huge wad of 
mail moved over to a new system. Sorry 'bout the delay.

>I've been trying to build some ruby-classes into parrot and I thought it
>would be really cool to have some ruby-classes in 0.0.4 :)

Absolutely! I need to get the reference type written, then, so 
ruby/python assignment semantics work properly.

>Anyway.  I'm having some problems understanding how to inherit from a
>base class so I would appreciate if you could answer at least that part
>in the attached mail.

Will do. You won't like it. :)

[Major header snippage]

>On Thu, 2002-01-03 at 23:14, Dan Sugalski wrote:
>  > At 11:15 PM 1/3/2002 +0900, Erik B虍fors wrote:
>  > >How is object-orientation going to be done in parrot??
>  >
>  > It's generally going to be left to the various classes. Variables all have
>  > a "dispatch to named method" entry in their vtables, which Does The Right
>  > Thing. Which, presumably, includes dispatching to the actual 
>method somehow. :)
>  >
>  > So if your code does:
>  >
>  >     someObject.hey_look_a_method
>  >
>  > that gets translated, more or less, to:
>  >
>  >     find_lex P0, 0, 7 # Assuming we're the seventh lexical in
>  >                        # the current scope
>  >     call_method P0, "hey_look_a_method"
>
>And here I can show my ignorance again by not knowing what the "seventh
>lexical in the current scope" means :)

I presume I don't need to explain the lexical or scope bits. If I do, 
that's OK.

Since all the lexicals are known at compile time, we can cheat and 
not have to look things up by name. (We can still do that, but we 
don't have to) One of the properties of the hashes used to hold the 
lexical variables is that the names come out in the same order they 
went in. So if the first name in the hash was "Foo", if you said 
"Gimme the value for the first entry" you'd get back the value 
associated with the name Foo.

That means the interpreter doesn't need by-name lookups at 
runtime--if it knows it needs Foo, and Foo's the first lexical, it 
can skip the name lookup, which saves us some time.

>How far off in time is the "call_method"-parrot-op? When can we start
>doing real implementations of the ruby-classes?

We need subroutines and packages to get it implemented. We need more 
than that to do it efficiently, but that's all a SMOP.

>  > >If I use a perl-module from ruby under parrot and it creates a new
>>  >object I should be able to use that from my ruby-code in the same way as
>>  >if it was a ruby-object, right??
>>
>>  Right.
>
>According to what you write below, not really..

Well, sort of. :)

>Sure, we can use the object like it was a ruby-object but it's not
>really a ruby-object since it doesn't inherit from Object.

Right. The inheritance tree's different--heck, it might even be a 
real tree if it's a perl object.

>If I add a method to the Object-class it will not be in
>python/perl-objects which means we are not really running in a
>ruby-world.

From that perspective, you're quite right. Depends, I suppose, on 
whether you consider the object hierarchy a part of the language, a 
part of the core library, or a quirk of implementation. For me, as 
the engine designer, it's in the core library category.

>Personally I think the advantages of interaction between the languages
>outweighs the disadvantages.

I think so too. :)

I think, in practice, that it won't be a problem, but then I'm 
writing at what's essentially the assembly language level so my 
viewpoint's a bit skewed.

Also, this is only an issue with cross-language objects. If you stay 
completely within Ruby code you'd never know.

>  > I don't know if python's got a base class, but if it does then python
>  > objects only have that base class, not base and Object.
>  >
>  > As far as the interpreter's concerned, there's really no single superclass
>  > that provides any methods or behaviour. (Well, unless you count the "you
>  > lose,  program dies" routine which'll get filled in for any vtable entries
>  > you haven't supplied, but the vtable's a bit below methods and such.
>  >
>  > If Matz, Larry, and Guido (or some subset of the three) get together and
>  > agree on a common set of default methods, then I'll make sure they get in
>  > and implemented. (It's not my job to define behaviour, just to design and
>>  get implemented the engine that provides the behaviour other people define)
>
>I don't think that is going to happen since perl is not really object
>oriented at all (sure you can have object but still :) ), python is
>half-way OO (some things are not objects/classes) and ruby is fully OO.
>There is no way to do this without turning perl and python into
>something alot more like ruby or turning ruby into something other than
>ruby.

If you look at things right, perl really is completely OO. (You'll 
need to stand on your head) For perl 6, it's much more so as part of 
the language itself, and completely so for the implementation. Almost 
completely by accident, but it was such a nice accident in terms of 
performance that it's here to stay.

>  > >BTW, thanks dan for answering the other questions I asked :)
>>
>>  No problem--glad to answer anything I can.
>
>Good,  Then I'm giving you some more questions now :)
>
>I been messing around with parrot alot lately and it's really really
>really cool.  I WANT ruby running under this so I was thinking about
>starting the whole thing.  I implemented a small RubyObject-pmc. This
>was really easy since there was lot's of examples to build on.  A
>RubyString, RubyNumeric, RubyInteger, RubyFloat and a few others should
>also be real easy to create but I didn't find any good information how
>to inherit from the RubyObject type.  There wasn't any documentation and
>no examples but since there is a default class that can be inherited
>from I guess it's implemented somehow. You have more info for me?

Some, but not much.

There's two bits here. The first are (as far as Parrot's concerned) 
generic methods and such, which live in the class' namespace. They 
get called with the call_method vtable, and we'll probably just do a 
dynamic by-name lookup and indirect dispatch. Nothing fancy there at 
the moment, though it can get fancier later. (Got some ideas and some 
pointers at ways to optimize this sort of thing)

For the specific class of methods that Parrot considers 'core', or 
the things that populate the vtable, there currently is no dynamic 
inheritance. The vtables are populated with pointers to real 
functions and that's it. Parrot'll keep a class hierarcy in, and 
it'll know what's a child of what class. When you change a parent 
class' methods such that its vtable changes, Parrot will 
automatically refigure the vtable for the child classes (it's just an 
array of function pointers after all) with pointers to the new 
routine(s).

I'm going to go and set some of this stuff in wet concrete, BTW. I'd 
not given the details a whole lot of thought until now.

>Writing as much of the ruby-implementation as possible in ruby itself
>would of course be very cool.

True. I'm not much of a language purist in that sense, really--I'll 
mix C and perl (or ruby, or python, or scheme, or, heck, Fortran) 
based on both what makes the implementation easier and what makes it 
faster. Parrot does have some bits that are something of a pain for 
the folks writing back-end stuff, but it should speed up actual 
program runs, so the pain's worth the gain.

>The obvious way of doing this is to write
>some objects and methods in c and then write the rest in ruby and
>compile that ruby-code into parrot bytecode, then include that bytecode
>into every ruby-program.

Sure--it'd just be part of the core ruby library for Parrot.

>Of course this will not be as fast as a
>c-version of everything.  I saw that there is a pbc2c-converter in the
>parrot distribution.  Would it be possible to use this to "get the best
>of both worlds"?  That is, the ruby language but the c-speed?

Absolutely, sure.

>Will there be some way of automatic convertion between types??  What I
>mean is this, let's say you have this wonderfull function in perl that
>takes a PerlString and returns another PerlString.  I want to use this
>from ruby and would really like to have RubyStrings for everything.
>Would automatic conversion between these types be something that's
>good/possible?

The core datatypes the engine really cares about are platform 
integers, platform floats, bignums (basically an indefinite-precision 
base-10 number), and parrot strings.

Parrot strings are a character buffer combined with encoding, 
character set, and locale information on the string. They're meant to 
be programming-language neutral. (A Unicode string in UTF-32 with a 
Finnish locale doesn't care whether it came from Perl, or Python, or 
Ruby)

There's not actually a PerlString type as such--the PerlString class 
is mis-named. It's a subtype of the perl scalar, for scalars that 
currently have only a string in them. Since perl scalars can be 
strings, integers, floats, or any number of other things, it makes 
sense to have specialized subtypes for those cases where it has 
*just* a string, or an integer, or a float. No need to check flags 
that way, no need to test and branch, and thus no need to blow your 
CPU pipeline a few times before you get to doing the real work.

I get the feeling the explanation's missing a bit, so prompt me for 
the bits that are unclear and I'll explain better.

-- 

					Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
[e-mail]                         have teddy bears and even
                                       teddy bears get drunk