#10056: Inconsistent precedence of ~ -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10059 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I few comments as I'm catching up on this thread: * We don't need to conform to any standards here. We're talking about type-level operators, so we're already beyond the Haskell reports. Thinking about standards is a Good Thing, but I just want to note that we're already quite off the map. * I think that, given the laziness annotation wrinkle, `~` will have to stay somewhat magical in the parser. (That may not have been true when this ticket started, as I think allowing laziness annotations in types came about only with `-XStrictData`.) * However, I think we ''can'' eliminate `HsEqTy` from `HsType`. Instead, just use `HsOpTy` with `eqTyCon_RDR` as the operator. Once we get rid of `HsEqTy`, I think we'll be well on our way to solving this ticket. Indeed, that's probably a good approach: get rid of `HsEqTy` and get everything to work again. * Parsing `->` is magical. And it has to be: we can write `forall a. a -> forall b. b -> (a,b)`, for example. `forall` can't appear to the right of other operators. And `->` has various other special things about it (like being able to appear in record GADT syntax). So we have to keep this in mind. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10056#comment:27 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler