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

What you've described is the basic predence difference between
"and"/"or" and "&&"/"||". Consider the following:

name = "evan" or "john"    =>      (name = "evan") or "john"
name = "evan" || "john"     =>      name = ("evan" || "john")

This puzzled me at first, but the semantics of it have grown on me.

The same goes for your examples though. Now, I'd agree that at first,
the fact that "and" is different from "&&" is a bit.. strange. But
remember that it seems from the fact that "and" is a parser directive
that creates an actual AND node in the AST. Where as, && is simply a
binary operator, and thus a normal method call.

This debate has been going on for quite a long time and I think that
the current behavior will probably never change. The best thing that
the community could do is to properly document this behavior so that
it becomes a non-issue.

 - Evan Phoenix <[e-mail]>

On 3/19/06, Robert Dober <[e-mail]> wrote:
> Dear all
>
> Are'nt we missing something here?
> I think that one of the many strengths of Ruby is that it *normally* does
> what you'd expect it to do?
>
> Are we sure that this rather courious exception is really worth it?
> I cannot really get that feeling.
>
> I even dare tracing this back, though I might be dead wrong of course, to
> the low precedence of "not", it just seems wrong.
> In order to enlighten me.
> Would someone care to explain the benefits of that low precedence to me?
>
> not true and false => (not true) and false => false
> not trua && false => not( true && false)  => true
>
> The two lines above frighten me a little bit.
>
> A philosophical discussion of, if one should write these expressions without
> "("s or not might be in order, but that is not what I am looking for. I just
> want someone to tell me, "hey you are right" ;)
>
> Thaughts?
>
> Cheers
> Robert
>
> On 3/16/06, Brian Mitchell <[e-mail] > wrote:
> >
> > 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.
> >
> >
>
>
> --
> Deux choses sont infinies : l'univers et la b黎ise humaine ; en ce qui
> concerne l'univers, je n'en ai pas acquis la certitude absolue.
>
> - Albert Einstein
>
>


--
When I do good, I feel good;  when I do bad, I feel bad,
and that is my religion.
    -- Abraham Lincoln (1809 - 1865)