From: Eric Mahurin Date: 2005-06-02T07:50:41+09:00 Subject: Re: ternary operator confusion --- Jamis Buck wrote: > On Jun 1, 2005, at 3:47 PM, Austin Ziegler wrote: > > > On 6/1/05, Eric Mahurin wrote: > > > >> --- "Marcel Molina Jr." wrote: > >> > >>> On Thu, Jun 02, 2005 at 01:40:23AM +0900, Phrogz wrote: > >>> > >>>> true ? a.push(1) : a.push(2) > >>>> > >>> i suspect this could have been just a contrived example > but you > >>> could also do: > >>> > >>> a.push true ? 1 : 2 > >>> > >> I wish Ruby didn't make the () optional when passing args > >> (probably from Perl which wanted to be like > shells/tcl/lisp where > >> command/function and arguments are space separated). > >> > >> When you don't put the () in, the precendence can get > confusing > >> and you arbitrarily prevent the first arg to start with a > "(" > >> (otherwise it will treat that "(" as what starts the > argument > >> list). > >> > >> Why do people feel the need to drop the ()? I didn't like > it in > >> Perl and I don't like it in Ruby. Do people just want > something > >> that is kind of like shell syntax? > >> > > > > I use it in PDF::Writer because it makes certain parts feel > more > > like a DSL (domain specific language) than a program. > > And that is _precisely_ why I like the technique as well. It > is > wonderful for making a Ruby program read (more or less) like > a domain > document. And when ambiguity raises its ugly head, I can > always throw > in the parens to disambiguate. > > But as someone else pointed out, if you don't like it, no one > is > forcing you to drop the parens in your own programs. Choose > the > technique that works best for you. When I first starting using Perl (v4) I thought it was neat that I didn't need the parens, but then I got burned a few times when I needed parens in the first arg. Then I realized what an ugly hack at in the syntax this was. This was a bad thing that was brought over from perl. Consider the following method calls: 1. f a , b # OK 2. f a , (b) # OK 3. f (a)+0, b # *** now (a) looks like the args to f*** 4. f 0+(a), b # putting in the 0+ prevented the problem above The problem is if you start with #1, you may eventually need for the the first arg to be some expression and you run into #3. For comparision here ways that some languages make function/method/procedure/command calls: function/method/procedure/command: f arguments: a, b `f a b` shells (bash also supports "$(f a b)") [f a b] tcl (f a b) lisp f(a,b) most other languages including perl and ruby f a,b alternate for perl and ruby The problem is that perl/ruby support both of the last 2 forms. This results in ambiguity if you are trying to use the last form, but need argument "a" to start with a "(". The () form wins the ambiguity in this case. The "f a,b" form could have worked more cleanly if the "f(a,b)" form wasn't supported (you'd have to group with "(f a,b)"). But since perl/ruby supports both and the f(a,b) form wins ambiguities, the f a,b form looks to work inconsistently. On top of that you have to think about precedence more closely (what started this thread). just my 2 cents. __________________________________ Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html