[Haskell-cafe] Re: Fractional/negative fixity?

[Arie Peterson]

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\
 ---