Sounds like some methods are missing
(maybe MessageNode>>ensureCanCascade: , BlockNode>>ensureCanCascade ?)

Nicolas

2011/2/3 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>:
> Great, I'll try and have a look after lunch.
>
> Nicolas
>
> 2011/2/3 Eliot Miranda <eliot.miranda at gmail.com>:
>> Hi Nicolas,
>>
>>     forgive the tangent but the attached changes at least allow
>> ^0=1
>> ifTrue: [self is: 'idiot'];
>> ifFalse: [Transcript show: 'Math world is safe'];
>> yourself
>> to function.  I'll try and answer your message soon.
>> best
>> Eliot
>> On Wed, Feb 2, 2011 at 4:38 PM, Nicolas Cellier
>> <nicolas.cellier.aka.nice at gmail.com> wrote:
>>>
>>> While revisiting
>>> http://thread.gmane.org/gmane.comp.lang.smalltalk.squeak.general/131331
>>> and
>>> http://thread.gmane.org/gmane.comp.lang.smalltalk.squeak.general/131333,
>>> I was intrigued by this:
>>>
>>> VariableNode>>canBeSpecialArgument
>>>        "Can I be an argument of (e.g.) ifTrue:?"
>>>
>>>        ^code < LdNil
>>>
>>> ? (as in chess notation)
>>>
>>> First reflex was to check that LdTrue and LdFalse both are < LdNil, so
>>> true and false pseudo variables canBeSpecialArgument.
>>> LdSelf too.
>>>
>>> This required more digging to find that other variables (inst var,
>>> temp vars etc...) have code < 0 < LdNil.
>>> So this means that a variable canBeSpecialArgument (but not the nil
>>> pseudo-variable).
>>>
>>> Who needs that ?
>>> MessageNode>>#checkBlock:as:from:maxArgs: uses
>>>        node canBeSpecialArgument ifTrue:
>>>                [^node isBlockNode].
>>> So inlined messages require a Block in order to be inlined.
>>>
>>> The other sender is MessageNode>>#transformCase:
>>> Ah yes, we tolerate a variable here:
>>>        ^encoder notify: 'caseOf: argument must be a brace construct or a
>>> variable'
>>>
>>> This is limiting a bit the usual chaining power... A variable would be
>>> OK, but another expression would not?
>>> No it wouldn't, as advertised above... For example this makes a Compiler
>>> bark:
>>>        | lowab upAB |
>>>        lowab := { [$a] -> [1]. [$b] -> [2] }.
>>>        upAB := { [$a] -> [1]. [$b] -> [2] }.
>>>        $a caseOf: lowab , upAB otherwise: [0]
>>>
>>> Note that the otherwise argument once upon a time had to be a 0-arg
>>> block...
>>> ... but I changed #checkBlock:as:from:maxArgs: to tolerate non block
>>> some time ago
>>> It now just turns message inlining off if not a block.
>>>
>>> I understand the intention, the syntax of caseOf: is quite unfriendly
>>> and we wanted to enforce rules just to help people learn it. But...
>>>
>>> 1) Noting that by now, any Object respondsTo: #value, an that we can
>>> consequently write
>>>        | lowab |
>>>        lowab := { $a -> 1. $b -> 2 }.
>>>        $a caseOf: lowab otherwise: 0
>>>
>>> 2) Noting that other special messages supports inlining off and will
>>> eventually let the receiver bark when not understood at run time.
>>>
>>> 3) Noting that forcing usage of a variable versus any other expression
>>> creates a syntax singularity.
>>>
>>> 4) Noting there are holes in the barking anyway, (self caseOf: nil)
>>> barks, (self caseOf: true) doesn't
>>>
>>> I would now tend to reduce the barking and simplify
>>> canBeSpecialArgument, and transformCase:
>>>
>>> What do you think ?
>>>
>>> Nicolas
>>>
>>
>>
>>
>>
>>
>