Quinn Dunkan wrote: > On 26 Mar 2000, Yukihiro Matsumoto wrote: > > > > |Ruby 1.5 seems to have a problem when parsing methods called > > |with a {...} block if there is space before the opening paren. > > > > It's not a bug. It is a bad feature which I'm thinking about > > improvement, and not yet come to conclusion. ;-) > > > > In 1.4.x, identifiers followed by parenthesises is considered as > > method invocation. In 1.5.x, if whitespaces comes between identifiers > > and parenthesises, parenthesises are considered as expression > > grouping, to enable: > > > > point.move (1+3)*2, 5 > > This slipperly path looks like one followed by a certain other language. Hmm, must be the overly context-dependent one. > The fact that ruby has variadic functions and optional parens causes some > unpleasant ambiguities, but I'd rather ruby raise a SyntaxError when it > doesn't know what you mean, rather than "cleverly" trying to figure it out. Good diagnosis. I also want to vote for something like this behavior. I would also like the error message to mention the 2 (or 3) possibilities it was trying to distinguish among rather than just giving a parse error. (I would also vote for doing away with optional parens, although this may be unpopular with many people or it may cause backwards compatibility problems. I prefer this option on the principle of least surprise grounds.) > Now *I* have to figure out what ruby is going to figure out based on what it > thinks I'm thinking... I just wanna write code, not play mind games with a > compiler! Well put. I think this sort of thing somehow goes against the spirit of OO programming in a way that I can't think how to succinctly specify at the moment. > For me at least, ruby's syntax is hovering near the edge of "too complicated". > Please don't push it over :) For me too, at least in this area. I think this is where Larry ran into the design Wall. I think Ruby syntax should strive to be "intuitively obvious" in the sense that it is doesn't readily invite mistakes and misinterpretation--even if that means having to write a few more characters. Conrad Schneiker (This note is unofficial and subject to improvement without notice.)