Re: lambda, ->, haskell, and so on

On Mon, May 12, 2008 at 9:06 AM, Paul Brannan <[e-mail]> wrote:

> On Sun, May 11, 2008 at 07:24:07PM +0900, Michael Neumann wrote:
> > Evan Phoenix wrote:
> > > Not to throw the whole thread into a tizzy again, but why again is:
> > >
> > >  ->(a,b) { }   # stabby proc
> > >
> > > better than
> > >
> > >   def(a,b) { } # anonymous def
> >
> > shouldn't that be
> >
> >     def(a,b) ... end
> >
> > otherwise it introduces again a bit of inconsistency. And then "def" is
> > used for methods, not procs. Despite, I like the syntax :)
>
> IMO 'def(a,b) ... end' implies that the code between def..end does not
> have access to variables in the outer scope (because this is how def
> works currently).
>
> I do like the anonymous def, but not as a replacement for lambda.  (it
> should be faster to call an anonymous def than to call a proc/lambda)
>
> Currently we have these kinds of functions:
>
>                      anonymous   closure   default args  checks # args
>  def foo(a,b); end       N          N            Y             Y
>  ->(a,b) { }             Y          Y            Y             Y
>  lambda { }              Y          Y            N             Y
>  proc { }                Y          Y            N             N
>  Proc.new { }            Y          Y            N             N
>  define_method { }       N          Y            N             Y


There should probably be one more column in the above: "self"-closure.  The
block for define_method isn't a normal closure.  "self" and @ vars refer to
the object where the method is placed, not the closure context.  This is
similar to "instance_eval" and "class_eval".  "instance_eval" and
"class_eval" would also be useful in this table.  I know there is a very
subtle difference between the way the block is treated for instance_eval and
class_eval, but I forgot.

(I can't remember off the top of my head the difference between proc and
> Proc.new -- are they the same in 1.9?)
>
> It would be nice if we could build some consistency into this table so
> that explaining the differences between all of these was a matter of
> following rules, rather than memorizing which mechanisms work which way.


Completely agree.