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
>>
>
>
>
>
>