July 2017 - Libraries

Removing bitSize
by David Feuer 05 Feb '18

05 Feb '18

The long-deprecated bitSize method of the Bits class is slated to be removed in base-4.11 (GHC 8.4). There is one remaining question: should we replace it with a *function* by that name with a FiniteBits constraint? I don't feel very strongly either way, but Ryan Scott seems in favor and Edward Kmett seems opposed. So it seems best to bring it to the libraries list and let the CLC make the call. If the function is added, it would look like this: bitSize :: FiniteBits a => a -> Int bitSize = finiteBitSize The biggest downside I see is that we might one day want to reuse the name for something with a better type, such as bitSize :: forall proxy a. FiniteBits a => proxy a -> Int bitSize _ = finiteBitSize (undefined :: a) or bitSize :: forall a. FiniteBits a => Tagged a Int bitSize = Tagged (finiteBitSize (undefined :: a)) or (with type applications) bitSize :: forall a. FiniteBits a => Int bitSize = finiteBitSize (undefined :: a) Thanks, David Feuer

5 5

Discussion: Allow custom constraint for elem in Foldable
by David Feuer 28 Jul '17

28 Jul '17

The Foldable class offers the method elem :: Eq a => a -> t a -> Bool Unfortunately, this is really awful for sets, hash maps, etc. See https://stackoverflow.com/questions/45361801/implement-an-olog-n-foldable-e… for an example. We could fix it, kinda: class Foldable t where type ElemConstr t :: * -> Constraint type ElemConstr t = Eq elem :: ElemConstr t a => a -> t a -> Bool default elem :: (ElemConstr t ~ Eq, Eq a) => a -> t a -> Bool One might legitimately complain that such a wild type is ad hoc, but one might counter that complaint by saying that most of Foldable is already ad hoc. David

7 7

Re: Discussion: Allow custom constraint for elem in Foldable
by Carter Schonwald 28 Jul '17

28 Jul '17

i wasnt aware of such guidelines for the libraries list constrained monads/ functors are still an area of study / experimentation, they need experimentation and more community knowledge before they land in base for core type classes On Thu, Jul 27, 2017 at 8:37 PM, David Feuer <david.feuer(a)gmail.com> wrote: > Off-list: Repeating what Eric Mertens said does not contribute to the > discussion. Perhaps you can offer an answer to my follow-up question to him. > > On Jul 27, 2017 8:26 PM, "Carter Schonwald" <carter.schonwald(a)gmail.com> > wrote: > >> agreed. >> >> this needs to be tested out in a user space lib first. >> >> >> On Thu, Jul 27, 2017 at 7:35 PM, Eric Mertens <emertens(a)gmail.com> wrote: >> >>> I would prefer to see designs for something like this explored in a >>> separate package before we worried about changing base’s Foldable class. >>> >>> > On Jul 27, 2017, at 3:45 PM, David Feuer <david.feuer(a)gmail.com> >>> wrote: >>> > >>> > The Foldable class offers the method >>> > >>> > elem :: Eq a => a -> t a -> Bool >>> > >>> > Unfortunately, this is really awful for sets, hash maps, etc. See >>> > https://stackoverflow.com/questions/45361801/implement-an-ol >>> og-n-foldable-elem-for-binary-search-trees-in-haskell#45362110 >>> > for an example. We could fix it, kinda: >>> > >>> > class Foldable t where >>> > type ElemConstr t :: * -> Constraint >>> > type ElemConstr t = Eq >>> > >>> > elem :: ElemConstr t a => a -> t a -> Bool >>> > default elem :: (ElemConstr t ~ Eq, Eq a) => a -> t a -> Bool >>> > >>> > One might legitimately complain that such a wild type is ad hoc, but >>> > one might counter that complaint by saying that most of Foldable is >>> > already ad hoc. >>> > >>> > David >>> > _______________________________________________ >>> > Libraries mailing list >>> > Libraries(a)haskell.org >>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >>> _______________________________________________ >>> Libraries mailing list >>> Libraries(a)haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >> >> >> _______________________________________________ >> Libraries mailing list >> Libraries(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >>

1 0

Data.List.singleton
by Ben Franksen 27 Jul '17

27 Jul '17

...is a function that seems to be missing from base. It is trivial, of course, but still would be nice to have for symmetry with the modules in container. (apologies if this has been discussed before) Cheers Ben

3 2

Exporting ioToST from Control.Monad.ST
by Andrew Martin 21 Jul '17

21 Jul '17

There's a function stToIO that is defined in GHC.IO and exported from Control.Monad.ST. There's another function, ioToST, that's also defined in IO, but it isn't exported from Control.Monad.ST. I propose that it be exported from Control.Monad.ST. -- -Andrew Thaddeus Martin

2 3

Re: Heterogeneous equality into base?
by Ryan Scott 18 Jul '17

18 Jul '17

Sorry for only just discovering this thread now. A lot of this discussion is in fact moot, since (:~~:) already is in base! Specifically, it's landing in Data.Type.Equality [1] in the next version of base (bundled with GHC 8.2). Moreover, it's constructor is named HRefl, so your wish has been granted ;) As for why it's being introduced in base, it ended up being useful for the new Type-indexed Typeable that's also landing in GHC 8.2. In particular, the eqTypeRep function [2] must return heterogeneous equality (:~~:), not homogeneous equality (:~:), since it's possible that you'll compare two TypeReps with different kinds. Ryan S. ----- [1] http://git.haskell.org/ghc.git/blob/99adcc8804e91161b35ff1d0e5f718d18fcaa66… [2] http://git.haskell.org/ghc.git/blob/99adcc8804e91161b35ff1d0e5f718d18fcaa66…

9 11

Re: Heterogeneous equality into base?
by Ryan Scott 11 Jul '17

11 Jul '17

I also agree that we should keep HRefl a distinct name, and moreover, we should keep :~: and :~~: as distinct datatypes. I'm also on-board with the idea that we should introduce a separate Data.Type.Equality.Hetero module that reexports :~~: and defines heterogeneous counterparts for sym, trans, etc. from Data.Type.Equality. I don't have a strong opinion on how they should be named (e.g., sym vs. hsym). Ryan S.

5 7

Heterogeneous equality into base?
by Wolfgang Jeltsch 07 Jul '17

07 Jul '17

Hi! The module Data.Type.Equality in the base package contains the type (:~:) for homogeneous equality. However, a type for heterogeneous equality would be very useful as well. I would define such a type as follows: > {-# LANGUAGE GADTs, PolyKinds, TypeOperators #-} > > data (a :: k) :~~: (b :: l) where > > Refl :: a :~~: a Is there already such a type in the base package? If not, does it make sense to file a feature request (or would such a proposal be likely to not being accepted for some reason)? All the best, Wolfgang

6 7