From: Dan Sugalski Date: 2002-01-26T08:17:11+09:00 Subject: Re: [Fwd: Re: more parrot-questions..] At 4:56 AM +0900 1/23/02, Erik B�gfors wrote: >On Fri, 2002-01-18 at 05:11, Dan Sugalski wrote: > > >> >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. :) > >You're right :) Such is life, alas. :) >[LOT'S OF STUFF CUT] > >> >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. > >SMOP? Simple Matter of Programming. You know, the things you think are trivial and then, after three days of non-stop coding find yourself with reams of code that still don't solve the problem. :) > > >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. > >I understand. For me as a user of the language it's one of the things >that makes it so great and therefore very important. Absolutely. And from within all-Ruby code it'll work like that. When you go cross-language, though, whether it's Ruby/perl or Ruby/Fortran, you'll find yourself stuck with some compromises. I'd like it to be otherwise, but there's not much for it. Nature of the beast--there are always engineering compromises. > > Also, this is only an issue with cross-language objects. If you stay >> completely within Ruby code you'd never know. > >It should be quite easy to "wrap" for example a ruby-class (with objects >and all) in ruby with minimal code-bloat. Sure, and in that case the person doing the wrapping will see the nasty bits, but the regular user won't. It's when you use the code from other languages directly that you'll see the conceptual mismatches a bit. > > 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 > >I prefer to keep my feets on the ground instead of my head :) Fair enough. Things aren't completely OO at the interpreter level either, but that's an appropriate thing. (The hardware we're operating on isn't either, and the interpreter gets to bridge the gap between the metal and the high-lelvel code) > > 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. > >So should I understand this as "it's not implemented yet but it will >rock once it is" ?? And don't forget "the design's changed for the better because of Ruby". > > 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) > >>From parrots point of view I guess that's true. But consider the >following code > >=== PYTHON CODE ===== >def python_method() > return "foobar" > >=== RUBY CODE ==== >str = python_method() > >==== END ==== > >From the ruby-codes point of view. What is the python_method >returning? If it's a string from pythons point of view one would use >str.upper() to convert it to uppercase. If it's a string from rubys >point of view you should use str.upcase. > >If I understand everything correctly the variable "str" will actually >hold a python-string and have to use pythons methods for working with >it. Is that correct???? Unless someone's defined automatic translations between the methods, then maybe. Depends on how things get implemented under the hood. At the moment there are no case-folding entries in the vtable, so you'd probably end up with something like that. There are some optimizer tricks that'll make it work if .upper and .upcase haven't been overridden somewhere along the line. >What I'm asking is if it should make sence to convert between ruby's and >python's string-type (as an example). Oh, almost undoubtedly. Ruby and Python strings (perl ones too, for that matter) have higher-level semantics than parrot's strings. Everyone should use the core parrot capabilities to do the ultimate case folding, since otherwise you need to write your own case folding stuff and that's a pain. > > 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. > >I think we are on two different levels here. I'm looking at things from >a ruby's viewpoint and you are looking at it from parrot's. Which is fine--we get to meet in the middle. I'm in a position to build a good solid foundation and provide tools to build on, which is what I'm trying hard to do. From there it's a matter of working out the interactions, conversions, and standards between the languages. (I know I need to provide some automatic data conversion code--that's become pretty obvious, which is fine) -- Dan --------------------------------------"it's like this"------------------- Dan Sugalski even samurai dan@sidhe.org have teddy bears and even teddy bears get drunk