Please take a look at http://bugs.squeak.org/view.php?id=6426

Boris.Gaertner a écrit :
> "Brian Brown" <rbb at techgame.net> wrote:
> 
> 
>> Looking at ProtoObject>>ifNotNil: ifNotNilBlock
>> "Evaluate the block, unless I'm == nil (q.v.)"
>>
>> ^ ifNotNilBlock valueWithPossibleArgs: {self}ifNotNil:
>>
>>
>> ... which is invoked if the receiver is not nil, I would expect the  
>> following to work:
>>
>> 5 ifNotNil: [:e |  e] to return 5, but what I get is:
>>
>> argument of ifNotNil: must be a 0-argument block
>>
>>
>> However, if first store the block in a temp:
>>
>> ab := [:e | e]
>>
>> 5 ifNotNil: ab.
>>
>>
>> returns 5
>>
>> I don't understand what the difference is between these; could some  
>> kind soul enlighten me as what is happening?
>>
>>
> Very interesting. There  should be no difference between the two
> statements you mention and the very fact that there is should be
> understood as a hint thatwe may have a new compilation bug.
> 
> In Squeak 3.7 the two statements of your example are both
> erroneous, forthefirst one the compiler gives a message,
> thesecond one brings up the debugger.
> 
> In Squeak 3.7 the definition of ifNotNil:  was:
> 
> ifNotNil: ifNotNilBlock
> "Evaluate the block, unless I'm == nil (q.v.)"
> 
> ^ ifNotNilBlock value
> 
> The difference to newer version is that in 3.7 no support
> for optional block arguments was present. In 3.9 it is
> present and in my opinion the compiler was not appropriately adapted.
> 
> Class MessageNode has two class variables that are relevant for
> that problem:
> MacroSelectors  an array of message selectors that are inlined or otherwise
>  transformed.
> MacroTransformers
>  an array of message selectors for messages in MethodMode that
>  implement the code optimization.
> 
> These class variables and others are initialized in MethodNode 
> class>initialize
> and I think a change there would fix the problem.
> The really important question is however:
> Was the introduction of optional arguments for  ifNotNil:
> (and others) a good change when that change requires
> the removal of a code transformation?
> 
> Comments from our compiler specialists are of course
> welcome.
> 
> For me it is quite clear that we have a compiler bug here,
> but I hesitate to propose a fix. Shall me modify thecompiler
> or shall we go back to an earlier definition of  ifNotNil: ?
> 
> Hope this will help
> Boris
> 
>