Re: shortcut for add unless nil ?

On Sun, Mar 27, 2011 at 03:09:05AM +0900, Robert Klemme wrote:
> On Sat, Mar 26, 2011 at 4:57 PM, Chad Perrin <[e-mail]> wrote:
> >
> >he 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 `<main>': 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".

Yes, that's a good point -- and it's why I did not actually suggest Ruby
should adopt that kind of approach.  The existing syntax rules of the
language make such changes difficult, to say the least.


> >
> > Frankly, I'd be happy without infix operator syntax (with its
> > precedence rules) at all. .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.

If I don't misunderstand what you mean by that, I'm not sure that's a
problem.


>
> 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.)

Actually, bracketing characters are not always necessary.  UCBLogo uses
an interesting approach where bracketing characters are optional when
using default numbers of arguments (since some arguments can take
arbitrary numbers of arguments).  For instance:

    sum 2 quotient 9 3

With some optional bracketing syntax:

    sum 2 (quotient 9 3)

For more than two arguments to sum, you would need bracketing characters:

    (sum 2 3 4)


>
> 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. :-)

One reason I might be happy with it is the fact that I guess I'd disagree
with your implied definition of elegance.  I think that complex
precedence hierarchies for buckets full of operators are not as "elegant"
as a single precedence rule for operator-style methods.  In fact, I
generally find it somewhat easier, in complex arithmetic operations, to
follow a chain of methods than a glut of (+-)*/% symbols with numbers
scattered amongst them, at first glance.

Obviously, your mileage may vary, depending on your experience.

Actually, one reason I would prefer the more universal syntactic style of
the language (in this case method call syntax) over special operators is
the fact that it does not require as much experience for precedence rules
to make intuitive sense, resulting in quicker uptake of the rules of the
language, thanks to the fact that the number of rules pertaining to
arithmetic and comparison is greatly reduced.

I guess I like consistency over convention, in such a case.  On the other
hand, I understand the importance of convention for things like popular
adoption.  If Ruby didn't have the standard set of C-style infix
operators, it probably would not have been so widely adopted, and I may
never have encountered it in the first place.  That would have been
something of a tragedy, considering how much I like Ruby.

-- 
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]