[RFI] I suggest to remove delegation slots and PMD algorithm

[Brian T. Rice]

I must correct one fallacy here in retrospect: changing the 
implementation does not change the PMD algorithm. It is quite abstract 
and doesn't care if there is single inheritance, multiple inheritance, 
tables, or named delegates. Basically you can plug in other inheritance 
mechanisms and only have to change parts of the code.

Delegation as it is in Slate is undesirable because of its semantics, 
but that is a separate discussion.

Brian T. Rice wrote:
> I'm not really sure how to respond to this. A "ztypo" is what you would 
> call a signature or protocol, by the way.
> 
> Basically, this is a really naive optimization that would suck up a huge 
> amount of memory if we decided that it would be the "mindset" (default 
> implementation) of the system. Such optimizations should be focused on 
> very static or very-frequently-called sites.
> 
> We also have optimizations that reduce the PMD algorithm to 
> single-dispatch already (well, it was applied to the Lisp system, and 
> will be in the VM-based system soon enough), that it shouldn't matter.
> 
> Changing the memory layout does nothing for the fact that we actually 
> have multiple inheritance and have to record it.
> 
> There are known multiple-dispatch, multiple-inheritance optimizations 
> involving the use of tables, but it is well known that they are oriented 
> to static usage. They cost time to set up, and cost the run-time system 
> quite a bit to ensure that they are accurate. So, this kind of thing 
> would get applied in Slate to specialized contexts or situations, and 
> not in general.
> 
> I think, to be brief, that this would suck by comparison. :) Sorry to be 
> blunt, but there's a lot of material on this field that is better 
> already, and we really do like being able to define and test methods 
> quickly. Slate's not just a Java or C++-equivalent, it's also intended 
> for interactive, scripting-style usage. If Slate acted as you suggested, 
> I would not want to use it.
> 
> The bottom line: if you don't like the speed of the current system, 
> wait. We already have plans to speed it up, and have read a lot about 
> the various ideas already tried, and Lee has his own good ideas which 
> are helping us already.
> 
> Paul Dufresne wrote:
> 
>> I did not have enough sleep time, so maybe what I'll say won't
>> make sense, but for now it seems. I did not very well understood
>> PMD thesis, and how slate dispach optimizations works. But
>> somehow, I was thinking about an improved inspector that would
>> allows one to press S for seeing numerated slots, and choose the
>> one you want to follows by pressing the numeric key, or D for
>> showing numerated delegating slots, and allowing to follows them
>> the some way. And I was thinking about M for showing the
>> methods defined on current objects, and then I began to realize
>> that in Slate, we don't tie roles directly to the objects, but
>> through an algorithm.
>>
>> I define for the length of this message, a ztypo, as
>> a selector and an arity of arguments. If 2 methods have
>> the same selectors and the same numbers of arguments, they
>> are the same ztypo.
>>
>> PMD is a function that given a ztypo, and an array of arguments
>> (that are objects) returns a list of methods defined on these
>> arguments, in the most appropriate order (slate says that it
>> is the arguments from left to right, and if this criteria alone
>> results in more than one methods, that we should order these with
>> delegation 'awayness'.
>>
>> To do this, Slate implementation use a sophisticated
>> PMD algorithm, and delegation slots.
>>
>> The question I ask, is why to use delegation slots and sophisticated
>> algorithm, when one could simply store in memory (or image file),
>> for each ztypo, the list of methods in the order we think they
>> should be called?
>>
>> That is, at the begining these list of methods would be empty.
>> Then each time a new method is defined, they would be added to the
>> method's ztypo's list at the correct position.
>>
>> Each time the garbage collector remove an object, we would erase
>> every methods from the ztypo lists that was having that object
>> 'defined' on one of their arguments.
>>
>> Each time a delegation slot (really just a concept in programs,
>> should not be part of the implementation) is changed, we would
>> adjust the order of every ztypo's lists affected by it.
>>
>> Calling a method would be fast, defining methods and deriving
>> objects would be slow (the opposite of what we have now).
>> But since most programs do almost all their definitions and
>> derivations at the beginning, and then while executing, just dispatch
>> this would be fast and appropriate.
>>
>> --Paul

-------------- next part --------------
A non-text attachment was scrubbed...
Name: water.vcf
Type: text/x-vcard
Size: 208 bytes
Desc: not available
Url : /archives/slate/attachments/20040825/db4e32af/water.vcf