4 ms·
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 re
by alextgordon 17y ago
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!
- labria 17y agoIf 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.
- viraptor 17y agoI'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
- wycats 17y agofoo()() doesn't seem better than foo.call