false caseOf: true

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

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

Nicolas

2011/2/3 Nicolas Cellier <[hidden email]>:

> Great, I'll try and have a look after lunch.
>
> Nicolas
>
> 2011/2/3 Eliot Miranda <[hidden email]>:
>> 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
>> <[hidden email]> 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
>>>
>>
>>
>>
>>
>>
>