[ruby-talk:02209] Re: parse bug in 1.5

From: mrilu <[e-mail]>

> > (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.)
>
> I have to say I don't agree. Principle of least surprise goes well along
> if you just use parentheses all the time. I agree though that this point
> should be made really clear for beginners, much better than it has been
> done so far. Maybe this is not clear because Ruby hasn't had
> enough beginner mass to make endless questions of same things. At some
> point FAQ will be in ten parts and the first thing in the FAQ will be
> famous proverbs from Ruby Veterans and Heroes like "Use parentheses unless
> you know what you do, and use them even then."

Well, I think you have just made a good argument for making parens required.
:-)

> *You take risks when you don't parenthesize everything and be specific*.
> You have right to be concise, but you have the responsibility for behaving
> and doing it right. Usually being concise enhances readibility and
> there is less rows for bugs to lurk, while that lack of space drives those
> parasites to be even clever.
>
> Doing short code right isn't easy. If Ruby executes your code in proper
> manner, there's still plenty of other coders who might fall into your
> trap. Ruby guesses well, I think. And usually when I'm running into
> problems, that's good sign my code is too complicated.

Well, I think you have just made another good argument for making parens
required. :-)

> I think denying There Is More Than One Way To Do It is not one of Ruby's
> desing goals. I hope it's quite much the opposite. Optional parentheses
> live on the TIMTOWTDI side.
>
> TIMTOWTDI is nice because it allows one to be as pedantic, clean or
> specific as syntax allows.

I think that TABWTDI (there are _better_ ways to do it) might be a better
description of Ruby's design goal in this area (if not originally, then
hopefully currently).

Too much flexibility in the wrong places can become counterproductive when
you try to extend languages later--and this has been a major problem for
Perl.

> I would guess it's Ruby's right to be right and the judge if some sample
> of coders could not totally agree (without dispute) what some piece of
> code should do. But that kind of event would show the code has too
> much ambiguity and it should be clearly removed for other coders and for
> Ruby by using parentheses (or whatever is appropriate).
>
> > > 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.
>
> Well, I can't agree here either. I don't have any experience on the
> internals of the language, but the BNF doesn't seem to be too long.
> And at least Ruby has well defined syntax. Let's remember that it's not
> possible to generate BNF for Perl (or maybe it is, it's just not
> convenient).

Yes, but it is the _human_ parsers that we are concerned with. (AFAIK, the
BNF for these things like vi commands is probably substantially simpler than
for RUBY--yet, as the person who started this thread indicated in another
thread, things like vi commands can be very complex to figure out when
strung together.)

> > 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.
>
> I agree. And for me it's totally intuitively obvious that everything works
> with parentheses. Without them I still hardly drive into problems.
>
> Actually I like to note that *I'm using function* here(). With perl it was
> important sometimes.

Well, however this issue is resolved, maybe "always use parens" (in the
sorts of contexts we have been discussing) should be something that a Ruby
"strict mode" should require, and maybe verbose mode should always warn
about it.

Conrad