Re: semenatics of if/unless/while statement modifiers

Hi,

In message "Re: semenatics of if/unless/while statement modifiers"
    on Wed, 23 Nov 2005 00:58:00 +0900, Stefan Kaes <[e-mail]> writes:

|>The current syntax rule is:
|>
|>  if assignment is done, a right hand side identifier is a local
|>  variable thereafter.
|
|Just keep it.

Hmm, I think you mean we don't have to change the rule except for
declaring that "expr1 if expr2" has *exactly* the same semantics,
right?

But in reality, the rule becomes

|>  if assignment is done, a right hand side identifier is a local
|>  variable thereafter.  and assignment in modifier condition affects
|>  modifying statement as well.

anyway.  So let us investigate the "exactly the same semantics" rule
more closely.  If you can explain like that, modifier explanation
would become little bit simpler.  But it also encourages false image
of "dynamic local variable initialization" model, that local variable
appear on its first assignment operation.  Next time users would
confused when they see

  if false
    a = 15
  else
    p a
  end

prints "nil", or expecting first "a" in

   5.times do
     p a
     a = foo()
   end

to be a local variable at the second iteration, and so on.  Potential
problems still remains.

After all, this "small" syntax change buys you small explanation
clarity, and only allowing assignment in modifier conditions, which I
believe is not something to be encouraged at most, at the cost of huge
(possible but difficult) parser changes.  I'm not exciting to change
for that kind of solution.

If the rule is like

|>  if there is assignment, a right hand side identifier is a local
|>  variable in the current scope.

it serves wider range of potential problems, so that it might motivate
me more likely.  But it still has disadvantage of ambiguity.

							matz.