Paul Battley

Both Ruby and Perl have the same challenge, and both solve it by treating the expression differently depending on whether f is a variable or a function/method. As it turns out, you can't actually parse Perl 5 [1], but Ruby can be statically parsed [2], and resolves this ambiguity based on context.

I don't actually know anything about CoffeeScript's parser, and I imagine that it complicates the grammar significantly, but would the same approach not be possible there?

(Personally, I'm quite happy to type parentheses in exchange for clear syntax, and it's these very aspects of CoffeeScript that put me off it: I really find it tricky to follow what's going on when function definitions, function calls, and named parameters are mingled. At least regular JavaScript is syntactically simple, even if I do have to type function more often and worry about this.)

[1] http://www.perlmonks.org/?node_id=663393
[2] http://po-ru.com/diary/ruby-parsing-ambiguities/

writing parsers is the least interesting part of an interpreter/compiler, and your grammar should be boring if you want your syntax to be easy to understand by humans.

In my (admittedly limited) experience, most grammars for programming languages that are supposed to be easy on humans end up being harder to parse. (See below) One notable exception is, of course, Smalltalk.

One criticism I have of this article, is that it is written in a way that obscures the fact a top-down parser is an LL(k) parser. I'd posit that sticking to an LL(1) grammar is a great way to wind up with a simpler syntax that lacks sticky syntactic sugar that will be hard to optimize and build software tool for later on. (AT least for your personal learning hobby project. But in that case, at least use a separate Lexer!)

You can't introduce bullshit ambiguous extensions to your grammar

Ruby: http://po-ru.com/diary/ruby-parsing-ambiguities/