[Haskell-cafe] Fixity parsing, Template Haskell

[Reiner Pope]

On Mon, Nov 24, 2008 at 12:39 AM, Niklas Broberg
<niklas.broberg at gmail.com> wrote:
>> 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?

No, I believe it wouldn't. The left-biased tree cannot distinguish
where parentheses have been used from where HSE inserted its own left
fixities. For instance, if we have the expressions

xs ++ ys ++ zs
(xs ++ ys) ++ zs

Then HSE will return something like (I'm using strings for the
subexpression parses, for simplicity)
   InfixE (InfixE "xs" "++" "ys") "++" "zs"
for both the first and second parses. However, if I then use the
knowledge that ++ is right infix, I will want to convert the first,
but not the second parses into right infix. I can't do this, because
they are both parsed the same way.

I would also like to point out that a list representation as I
suggested can in fact encode the correct fixities if they are known to
HSE. This is true simply because the list constructor is isomorphic to
the current constructor in the special case where the list of
operators has length 1. For instance, in the first example above, if
HSE somehow knew that ++ is right infix, it should return a parse
result of
   InfixE ["xs", InfixE ["ys", "zs"] ["++"]] ["++"]
rather than just
   InfixE ["xs", "ys", "zs"] ["++", "++"]

Cheers,
Reiner

>
> Cheers,
>
> /Niklas
>