------art_7812_26440096.1142769568518
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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 <binary42 / gmail.com > wrote:
>
> On 3/16/06, mathew <meta / pobox.com > wrote:
> > Brian Mitchell wrote:
> > > On 3/16/06, mathew <meta / pobox.com> 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

------art_7812_26440096.1142769568518--