Receiving type information from environment instead of hardcoding.

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... -- Best regards. Rinat Striungis

Rinat Stryungis
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. Cheers, - Ben

In light of the mentioned patch, I prefer to freeze my activity about the
unification of Nat and Natural up to the merging this patch. After that, I
am going to rebase my branch and make MR. Thank you, Ben!
пн, 15 июн. 2020 г. в 00:32, Ben Gamari
Rinat Stryungis
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.
Cheers,
- Ben
-- Best regards. Rinat Striungis

FYI ghc-bignum has been merged yesterday. Cheers, Sylvain On 15/06/2020 11:28, Rinat Stryungis wrote:
In light of the mentioned patch, I prefer to freeze my activity about the unification of Nat and Natural up to the merging this patch. After that, I am going to rebase my branch and make MR. Thank you, Ben!
пн, 15 июн. 2020 г. в 00:32, Ben Gamari
mailto:ben@well-typed.com>: Rinat Stryungis
mailto:lazybonesxp@gmail.com> 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.
Cheers,
- Ben
-- Best regards. Rinat Striungis
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
participants (3)
-
Ben Gamari
-
Rinat Stryungis
-
Sylvain Henry