> On Sun, Nov 23, 2008 at 8:23 AM, John A. De Goes <[EMAIL PROTECTED]> wrote: >> Though many see it as "losing" information, I agree wholeheartedly with your >> proposal to change the AST. >> >> It's better to have an AST that conveys less information, but truthfully, >> than to have an AST that purports to convey more information, when in fact >> that information is false. >> >> In most languages, some things just can't be known at parse time. They need >> to be resolved later.
While I agree with you in principle, that the rule of least surprise should be adhered to, I don't agree in this instance. You are assuming that the AST is only used by the parser, and if that was true I would agree with you. But HSE is just as much a library for *building* an AST using combinators. If I changed the AST to one carrying less information, it would be impossible to *ever* get the fixities right in the AST, even for those use cases where the information is known and possible to use. > 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? Cheers, /Niklas _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
