On Fri, 2004-10-08 at 20:32, trans. (T. Onoma) wrote:
> On Friday 08 October 2004 11:12 pm, 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?
> |
> |      The best answer I have come up with so far, is to require that if
> | they're compile-time properties are changed they must be declared before
> | their first use, and that any additional declaration must match.
> | Declarations of this sort are not commonly done in ruby (but they are
> | not unheard of either).
> 
> Just a thought. Since you are already using only character already used in 
> Ruby operators (which I think is good idea) then you may also fix the 
> precedence according to those. You would just need to come up with good set 
> of rules. For example, where R means one or more other op-chars:
> 
>   Ruby (high to low)        User defined examples with same precedence
>   **                        R** **R R**R  (contains ** goes right to top)
>   ! ~ + -                   all unary operators (can we do those 'def @++' ?)
>   * / %                     *R /R %R
>   + -                       +R -R
>   &                         &R
>   ^ |                       ^R |R
>   < >                       <R R>
>   =                         =R R=R  (equals on end illegal)
> 
> It may have to be a bit more complex then that but you get the idea. Like I 
> said, just a thought.

     That was my "doodle in meeting" project for a few days last week. 
I didn't come up with anything I liked.  For example, what do you do
with something that comprises two or more extant operators?  How do you
decide which part is the R and which is not-R?  How do you find the
buddha-nature of a missmatched pair of socks?  And what if there is a
chance congruence hidden in an operator that the users don't see?

     I'll add you suggestions to my notes, but I'm not optimistic about
that path.

   -- Markus