Re: [ ruby-Bugs-3843 ] "not" operator used in expression that is a method parameter can generate syntax error

On 3/16/06, mathew <[e-mail]> wrote:
> Brian Mitchell wrote:
> > On 3/16/06, mathew <[e-mail]> wrote:
> >
> >> I still don't understand why foo(!(1<2)) is OK, but foo(not(1<2)) isn't.
> >>
> >> The pickaxe says that the only difference between '!' and 'not' is
> >> precedence, and in these two cases everything is explicitly bracketed so
> >> precedence shouldn't be involved.
> >>
> >> What am I missing?
> >>
> >
> > foo(not(1<2), 3)
> > or more clearly bound if I understand Matz correctly:
> > foo(not((1<2),3))
> >
>
> Except comma isn't an operator according to the Pickaxe. Could be a
> documentation error, I suppose.
>
> Accepting for a moment that comma is an operator...
>
> I don't see how it makes sense to give an error for foo(not(1<2)) just
> because a completely different statement foo(not(1<2),3) would have a
> precedence clash. I mean, method {|x| 2*x } is allowed, even though
> method {|x| 2*x }, {|y| 3*y} wouldn't be.

Comma is not an operator, strictly speaking, but when parsing code,
you must bind the acitons of "," and "not" in specific orders. This is
why I called it an operator (more in the scope of the grammar than the
actual langauge). Please pardon my generic use of the term.

Continuing from there one can see that there would be no problem
making a special case for

  f(not x)

This will be turned around right after the dust settles by someone
unaware of this. They might complain:

I can use f(not x) legally but why does f(not x, y) cause an error?

I think there is a delicate ballance to be made and consistency of
syntax is more important to me than allowing an extra corner case.

I could take a guess at why this was settled on. Consider the following:

  def f *; end
  f f not 1 # f f not 1, 2 will also fail

This example will fail. It should correctly complain about the not,
saying "syntax error, unexpected kNOT, expecting $end" or similar. On
the other hand, Ruby is smart enough to handle the following (though
it will give a warning):

  def f*; end
  f f 1 # f f 1, 2 will also work.

The amount of work nessessary to implement this includes giving
function application and "," explicit precedence while preserving the
ability to do:

not f f 1

Which has the behavior:

not(f(f(1)))

I hope this helps and apologize in advance for any incorrect
information the above might have.

Now, the question of whether or not "," and "not" could be made
smarter is not one I can answer. My intuition would say that the gain
from using not in an argument when compared to the increased
complexity of the parser would not be worth it. For now, I find the
glyph style operators work in all of my code (indeed, I don't ever use
"not").

> I've never encountered a language where f(x) was OK but f(not(x))
> wasn't, so this is Surprising (TM). I mean, it works in Perl, for example.

I doubt the fact that language X can do something has any bearing on
how Ruby will handle this in the future. This is entirely up to Matz
and what he thinks servers the language (and its implementation) best.
You better be prepared for many surprises in most languages. Ruby is
no exception. It happens to bet on the fact that Matz knows Ruby
considerably better than most of us.

Brian.