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

[Benjamin Franksen]

Henning Thielemann wrote:
>  Maybe making fixity declarations like type class instance declarations is
> good.

I thought so too at first but, having thought about it for a while, I now
see this will cause /major/ problems. The precedence relations as declared
explicitly by the programmer must form a DAG, with the vertices being the
operator classes with equal precedence. There are two ways you can break
the DAG: by introducing a 'smaller' or 'larger' relation when another
module has already declared them to have equal precedence (resp. the other
way around); or by introducing a cycle. Both can be caused simply by
importing yet another module. I think it would be unacceptable not to
provide some way for the programmer to resolve such conflicts.

One way to do so would be to give an explicit order of 'precedence
declaration priority' (PDP) for conflicting modules. Any rule introduced by
a module with a lower PDP would be dropped (in the order of appearance) if
it causes the DAG to break. Simple to use but the resulting precedence
order would be quite hard to predict!

Another way would be to hide precedence relation(s) in the import
declaration. However, this is practical only if precedence declarations
have a name we can refer to.

The cleanest variant would probably be to tear holes in the graph by
removing all relations to a particular operator from the graph, making it
an isolated vertice, and then re-introducing new precedence relations for
this operator. You might have to do this with several operators and it
would be quite difficult to find the minimal set of operators that together
will do the trick (i.e. restore the DAG). Even if you manage to find out,
it could well be that by removing an operator from the graph you will
accidentally remove many other operators, too, for instance if all these
other operators have been declared to have the same precedence than the one
you removed.

I am not a graph specialist; maybe there exist semi-automatic solutions for
such problems in the literature, anyway I know of none, and it would would
in any case be quite a 'heavy' extension.

All in all, in must agree with Nils and say that I can't see a light-weight
and elegant way to make this work. Too bad, really.

Ben