[Haskell-cafe] Fixity parsing, Template Haskell

[Niklas Broberg]

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

No, this is not correct, they are parsed differently. HSE will return
(the equivalent of)

  InfixApp (Paren (InfixApp "xs" "++" "ys")) "++" "zs"

for the second case, i.e. with explicit parenthesizing of the
subexpression. So they can be and are distinguished, and there would
be no problem with the fixity fixing. However...

> 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"] ["++", "++"]

Indeed, I did not realize that. So that means that this representation
carries strictly *more* knowledge than that binary constructor, which
is of course nice. That certainly makes me somewhat less antagonistic
towards a change along these lines. Hmm...

Cheers,

/Niklas