Marcel Weiher wrote:

>> I didn't develop it for speed, but in fact to make the woven code more
>> readable: the original methods are so small and generic that it's
> very hard
>> to see what actually ends up being done in a specific case.
> 
> Hmm, is that more readable?

Yes, working with aspects yields a rather large number of small, generic
pieces that are assembled in various combinations to yields different
specific wholes. Take the example I gave:

 ^Representation store: ((Xform inverseOfMessage: message) sentTo: Other
other)
     ==> 
 ^ Representation store: (message sentTo: other)
     ==>
 store _ message sentTo: other     (NB. ^ gone is correct...)

With a complete aspect definition, the final result might have been eg.

 store _ other veryDeepCopy

or something. Compare that to the first line which really specifies how
three aspects should contribute to the method. Even though you know what
each aspect is in this specific case, the final version is much easier for
verifying that the result is correct. I often find myself having to look
into why the woven result is the way it is (the above comment about the
removed ^ was the result of that). More than once have I started to chase a
bug in the weaver, only to find out after a while that the woven code was
correct although I didn't realize it at first.

>>> (4)    translate to machine code (in any one of the previous states)
>>> (5)    generate specialized versions of methods in subclasses
>>> and for specific parameters
>> 
> 
>> Hmm, in fact aspect weaving is (5), really. And the Slang
> translator is (4).
> 
> Not really, although aspect weaving is related to a lot of this
> stuff.  Slang does not handle message sending or real objects.

Your email parser is too picky for my taste :) "Really" was a hedge, as in
"is equivalent to" or "roughly". Note how what happens in my example above
corresponds to (5). "store _ other deepCopy" is a specialized version in the
aspect equivalent of a subclass, since a subclass is a more detailed version
of a more generic description (its superclass).

Both the specialization of the Self compiler and aspect weaving take what
are (on some level) generic descriptions and translate them, by partial
evaluation in fact, into the specific case at hand. It's rather interesting
that Self's polyvariant specialization compiler is really a special case of
partial evaluation, and also so relatively similar to aspect weaving. On an
abstract level, I should add, as a pragma to your email parser ;)

If I may get bold, I think partial evaluation is the wave of the
future--note how in recent years the distinction between compilers and
interpreters have been blurred so that it is almost irrelevant. The
traditional Smalltalk model, for example, first compiles, then interprets
(the bytecodes). The Self compilers blurred this even more, but what they
did--in principle--was to employ various modes of lazy and/or agressive
evaluation. Unfortunately, they never took the time to reflect on their work
on a more principled level (at least not in public).

Henrik