
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