From: Robert Klemme Date: 2011-03-27T03:09:05+09:00 Subject: Re: shortcut for add unless nil ? On Sat, Mar 26, 2011 at 4:57 PM, Chad Perrin wrote: > On Sat, Mar 26, 2011 at 07:21:25PM +0900, Robert Klemme wrote: >> > >> > IDK how well this would work or its potential ramifications, but i >> > think it fits into the 'flavor' of ruby to be able to do such things >> > (i mean, you can define/change damn near *everything else* in the >> > language, why not operators?) >> >> Because that would completely break parsing.  Whenever an operator >> definition would be seen the whole source would need reparsing - or at >> least part of it.  It would be tricky to determine which part. > > I'm not so sure about that.  If it were just possible to specify that a > method need not be connected to its object with the "dot", it would give > the appearance of an infix operator for those who really want it, but > would only conform to the standard rules for method calls. That's a different story because that is a fixed syntax for method calls and *not* introducing arbitrary new operators. Introducing new operators ad hoc changes the syntax hence you need to reparse or do parsing completely different as I have laid out. >  The parser > would just have to maintain a last-object context of one to determine > whether what follows is a method to which the last object responds. It wouldn't work though because of ambiguity. You cannot change "a.b c" to "a b c" which has a valid interpretation already today: $ ruby19 -e 'def a(*x)printf("a:%p\n",x)end;def b(*x)printf("b:%p\n",x)end;def c(*x)printf("c:%p\n",x)end;a b c' c:[] b:[nil] a:[nil] $ ruby19 -e 'def a(*x)printf("a:%p\n",x)end;def b(*x)printf("b:%p\n",x)end;def c(*x)printf("c:%p\n",x)end;a.b c' a:[] c:[] -e:1:in `
': private method `b' called for nil:NilClass (NoMethodError) Even simpler "a.b" means "evaluate a and invoke b on the result" while "a b" means "evaluate b and use it as argument when calling method a". > Of course, I'm not sure that would be so great a task to dump on the > interpreter, but I don't think it would necessarily be as dire as you > describe, as long as we're willing to recognize that infix arithmetic, > comparison, and assignment operators are actually methods. Many operators are actually methods already. (And 1.9 has expanded on this IIRC.) But that is not the problem here, the problem lies with the syntax. What makes operators special is not the fact that they use a specific subset of ASCII but rather the role they play in the syntax of the language. > Frankly, I'd be happy without infix operator syntax (with its precedence > rules) at all.  2.plus(3) is conceptually simpler than 2 + 3 in the > context of code; so is something like (+ 2 3), add(2,3,), or sum 2 3. > > 2.plus 3 looks pretty "infix"y to me anyway, but it's still a method call > with obvious meaning and precedence. Yes, but the downside is that there is only one level of precedence. The good thing about using operators in syntax is that you can have precedence without explicit bracketing thus repeating something that most people know from mathematics. Everybody with basic math knowledge knows what "a + b * c" means and in what order it is evaluated. For methods you need to do "a.plus(b.mult c)". ("times" was already taken.) Of course we could have Ruby with the same functionality as today without *any* operators without restriction in functionality. But then code becomes more verbose and less elegant and concise which is one of the strengths of the language. I am not sure that you would be really that happy with the result - certainly I wouldn't. :-) Kind regards robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/