Re: dependency info

["Jecel Mattos de Assumpcao Jr." <jecel@lsi.usp.br>]

On Wed, 27 Sep 1995 22:22:00 +0100 
"ian (i.r.) woollard" <wolfe@bnr.ca> wrote:
> I ran up self to have a look around. I noticed a few things that would
> affect it as a scheme...
> 
> I took list as an example. It has: traits list, collection, ordered
> clonable, ordering, lobby, globals, default behaviour as parents
> objects.

Check.

> If you choose groups at random that would make 4-7 of the groups full
> already (you might choose to be smarter than that, by putting the
> parents of lobby in the same group...) Still you are looking at
> 7/32*15 seconds ~ 3 seconds with a naive implementation.

I agree you have to be smarter than a random distribution. Any method
in list is likely to depend on more than just the parents. I would guess
that a random distribution would fill in all 32 bits in most methods,
making the whole idea worthless. It would be better to choose groups
as collections, user interface, floating point....

> Hey, here's an idea. If you add a second, differently randomised 32
> bit tag bit field and you say that the method must match both, then
> the number of likely overlaps goes down in a square law, so if you
> have 1/4 filled to start with then you get 1/16 with two 1/64 with 3
> etc.

Ok. As long as you are not filling in all 32 bits in the first place.
But I think it is really neat how you got four times the resolution
with only twice as many bits!

> A problem with the idea as a whole is that a method doesn't only
> search self, it also searches other object's parent hierarchy... If
> the method references 4 other objects most of the groups will fill
> up. Might not be a killing problem, you need to find out how often
> this kind of thing happens. Most sends *are* to self, it *might* not
> matter.

I think this is a killing problem for randomly created object groups,
as I mentioned above.

> One other thing that you might consider is baseing tagging on the
> senders of slot names instead. Like the object dependency scheme, it
> will work most of the time, but might run slowly for some popular
> slots like 'add:'. Still, the object dependency scheme runs slowly for
> globals... When adding a parent slot, at worst you may have to
> recompile everything.

The problem here is that a method would depend on every parent slot
name used in every lookup, and that could be a lot of names ( not
quite true - there are many "parent*" slots around ). But it is
certainly an idea worth testing.

> Disclaimer: I don't *really* understand this stuff... ;-) Chris
> Chambers idea of baseing it on message lookup dependencies looks the
> best idea to me...

It probably is the best idea. My "tinySelf" is a pure interpreter
and doesn't use any of this, but I am looking for the simplest
solution so that I don't have to do much work when I get to the
compiler.

-- Jecel