Re[4]: [Haskell-cafe] Fractional/negative fixity?
Hello Nicolas, Wednesday, November 8, 2006, 1:25:23 AM, you wrote:
prec ?? < $ over-specification). You want ?? to bind more tightly than does $; that's exactly what this approach would let you specify.
and how then compiler will guess that is relational priority of this operator comparing to '$!' ? :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
On Wed, 8 Nov 2006, Bulat Ziganshin wrote:
Hello Nicolas,
Wednesday, November 8, 2006, 1:25:23 AM, you wrote:
prec ?? < $ over-specification). You want ?? to bind more tightly than does $; that's exactly what this approach would let you specify.
and how then compiler will guess that is relational priority of this operator comparing to '$!' ? :)
(What might the smiley mean?) It could not guess it, and this is good! However, if in the Prelude it is defined, that ($) and ($!) have the same precedence, then the compiler could derive automatically that prec ?? < $!.
Bulat Ziganshin schrieb:
Hello Nicolas,
Wednesday, November 8, 2006, 1:25:23 AM, you wrote:
prec ?? < $ over-specification). You want ?? to bind more tightly than does $; that's exactly what this approach would let you specify.
and how then compiler will guess that is relational priority of this operator comparing to '$!' ? :)
For an expression like a ?? b $! c it would have to emit an error message, since it isn't clear whether the programmer meant (a ?? b) $! c or a ?? (b $! c) In fact that wouldn't be clear to a human reader, either, so it's actually a Good Thing that the programmer must explicitly disambiguate the expression! Dan Weston's proposal (let local fixity declarations augment and/or override those imported from the module that defines an operator) would eliminate the pain in code that makes heavy use of both operators. Fractional priorities, on the other hand, would silently resolve this kind of ambiguity. What makes this troublesome is that programmers and maintainers won't always assume the same resolution as the one that the compiler chose; such things are one of the more powerful ingredients for the occasional debugging nightmare. This lesson has already been learned several times now (I know of PL/I and C++, which both have had their share of problems due to overly ambitious defaulting mechanisms). No need to repeat that. Regards, Jo
participants (3)
-
Bulat Ziganshin -
Henning Thielemann -
Joachim Durchholz