[Cardinal-devel] Cardinal Design Documents - Code Generation

[mark sparshatt]

Dan Sugalski wrote:

> At 9:33 PM +0100 8/9/04, mark sparshatt wrote:
>
>> Dan Sugalski wrote:
>>
>>> At 8:44 PM +0100 8/9/04, mark sparshatt wrote:
>>>
>>>> h1. Code Generation
>>>>
>>>> h2. Method Name Munging
>>>>
>>>> Parrot doesn't support symbols within function names so it's
>>>> neccessary to modify the names of some methods.
>>>
>>>
>>>
>>> Bah, we need to fix that. (Though it may be worth it to alias these 
>>> to the 'standard' vtable method names, but that's a separate issue)
>>>
>> I assume that using the standard method names will make 
>> interoperating with other languages easier, in which case it'd 
>> definitely be a good thing.
>
>
> Yep. What we need to work out is a way to have the method in the 
> namespace in two slots at once. You'd want to find the method when 
> looking for '+' if you had ruby code and were introspecting, while 
> parrot needs it elsewhere. (And there's the argument that it ought to 
> appear in *all* slots of the namespace that correspond, so perl, 
> python, ruby, scheme, haskell et al code can find it. I think we 
> shan't go there right now, though.
>
>>
>>> We'd talked about having a special block parameter for just this 
>>> use, but Larry argued me out of it. I'm all for being argued back in 
>>> if you want. :) Alternately we can come up with a good Plan B here.
>>>
>> Having a special block parameter would be handy. It just occurred to 
>> me that assuming that the first parameter is either a block or nil 
>> will cause problems when other languages call Ruby methods.
>
>
> Yeah. Hrm. Okay, could you throw a message at perl6-internals at perl.org 
> detailing what you need, even if it's really trivial? That way a) I 
> won't forget and b) It'll be coming from someone handling one of the 
> first-class languages so it'll be easier to deal with.
>
Will do

>>>> h2. Modules
>>>>
>>>> h3. Implementing
>>>>
>>>> Modules need to be implemented using a specialised version of the
>>>> class PMC which can't be instantiated.
>>>
>>>
>>>
>>> Is that the only difference between a class and a module? (Not being 
>>> able to instantiate an object of the class?)
>>>
>> The two differences are
>> 1: Modules can't be instantiated
>> 2: Classes can't be included in other classes, they can only be 
>> inheritted from
>
>
> Ah, OK. Fair 'nuff, that'd be, hrm, overriding the new vtable slot for 
> the module to pitch an exception. Doable easily enough, I think.
>
The behaviour in cRuby is to pitch a NoMethodError exception

>>>> h3. Including
>>>>
>>>> This should work the same way as cRuby. Create an annomynous class
>>>> which references the module, then twiddle the inheritance for the
>>>> including class so it inherits from the anomynous class.
>>>
>>>
>>>
>>> Or alternately just use MI when building the class, so if you had 
>>> class C which was a B and included A, then its parents would be B 
>>> and A.
>>>
>> The problem with using MI is that under Ruby at the moment if you run 
>> the following code
>>
>> Module A
>> end
>>
>> class B
>> end
>>
>> class C < B
>> include A
>> end
>>
>> p C.ancestors
>>
>> this outputs
>>
>> [C, A, B, Object, Kernel]
>>
>> I don't know if anything will break if this isn't the case, but it'd 
>> be safer to stick to the cRuby semantics.
>
>
> Ah, I see. Can modules have parents? Something like:
>
Yes, modules can include other modules.

>   Module A < B
>
>
> or
>
>    Module A
>    include B
>
> ?
>
It's the second

>
> Either way using MI at the parrot level's the right thing, only you 
> get an anonymous subclass. Kinda, sorta. (Since I presume 
> instantiating an object of class C really gets you an object of the 
> anonymous sublcass which was made from C, right?)
>
No, you get an instance of C. Just now rather than inheritting from B it 
inherits from the anomynous class, which inherits from B.

Using MI would be simpler as long as we can ensure that with this code

module A
  def meth
  end
end

module B
  def meth
  end
end

clas C
  include A
  include B
end

C.new.meth

it's B's copy of meth that gets called rather than A's

> We don't expose ways to really, really mess with a class' inheritance 
> hierarchy. I think I'll throw in a todo item for that.
>
>>>> h2. MetaClasses
>>>>
>>>> Classes in Ruby are also objects. Parrot doesn't currently have
>>>> support for metaclasses
>>>
>>>
>>>
>>> Bah. Let's fix this too. I'm fuzzy on metaclasses, unfortunately, as 
>>> I'm not a big OO guy. Time to change that, I guess.
>>>
>> The best explanation I've read, from a Ruby point of view, is the one 
>> in programming ruby http://www.rubycentral.com/book/index.html
>
>
> Argh! Another book I *must* buy! :) If you've one of those "I get a 
> cut of this if you buy it from my special clicky-link" URL handy (I 
> don't much care for whom :) I'll use that, otherwise I'll take a trip 
> to Powell's or Amazon later.
>
For the moment either Powell's or Amazon is the best place.

Though in the next few months the second edtion will be coming out and 
you'll be able to buy that directly from the writers at 
http://www.pragmaticprogrammer.com/

>>>> h2. Singleton Classes
>>>>
>>>> Ruby handles adding methods to an individual object by creating an
>>>> anomynous singleton class which inherits from the objects class and
>>>> then changing the object to be an instance of this class.
>>>
>>>
>>>
>>> Which should work for Parrot too, though we lack some support to add 
>>> methods to class objects.
>>
>
> And I need to put this on the todo list too, before I forget.