Receiving type information from environment instead of hardcoding.

Ben Gamari ben at
Sun Jun 14 21:32:35 UTC 2020

Rinat Stryungis <lazybonesxp at> writes:

> Hi. I have a question about a possible way of unification of Nat and
> Natural. I've almost done that, but only in case of using integer-gmp.
> If I use integer-simple there is a completely different definition of
> Natural.
> How I construct now naturalTyCon (to make `naturalTy` to use it instead of
> `typeNatKind`) :
> ```naturalTyCon :: TyCon
> naturalTyCon = pcTyCon naturalTyConName Nothing [] [natSDataCon,natJDataCon]
> natSDataCon :: DataCon
> natSDataCon = pcDataCon natSDataConName [] [wordPrimTy] naturalTyCon
> etc...
> ```
> Now I have to check`DynFlags` in a few places to reimplement `naturalTyCon`
> in case of using `integer-simple`.
> Is there a way to avoid hardcoding of `naturalTy`?
> My colleague said that it would be nice to get `naturalTy` from an
> environment by  something like `lookupTyCon`,
> but there are many functions whose don't use any environment like functions
> from `typeNatTyCons` list in `GHC.Builtin.Types.Literals`.
> Now I am going to use `DynFlags` checking, but it looks like an ugly way...

Note that all of this will be moot in a matter of days. The ghc-bignum
patch, which will ship in 8.12, removes integer-simple and uses a
consistent number representation across its various supported backends.

In light of this, if I were you I would probably just settle for a hack
in the meantime.


- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <>

More information about the ghc-devs mailing list