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 <b...@well-typed.com>: > Rinat Stryungis <lazybone...@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
