FWIW, as someone who does a lot of work with parsers, that block case is a bad example, as it is not at all ambiguous and does not make the language more difficult to parse. C and C++ have tons of things that make them frustrating or even nearly impossible to parse: if you just write down the naive description of this feature from Ruby you will see there are no ambiguities and it never even requires more than a single lookahead token to decide if you are using a hash or a block argument. A very similar example from JavaScript between and object literal and a block statement is actually a legitimate issue, but this feature of Ruby is so benign you can probably parse it correctly dropped into the middle of the file at the { with nothing but a single token of look-behind. The "splat" example, though, is spot on: there you have a context sensitivity. (Not so much in the [/" one, though: this does make the language more frustrating to parse, but only because the language is clearly defined over characters instead of tokens; but it is still a better example than the block argument.)
(And sorry for not having replied earlier, i seems HN doesn't notify about replies any more.)
The point i was trying to make was mostly about the difficulty of understanding the syntax (i.e. "parsing" for humans), not so much about syntax ambiguity or having to use a more sophisticated parsing strategy. The comments on the code represent the "rules" that a human might follow to try and make sense of that syntax. They are not as simple as they could be had Ruby only allows blocks to be denoted with do/end.
However, about the complexity on the parser itself, doesn't this case of block syntax need at least some dedicated logic to take care of ´foo {}´ not parsing the {} part as a hash literal expression but rather as a block? (e.g., maybe adding some explicit priories to the parser rules, or making the lexer add hidden parentheses so that the parser sees ´foo() {}´ and doesn't have to make that distinction).
