From: Artem Voroztsov <artem.voroztsov@...>
Date: 2008-05-12T01:01:33+09:00
Subject: Re: lambda, ->, haskell, and so on

2008/5/5 Paul Brannan <pbrannan@atdesk.com>:
> On Thu, May 01, 2008 at 12:26:47PM +0900, Dave Thomas wrote:
>  > This is one of those e-mails that I know from the start to be futile,
>  > but...
>  >
>  > For a while now, the
>  >
>  >      -> (params) { block }
>  >
>  > syntax in Ruby 1.9 has bothered me, but I've never been sure why.
>  > Today, while playing with pure, it struck me. The '->' sequence is in
>  > an unexpected place. Having played with some functional languages, I'm
>  > used to lambdas being written
>
>  I agree.  To me the -> looks like an arrow rather than a lambda, so it
>  reels like it should be between two items.
>
>  What if "lambda" were to become a keyword, so one could write:
>
>   lambda(params) { block }
>
>  as an alternative to the -> syntax?
>
>  Paul
>
>


+1

1) Syntax

 lambda(params) { block }

may cause problems with interpreting the following code:

 block = proc {}
 lambda(&block)

So 'lambda' should become keyword and does not allow passing &block in
round parentheses.
 If parenthesis goes after 'lambda' that it should be treated as
special case with method semantics.

So
  lambda(&block) { block.call  }
is valid.

And
  lambda(&block)
gives ArgumentError "Block should be given to lambda implicitly"


But still curled brackets block is associated  with "block semantics"
and not with "method semantics". It's a problem.


2) Proposed define_method's syntax

  define_method :bar, &lambda(a,b=1){a + b}

is too heavy. And again it's unnatural to think about curled brackets
block as having "method semantics" (What will 'return' do inside this
block?).

In fact I prefer something like this:

def { :bar } (a, b=1)
  a+b
end

{:bar}  could be replaced by < :bar > OR \(:bar) OR  *(:bar)  to
simplify parsing.

Here we need something absolutely new with semantic "calculate it,
call :to_sym, and place it here".


Artem