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