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

[Brian T. Rice]

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/20040804/58f05458/water.vcf