#14170: 8.2.1 regression: GHC fails to simplify `natVal` -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: Bodigrim Type: bug | Status: new Priority: high | Milestone: 8.2.3 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by phadej): Yes, IMO there is enough motivation to have evidence as `Natural`. We are talking about type level Nats, not Ints. The fact that term value `Natural`s are second-grade citizens in GHC atm is unfortunate. If we are able to constant fold other numeric types, we should be able to do that for `Natural` too. See https://phabricator.haskell.org/D3024 discussion. I'm in great favour of adding `Natural` literal into core. It was untrivial and I didn't pursue that back then, but again IMO it's the right thing to do. Pushing even further, I'd propose to introduce `{-# LANGUAGE NaturalLiterals #-}`, so `2` is desugared to `2 :: FromNatural a => a` where `class fromNatural :: FromNatural a where Natural -> a` (use `Num` or better `FromInteger` if `NegativeLiterals` is enabled and literal is in fact negative). Putting that behind the language extension doesn't break old code (which needs `Num a => a`). Side-question: how constant folding works when cross-compiling, when `Int` is of different bit-widths on host and target? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14170#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler