"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