Hi,

In message "[ruby-talk:5789] Re: local variables (nested, in-block, parameters, etc.)"
    on 00/10/23, "Guy N. Hurst" <gnhurst / hurstlinks.com> writes:

|I think they are:
|
|If a local var exists before a lambda, 
|- it should be available to the lambda
|- it should be bindable to a parameter
|
|If you are making a lambda
|a - you should have the option to bind parameter to a local var
|    + makes in-block var same as local var; no name conflicts
|b - you should have access to local vars you know about
|c - if you don't bind a parameter to a local var, you shouldn't
|have to worry about conflicts of that in-block var with the local var
|    + [name conflict] either disallow using the local var you chose to not bind to
|    + or, use special accessor syntax to differentiate the two
|d - you should be able to make in-block vars that are limited to inside the block
|    + to make it limited to the block, it can't be bound to a local var
|    + you shouldn't have to worry about conflicts with local vars you use inside the block
|e - you should be able to make vars inside the block that are accessible outside it
|    + to make it accessible outside the block, it should have to be a local var
|    + you shouldn't have to worry about conflicts with other local vars
|f - you shouldn't have to know about all local vars to avoid conflicts

Thank you for the problem analysis.

My current idea is to introduce new block parameter syntax <>, which
makes all variables inside block local.  In addition, optional block
local variable declaration might be added, like:

  l = lambda{<a, b; c, d> ...}

Plus, if compatibility problem would not be so critical, || block
parameters might NOT be in-block vars even if they are NOT seen before
the block.  Note I've not decided anything yet. We still need discussions.

Good things about this are:

  * We would be freed from local name conflict problem finally.

  * single block parameter (e.g. |a|) is something in between |a,| and
    |*a|.  But <a> behavior would be clear.

Bad things about this are:

  * it introduces explicit declaration, which Ruby has avoided for
    long time.

  * incompatibility.  Especially, || behavior change might be too big
    damage for existing programs.

							matz.