> 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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe