From: Markus <markus@...>
Date: 2004-10-09T14:23:57+09:00
Subject: Re: ANN: Free-form-operators patch

On Fri, 2004-10-08 at 20:59, Jim Weirich wrote:
> Markus wrote:
> >      This is a very good description of why I'm unsure about letting the
> > user set the precedence/associativity/arity.  Do you mind if I use it?
> 
> Please do!

     Thanks.

> > I'm being a bit more conservative at this point: only characters
> > that are already found in ruby operators (and only on combinations that
> > are not already used) may be user defined.
> 
> Hmmm ... I felt my position was the conservative one :-)  I think yours 
> will be quite hard on the programmer.
> 
> Quick, without looking ahead ... which of the following operators can 
> appear in valid ruby code today ...
> 
>      (A)   <-+
>      (B)   +/-
>      (C)   !~~
>      (D)   ++
> 
> I'll comment on something else (to provide spoiler prevention :-)

     I'll reply without reading ahead.  I don't think any of them are
valid operators in a version of ruby without my patch or something like
it.  (D) could occur in the construct x++3, but it would be two
operators.  With my patch, any of them could be used as operators if you
defined them, but (D) would generate a warning and parse as two
operators if you didn't make your intention clear with white space. 
((A) and (B) would also warn.)  I'll read on and see how I did...

> >>[...]  User defined Binary operators should
> >>be the same as the highest precedence binary operator under the unary
> >>operators.
> > 
> > Why the highest?  I know that's how eiffel does it, but I don't
> > recall the rational.  I've also considered some function of the length
> > or contents (such that the built in operators would "fit" the scheme),
> > but I haven't found anything I like. 
> 
> I'm not strongly tied to it being the highest.  Whatever it is, it 
> should be easy to remember.  I don't want to have to remember 35 levels 
> of operator precedence (I can go back to C++ if I want that).
>
> So highest seems like an easy to remember option.  If you have another 
> easy to remember scheme, I would be open to it.

     *sigh*  Alas, I do not.

> Now back to the legal operators ...
> 
> (A) is legal, e.g.    2<-+1    => false
> (B) is illegal, e.g.  2+/-1    => illegal, however, 2/-1 is legal
> (C) is illegal (but I'm not sure why)
>       ! ~~1 is legal, but !~~1 gives strange results
>       try:   ruby -e '!~~1'  and see for yourself.
> (D) is legal, e.g.    ++1      => 1

     Ooooo!  Good catch on (A).  It's three operators though.  The main
cost of this patch is that operators will have to be treated the same
way identifiers are; you can't run them together indiscriminately and
have the compiler guess what you meant.

> Anyways, I'm not sure it will be immediately obvious to the casual 
> observer that +/- is a user defined operator and ++ and <+- are 
> concatenations of existing legal Ruby built in operators.  (Or that !~~ 
> looks like a concatentation of built in operators, but for some reason 
> is not).

     That's why you use white space.  Note that the confusions you
listed were not created by the free form operators, but were present in
the language all along.

-- Markus