[GHC] #14170: 8.2.1 regression: GHC fails to simplify `natVal`
GHC
ghc-devs at haskell.org
Mon Feb 19 13:48:10 UTC 2018
#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
More information about the ghc-tickets
mailing list