Re: [PATCH] lambda with normal block syntax

On Thu, May 29, 2008 at 10:09 AM, Yukihiro Matsumoto <[e-mail]> wrote:
>
> Hi,
>
> In message "Re: [PATCH] lambda with normal block syntax"
>    on Thu, 29 May 2008 22:59:41 +0900, "Eric Mahurin" <[e-mail]> writes:
>
> |> The case I hate most is
> |>
> |>  meth {|a|...}
> |>
> |> can be parsed (by humans) both
> |>
> |>  meth({|a|...})
> |>
> |> and
> |>
> |>  meth() {|a|...}
> |>
> |> having too confusing semantics.
> |
> |But, this ambiguity already exists today:
> |
> |meth {}
> |
> |can be parsed (by humans) both
> |
> |meth({}) # {} is a Hash
> |
> |and
> |
> |meth() {} # {} is a block
> |
> |Precedence resolves this: block has higher precedence.
>
> Yes, but hashes and blocks are completely different beasts; in
> contrast blocks and lambdas are too similar (yet different).
>
>                                                        matz.

But, there are other cases where the same symbol is used for similar
but different things (i.e. binary vs. unary operations, [] indexing
vs. array creation).  Here's a list of possible ambiguities we have
today along these same lines I could come up with for those that don't
use ()'s around arguments:

def foo(*args, &block); args<<block; end
foo = 42
bar = lambda { "bar" }
q = 43
s = 1
module A; end
A = 44

p(foo {})                # => [#<Proc:[e-mail]:11>]
p(foo({}))               # => [{}, nil]

p(foo [0])               # => 0
p(foo([0]))              # => [[0], nil]

p(foo -1)                # => 41
p(foo(-1))               # => [-1, nil]

p(foo +1)                # => 43
p(foo(+1))               # => [1, nil]

p(foo *2)                # => 84
p(foo(*2))               # => [2, nil]

p(foo /2/s)              # => 21
p(foo(/2/s))             # => [/2/s, nil]

p(foo &3)                # => 2
p(foo(&bar))             # => [#<Proc:[e-mail]:7>]

p(foo (1), 2)            # => [1, nil]
                         # => 2
p(foo((1), 2))           # => [1, 2, nil]

p(foo %q)                # => 42
p(foo(%q<hello>))        # => ["hello", nil]

p(foo <<1)               # => 84
p(foo(<<1))              # => ["world\n", nil]
world
1

p(foo ?A : nil)          # => 44
p(foo(?A))               # => [65, nil]

p(true ? foo :A)         # => 42
p(true ? foo(:A) : nil)  # => [:A, nil]
p(true ? foo(::A) : nil) # => [44, nil]


In all of the above cases, it looks like if a symbol can be
interpreted as an infix operator (in a binary or ternary operation) it
takes precedence over being interpreted as a prefix/unary operator.

The only other case I found with a 3-way ambiguity was the ":" case
above.  I think this would be similar to the 3-way ambiguity between
block, hash, and lambda that I proposed.

Anyways, thank you for the consideration of these patches.  I'm glad
to see that you'll be adopting the defaults for block arguments patch
as it is the more important one.  The bare block lambda patch is just
syntactic sugar.

Eric