Ticket #207 (new bug report)

Opened 7 years ago

Last modified 7 years ago

Fixity resolution incorrectly handles shadowed operators

Reported by: benmachine Owned by: nibro
Priority: major Milestone:
Component: parser Version: 1.9.x
Keywords: Cc:


When an operator name is shadowed, haskell-src-exts continues to use the fixity from the outer scope. This is obviously wrong when the operator carries its own fixity declaration (I think this is merely a problem of adding the new fixities to the front of the list rather than the back) but in fact shadowing an operator without a fixity declaration should reset it to infixl 9 - so we have the somewhat trickier problem of detecting when any new operator names are introduced that might shadow an outer definition. In the extreme case with TH or a quasiquoter this is actually impossible, I think, but it would still be nice to respect the (admittedly quite rare) case of an operator name defined inline.

An example of where this would go wrong is the following definition that lambdabot gives for on:

(*) `on` f = \x y -> f x * f y

In the RHS here, HSE would give * fixity 7, when it should really have fixity 9. In this case it wouldn't make a difference, but it's not hard to construct cases where it would.

Change History

Changed 7 years ago by benmachine

  • version 1.8.2 deleted

For a proper testcase, try:

ghci> parseExp "let ($) a b = a - b in 3 $ 4 $ 5"
ParseOk (Let (BDecls [FunBind [Match (SrcLoc {srcFilename = "<unknown>.hs", srcLine = 1, srcColumn = 5}) (Symbol "$") [PVar (Ident "a"),PVar (Ident "b")] Nothing (UnGuardedRhs (Var (UnQual (Ident "a")))) (BDecls [])]]) (InfixApp (Lit (Int 3)) (QVarOp (UnQual (Symbol "$"))) (InfixApp (Lit (Int 4)) (QVarOp (UnQual (Symbol "$"))) (Lit (Int 5)))))

i.e. we get associated to the right, whereas:

ghci> let ($) a b = a - b in 3 $ 4 $ 5

is clearly associating to the left.

Changed 7 years ago by nibro

  • version set to 1.9.x
Note: See TracTickets for help on using tickets.