| On Tue, 13 Mar 2001, Malcolm Wallace wrote: | > Interestingly enough, all of Hugs, nhc98, and hbc make the same | > mistake. Only ghc rejects the expression, correctly complaining that | > the fixities do not match. | | Why is this common? The language design seems to be correct | and it's not hard to get the implementation right, surely? Getting infix right is one of the hardest parts of parsing Haskell. The main difficulty arises because fixities and priorities can be declared in the source itself (local to definitions - indeed, fixity can be declared /after/ the use of the symbol). Most systems tend to have a liberal parser, accepting all kinds of infix expression, then later on, typically during renaming, they attempt to detect errors and patch-up the expressions given the declared fixity that was in scope. Hbc is the only system that actually changes its parsing rules on-the-fly as it reads a fixity decl. This is one reason why it is interesting that hbc makes the same mistake as Hugs - it shows there is a different mechanism/assumption at work. The mistake arises because of the operator section. After finding the outermost operator, the system (at least in nhc98) simply treats the whole of the rest of the expression as its argument, essentially demoting the sectioned operator to zero priority. Regards, Malcolm P.S. Now fixed in nhc98.