Hacker News Reader

Comment by alextgordon | Hacker News Reader

tl;dr: The problem is that if () were to call blocks, then this

    def foo
      proc {}
    end
    
    foo()

...would be ambiguous. Is it a call of foo returning a block, or a call of foo returning a block and calling that block?

To "fix" this you'd have to require parens when calling all functions, since you have no way of knowing whether the function returns a block or not. The other option is only allowing parens to call blocks at certain times and not at others - certainly confusing!

View on HN

I'm not sure why people say that. It seems obvious. What optional '()' needs to achieve is:

    def a
      42
    end

    a => 42
    a() => 42

So the grammar could use something like:

    call = expression '(' ... ')'
    call_or_variable = expression

it cannot be reversed really, because then it would match `call_or_variable` '(' ')' - which would make `a()` fail to run, because 42 is not callable (or you'd have to use backtracking and guessing... evil).

It cannot be the case of "no way of knowing", because at parsing time in dynamic language you don't know what the result of a function is - you only look at grammar. So in the simplest possible way, if the '()' is optional, then... I'm not sure how to call it, but let's say - '()' binds stronger than 'possible application':

    foo => call foo
    foo() => call foo
    foo()() => call proc

foo()() doesn't seem better than foo.call

If we were to make () call blocks, then we would have to make ()'s in function calls mandatory, so that we would get something like foo()() to call the function _and_ the block.

Reply on news.ycombinator.com