Jason Voegele wrote:

>Markus said:
>  
>
>>On Fri, 2004-10-08 at 11:44, gabriele renzi wrote:
>>    
>>
>>>I like the idea of free form operators and actually I'd like even
>>>prefix  freeform ops, if this patch allow them :)
>>>      
>>>
>>Not yet.  I can see how to do it, but haven't quite finished thinking
>>through the details.  I'd also like to have some way to control the
>>precedence/associativity/arity, but I haven't figured out a way to do it
>>that I'm sure could be made consistent.
>>    
>>
>
>FYI, Eiffel has user-defined prefix and infix operators.  The language
>rule is that all user-defined operators have a higher precedence than
>built-in operators.  The built-in operators follow typical precedence
>rules.
>
This is one place that I don't think Eiffel got things quite right.  
Precedence should be defineable, not necessarily higher than all 
built-in operators.  If one is defining a cross-product, e.g., one 
doesn't necessarily want it to be of higher precedence than whatever one 
is using to define the literal representation of the matrix.  And 
ordinary arithmetic might be of even higher precedence.  E.G.:

| .< 1 + 3, 5 * 2, 6 / 3 >. .<n21, n22, n23>. .<n31, n32, n33>. | .*. M
(To allow for varying type faces... there are no doubledots within that 
expression.  They are separated by spaces.  Also, the vertical bars are 
set off by spaces.
Interpretations:
| means start or end a matrix
.< means start a row
 >. means end a row
.*. means cross product
Perhaps this isn't the most elegant notation, but I created it off the 
cuff, and even so I think it's fairly intelligible.  But it wouldn't 
work if the precedence didn't allow it.  This means that .*. and | can't 
have the same precedence.