--- Jamis Buck said:
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