[Haskell-cafe] Re: Re: non-total operator precedence order (was:Fractional/negative fixity?)

[Benjamin Franksen]

Jan-Willem Maessen wrote:
> On Nov 9, 2006, at 7:16 PM, Benjamin Franksen wrote:
>> Carl Witty wrote:
>>> If you have operators op1 and op2, where the compiler sees
>>> conflicting
>>> requirements for the precedence of op1 and op2, then they are
>>> treated as
>>> non-associative relative to each other: the expression
>>>   a op1 b op2 c
>>> is illegal, and the programmer must instead write
>>>   (a op1 b) op2 c
>>> or
>>>   a op1 (b op2 c)
>>
>> It's a possibility. However, I fear that such conflicting
>> precedences might
>> not come in nice little isolated pairs. For instance, each operator
>> that is
>> in the same precedence class as op1 (i.e. has been declared as
>> having equal
>> precedence) will now be 'incompatible' with any that is in the same
>> class
>> as op2, right?
> 
> Well, look at it from the perspective of the reader.  Does the reader
> of your code know beyond a shadow of a doubt what the intended
> precedence will be in these cases?  If not, there should be
> parentheses there---quite apart from what the parser may or may not
> permit you to do.  If the parser can't figure it out, you can bet
> your readers will have trouble as well.

Imagine op1=(+), op2=(*). Would you think that it is acceptable if any wild
module can come along and destroy the relative precedence order everyone
espects to hold between those two?

For this to happen it would be enough if M1 says

  prec (<+>) = prec (+)
  prec (<*>) = prec (*)

while M2 says

  prec (<>) = prec (<*>)

and M3

  prec (<>) = prec (<+>)

All modules M1, M2, and M3, when viewed independently, and even when viewed
in pairwise combination, don't do anything bad. It is only the combination
of all three that cause the expression

  3 + 4 * 3

to become a syntax error!

Ben