David House wrote: > Also, it provides an infinite space for fixities. I think the problem > 'binds tighter than X but not as tight as Y', where X and Y are only > fixity integer apart is somewhat common, and this would fix it. It > would allow for extensibility into the future, where the operator > space will only become more dense, and maintaining a complete order > with only 10 integers to play will become more and more difficult. > Allowing an infinite amount of operators to come between any two > operators sounds like a solid design decision to me.
For me, the most important objection to specifying precedence by an embedding into some total order -- be it the integers or the rationals -- is that it forces you to make a global decision, and that threatens modularity. Consider the following scenario: - Two unrelated pieces of code each define an operator (`A` resp. `B`). The writers choose their precedences with due regard to relations to basic operators and maybe other relevant ones, but *not considering their mutual relation*. The last writer may not know about the code of the first one, or did not bother to consider the possibility of mixing it with his code (it is unreasonable to expect a writer to consider the relation to every other existing operator). - At some point, `A` and `B` meet; maybe they are part of two unrelated libraries and a programmer uses them both, or maybe `A` was defined by a programmer who just found out that there exists this wonderful library exporting `B`. - Now, if she is lucky, the relative precedence of `A` and `B` just happens to be nice and logical. If she is unlucky and the relative precedence is really annoying, the precedence of at least one of `A` and `B` will have to change to fix this. However, if you change the precedence of `B`, say, (which currently is "written in stone forever", as Nicolas Frisby put it,) and `B` is an operator of any significance, then you have to send out an announcement to everyone who uses `B`, telling them that its precedence has changed, so they should check if that breaks any of their code. If it does, they may have to change the precedence of other operators, propagating a horrible cascade of realignment. That's a whole yotta words for a small bikeshed, but I think this scenario is actually not far-fetched at all. Specifying precedence 'lazily', by a partial order, does not suffer from this problem, because it only requires you to make local decisions. Kind regards, Arie -- Mr. Pelican Shit may be Willy. ^ /e\ --- _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
