On 10/18/05, Sean O'Halpin <sean.ohalpin / gmail.com> wrote:
> On 10/18/05, Austin Ziegler <halostatue / gmail.com> wrote:
>> Except that Matz still plans on making anonymous functions have
>> closure capabilities.
> Hmmm. I must have missed that. What does "closure capabilities" mean
> exactly?

Keeps local scope at the time that the closure is created.

>> This is why, after Dave Thomas suggested:
>>
>>  anon = def(x = 5)
>>    # implementation of anon
>>  end
>>
>> I then suggested:
>>
>>  anon = lambda(x = 5)
>>    # implementation of anon
>>  end
>>
>> To me, this is clearer than any of the other options that have been
>> so far suggested for anonymous functions.
> I was under the impression that it was
>
>   anon = def(x = 5) ... end
>
> for def style semantics (i.e. 'true' anonymous function, opaque scope,
> etc.) and
>
>   block = lambda(x = 5) ... end
>
> for closures. If so, then I would endorse these suggestions.

This is not what was discussed on Friday during the roundtable or on
Saturday during the keynote. Both were suggested to solve the same
problem -- that is, the same problem that is currently solved in 1.9
with:

  anon = ->(x = 5) { ... }

I think that a *lot* of people really don't like that notation. Too many
symbols, lack of a left-side for the arrow, etc. But my sense of the
room was that either using def() or lambda() was generally felt to be
cleaner and as meaningful. Using def(), however, means that "def" is
contextually closure/non-closure depending on the presence of a name. It
also seemed to me that Matz wasn't fond of the reuse of "def".

> Otherwise, I have to confess, I'm a little confused as to what the
> proposal for anonymous functions actually means.

There is a difference between anonymous functions (lambdas) and blocks
in that blocks are considered -- after a fashion -- to be an extension
of the using/calling method. So parameters are passed to blocks in
parallel-assignment fashion and are passed to lambdas as actual
parameter lists. Also, "return" in a block will return from the yielding
function; in a lambda, it will return from the lambda only.


> On 10/18/05, Trans <transfire / gmail.com> wrote:
>> I agree that a *true* anonymous function is needed,
> I'm surprised more people don't seem to think real anonymous functions
> would be useful. I'm pretty sure they'd be applicable in the majority
> of cases where we use blocks now, especially with map, inject, select,
> grep, etc. They would surely be more efficient (no need to set up
> binding, no lookup outside current scope, lower memory usage).

I have yet to need one (an anonymous function). I personally don't
believe that it would necessarily be more efficient, either. Indeed,
with my use of #map, etc., I tend to liberally use the fact that no new
scope is introduced and that the block is a closure. I think that your
estimation of which would be more useful flies contrary to current use
and likely continued future use of Ruby.

Indeed, I don't think that I'd ever use the lambda() keyword that has
been proposed to replace ->() in 1.9. I could be wrong, but that's just
not my programming style. I almost certainly wouldn't use one that gives
me an anonymous non-closure function. I don't think that that's an
important enough use case, where a named method would work just as well.

Others may find it more useful, but I haven't had a need yet.

[...]
>>  lambda do |x|
>>    # ... has closure
>>  end
>>
>>  lambda do(x)
>>    # ... does not have closure
>>  end
> I quite like that. While we're at it, how about

I can't stand it. It's entirely too contextual and "magic". If you
really *must* have non-closure anonymous functions, propose a keyword.
Magic punctuation doesn't do it for me. IMO, there's just a little too
much magic punctuation in Ruby as it stands now. (Not much, but I'm not
really comfortable with **kwargs.)

>   lambda {|x| .. }
>
> for closure and
>
>   lambda [|x| ... ]

No. That's even uglier than the first.

-austin
--
Austin Ziegler * halostatue / gmail.com
               * Alternate: austin / halostatue.ca