[ruby-talk:5514] Re: Some newbye question

First thanks to everybody for the numerous answers.

I must confess that I am not fond of this ruby feature and I would like to
motivate my point of view quoting some of the answers.

I definitively agree with

On Fri, 13 Oct 2000, Aleksi Niemelwrote:

> I think it's really weird to think one's passing a parameter when
actually
> the parameter has been already bound.

IMHO the most enlightening answers comes from THE AUTHOR

On Fri, 13 Oct 2000, Yukihiro Matsumoto wrote:
> For example
>   
>   fact = proc{|n|
>     n == 0 ? 1 : fact.call(n-1)*n
>   }
>   p fact.call(4)
> 
> would return 0 if the block does not introduce a new scope.

The problem is that indeed the code fragment above does return 0. Simply
evaluate it in an environment in which n is already defined.

n = 1
fact = proc{|n|
   n == 0 ? 1 : fact.call(n-1)*n
}
p fact.call(4) # returns 0

but this IMHO contradicts the statement of 

On Fri, 13 Oct 2000, Clemens Hintze wrote:

> This is a very nice feature, as code
> should not depend on a variable created by a certain context!

it seems this is not the case here. Isn't it?

To answer to 

On Fri, 13 Oct 2000, Yukihiro Matsumoto wrote:

> So what will happen to `n'?  Will the variable `n' be an isolated from
> outer `n'?

The same things it happens to n in case it is not already declared.

On Fri, 13 Oct 2000, Clemens Hintze wrote:

> Why? Well, it may be that the context is never executed hence the 
> variable does not exist in the end. What will the surrounding
> context be supposed to do then?

As you surely guessed I am talking about variables occurring as parameters
only and in particular the fact that it does not behave as \lambda binder
in lambda calcus. We have no implementation issues here, everything is
needed to implement lambda binding is already present in the execution
environment (a simple tacit rename of parameters would do).

And for sure we have no deep sementic issues. Lambda calculus is studied
since fourties and a number of implemented languages are superset of
it, functional languages as Scheme, ML, Haskell, Gopher, Miranda, ... and
also some non functional having functions as first order objects.

To conclude IMHO 

On Fri, 13 Oct 2000, Yukihiro Matsumoto wrote:

> It's one of the ugliest part of Ruby syntax, which I want to
> fix in the future if I found the way to fix.

You already have a simple and effective way to fix it, simply implement
the standard binding rules.

Again sorry for the length of the mail but I find this is an important
point.

Best Regards,
					Davide Marchignoli