It seems to me that fixity information behaves more like semantics than like syntax. For instance, fixities may be imported, and obey namespacing rules. Knowing and correctly handling these rules seems beyond the scope of a mere parser: I would hope that a single Haskell file could be parsed without reference to any files, and fixity declarations seem to be just about the only thing which prevent this -- hence my suggestion to change the AST in order to regain this property.
The use I envision of it is as I described: writing a quasiquoter using HSE to parse the user's Haskell expressions. The problem is that, for such a case, HSE (or any other parser) is forced to parse infix expressions for which it cannot possibly know the correct fixities. Any result with more information than the list form I gave would be a lie. I realise that I don't know how fixities are implemented in Haskell compilers, so perhaps I'm misunderstanding how they are treated. Cheers, Reiner On Sat, Nov 22, 2008 at 11:54 PM, Niklas Broberg <[EMAIL PROTECTED]> wrote: >> Of course, this would require a change to Template Haskell, so a >> second-best solution would be to forbid unparenthesised expressions in >> my quasiquoter. Then, parsing can proceed correctly without knowing >> the fixities. This would be easiest to do if haskell-src-exts changed >> its AST in a similar way to described above for Template Haskell. > > I'm not sure I follow you here. In what way would it be simpler if HSE > changes its AST to a less-information constructor? I won't do that, > for the same reason you point out with TH and disadvantages when using > it as a library, though I'm still curious what uses you envision and > how it would be made easier. I'm still in the process of designing the > fixity support for HSE, and all input is valuable. :-) > > Cheers, > > /Niklas > _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
