[ruby-core:24431] Re: lvar_propagate

Hi,

In message "Re: [ruby-core:24421] lvar_propagate"
    on Sat, 18 Jul 2009 15:17:36 +0900, Yehuda Katz <[e-mail]> writes:

|Very good keynote today. I enjoyed looking at some of the new features you
|are playing around with. I was very existed about lvar_propagate, and am
|hoping I can convince you to give it another chance :)
|
|Here's why: In my ideal world, blocks behave transparently to the end user.
|There would be no difference between:

In my ideal world, there's no implicit block-local variable, just flat
to innermost scope making construct, e.g. def, class, module etc.  And
when one want block-local variables, he need to declare them by using
block local variable list in the block parameter part (|a; b c|), or
by using := assignment from block_local_vars_eq patch stack, which was
also in the keynote.

  100.times do |x|
    v1 = x
    v2 := x
    ...
  end
  p v1  # local variable; no block scope
  p v2  # name error; out of scope

In real world, It would cause serious compatibility problem.  That's
the very reason I made up far more complex local variable propagation.

Shugo came to me today telling me he made a patch to realize flat
local variable scope that can be enabled by magic comment, so that

  100.times do |x|
    v1 = x
    ...
  end
  p v2  # name error; out of scope

But if there's a magic comment

  # -*- nested-local-variables: false -*-
  100.times do |x|
    v1 = x
    ...
  end
  p v2  # local variable; no block scope

I have not yet have any conclusion about the idea, but eventual
migration using magic comment may be realistic (or not).  I am not
sure which is the best way from:

  * keeping as they are.  no compatibility issue.
  * local variable propagation.  complex, but works for most of the
    cases.  little (if any) compatibility issue.
  * flat local variable scope, unless explicitly declared.  has
    compatibility issue.  need migration path.

							matz.