Re: semenatics of if/unless/while statement modifiers

David A. Black wrote:

> Hi --
>
> On Tue, 22 Nov 2005, Stefan Kaes wrote:
>
>> Yukihiro Matsumoto wrote:
>>
>>> Hi,
>>>
>>> In message "Re: semenatics of if/unless/while statement modifiers"
>>>    on Tue, 22 Nov 2005 09:54:46 +0900, Stefan Kaes <[e-mail]> 
>>> writes:
>>>
>>> |So this behaviour is caused by intermingling parsing with semantic 
>>> |analysis. Much like forward procedure declarations were required 
>>> for old |Pascal compilers.
>>>
>>> I believe it's a strict application of the "local variables should be
>>> assigned first" rule.  Not a compromise for the compiler.
>>>
>> It is definitely a compiler issue. Just like the recent discussion of 
>> the syntax for block parameters is only a compiler issue.
>>
>> In both forms, the v=expr gets evaluated first. So during evaluation, 
>> the assignment v=expr is always seen first, which means to me, a 
>> local variable gets created and assigned in the current binding. Any 
>> decent formal semantics writer would  like to treat both forms 
>> identically too, simply by stating that "expr1 if expr2" is 
>> equivalent to "if expr2 then expr1" end.
>>
>> If the resolution of local variable assignment vs. function call were 
>> implemented as a second pass on the abstract syntax tree or using 
>> some form of back patching, there would be no difference between the 
>> 2 forms to begin with.
>
>
> What would you want to happen here?
>
>   def x
>     puts "method x"
>   end
>
>   x if x = 1   # method x
>   puts x       # 1
>
That's easy to answer: the same thing that would happen for

  def x
    puts "method x"
  end

  if x = 1
    x
  end

  puts x

You could still use () to disambiguate between local x and method x.

But I certainly don't want to get this message:

  warning: found = in conditional, should be ==

This one would be better

  warning: found = in conditional, maybe you meant ==

-- stefan