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