> 
> Cool. Intriguing.
> 
> I'm sure I can use it to:
> - patch problematic code on the fly without registering an override
> - change the semantics of some smalltalk statement (so that a := becomes self 
> a: or anything else)
> 

Yes, it is for “evil” experiments that can not be done else (short of changing 
the compiler itself).

e.g. last week for an experiment, I wanted a form of “super” where it is not 
“self, but start lookup in superclass”, but instead
“this object, do a send to it but start lookup in the superclass”.  There are 
no messages called #super in the image, so you can
so that by transforming all

myObject super doSomething

into

myObject perform: #doSomething withArguments: #() inSuperclass: myObject class 
superclass.

The needed Opal plugin has this #transform method:

transform
        | superSends new  |
        superSends := ast sendNodes select: [ :each | each selector = #super ].
        superSends do: [ :spnode |
                new := RBMessageNode 
                        receiver: spnode receiver copy
                        selector: #perform:withArguments:inSuperclass:
                        arguments: {RBLiteralNode value: spnode parent selector 
copy . 
                                RBArrayNode statements: spnode parent arguments 
. 
                                RBMessageNode receiver: (RBMessageNode 
receiver: spnode receiver copy selector: #class) selector: #superclass}.
         spnode parent replaceWith: new
        ].
        ^ast

> Would it be possible to couple it with Clement work to have some ability to 
> pre-compile some code in specific classes (strength reduction, once literals) 
> where we know that this is valuable?
> 
Good question….

> It would also be nice to have a way not to write bytecode by hand, like, say, 
> in the slots example of a few days back.
> 
Yes, the byte code writing for Slots is just a solution that works *today*. 
With a runtime optimizer you could instead always generate the reflective slow 
version
and let Sista optimise it.

> Oh, ok, for the literal stuff, I think I know how to do it:
> 
> In a method:
> - replace target expression with symbol literal.
> - evaluate target expression in isolation, store value.
> - compile method with symbol literal.
> - in compiled method, replace symbol literal with value stored above.
> 
> Would that work?
> 

Hmm… messages to known objects without side effect could be evaluated by the 
compiler.
What makes it hard ist mostly debugging: mapping the generated code back to the 
original
source…. 

        Marcus



Reply via email to