[Haskell-cafe] Fixity parsing, Template Haskell
niklas.broberg at gmail.com
Sun Nov 23 16:20:14 EST 2008
> 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...
More information about the Haskell-Cafe