[Haskell-cafe] Fixity parsing, Template Haskell

Niklas Broberg niklas.broberg at gmail.com
Sun Nov 23 08:39:21 EST 2008

> On Sun, Nov 23, 2008 at 8:23 AM, John A. De Goes <john at n-brain.net> wrote:
>> Though many see it as "losing" information, I agree wholeheartedly with your
>> proposal to change the AST.
>> It's better to have an AST that conveys less information, but truthfully,
>> than to have an AST that purports to convey more information, when in fact
>> that information is false.
>> In most languages, some things just can't be known at parse time. They need
>> to be resolved later.

While I agree with you in principle, that the rule of least surprise
should be adhered to, I don't agree in this instance. You are assuming
that the AST is only used by the parser, and if that was true I would
agree with you. But HSE is just as much a library for *building* an
AST using combinators. If I changed the AST to one carrying less
information, it would be impossible to *ever* get the fixities right
in the AST, even for those use cases where the information is known
and possible to use.

> I want this information to be used somehow when creating the Template
> Haskell AST, so that the operators used have the correct fixities. If
> I use HSE for parsing Haskell expressions, then I want it to tell me
> where it unsure of the fixities, so that I can insert the correct ones
> there. For this use case, I would want HSE to use an AST like I
> suggested, because it allows the parser to say, "I'm not sure what the
> correct fixity is".

As noted above, I really don't like that change. If you use HSE for
parsing expressions, it would *never* know the correct fixities, and
you would always get a completely left-biased tree. Why would that be
harder to work with? I understand the argument about least surprise,
and that this feature must be strongly documented (which it currently
isn't), but for practical purposes I don't see why the current state
would be problematic. It should even be trivial to convert the
left-biased tree into an intermediate structure exactly like the one
you suggest, no?



More information about the Haskell-Cafe mailing list