- Libraries - Haskell.org

PROPOSAL: Add `disjoint` method to `Data.IntSet`
by Víctor López Juan 27 Dec '17

27 Dec '17

Proposal: Add a method disjoint :: IntSet → IntSet → Bool, to Data.IntSet, such that prop> disjoint a b ≡ null (intersection a b) Alternatively or additionally, add a method overlaps :: IntSet -> IntSet -> Bool such that prop> a `overlaps` b ≡ not.null$ intersection a b Rationale: - I have found it useful to have such a method when keeping track of the set of free-variables in a term. I believe that there can be more use cases. - There are already similar specialized implementations in the library. For example, isSubsetOf :: IntSet -> IntSet -> Bool is such that prop> a `isSubsetOf` b ≡ (a == (a `intersection` b)). - Having `disjoint`, the user can also check whether two sets overlap with `(not.).disjoint`. This is shorter and more self-explaining than (not.null$ intersection). - A specialized implementation of `disjoint` (vs. (null.).intersection) can shortcircuit as soon as the sets overlap on one element. This leads to significant speed-ups; for example, 23× when checking that the sets {1,2,3…,2¹²} and {2,4,6,…,2¹²} are not disjoint [1]. Discussion: I would like to get some comments on this proposal. In particular: - Should any of these methods be added? - Should both `overlaps` and `disjoint` be added? - If only one of them is added, which one should it be? I hope a decision about the proposal can be reached before 2018-01-09. See also: - Proposed patch [2] - Previous discussion [3] [1] https://github.com/haskell/containers/pull/377#issuecomment-352585171 [2] https://github.com/haskell/containers/pull/377/files [3] https://github.com/haskell/containers/pull/377

8 8

Constrained Dynamic variant
by Ryan Reich 27 Dec '17

27 Dec '17

I have found it useful to use Dynamic-like existential types such as (fake example): > data Number = forall a. (Num a, Typeable a) => Number a which supports precisely the same API as Dynamic, but with a Num constraint on everything. However, writing that API for this particular type requires copy-pasting the definitions of fromDyn and fromDynamic as boilerplate, which is (ahem) stupid. Now that we have the Constraint kind, it is possible to generalize this in a form suitable for Data.Dynamic: > data CDynamic (c :: Type -> Constraint) = forall a. (c a) => CDynamic (TypeRep a) a > > toCDyn :: (c a, Typeable a) => a -> CDynamic c > fromCDyn :: (c a, Typeable a) => CDynamic c -> a -> a > fromCDynamic :: (c a, Typeable a) => CDynamic c -> Maybe a > relaxCDyn :: CDynamic c -> Dynamic > dynApplyC :: CDynamic c1 -> CDynamic c2 -> Maybe Dynamic > dynAppC :: CDynamic c1 -> CDynamic c2 -> Dynamic > dynTypeRepC :: CDynamic c -> SomeTypeRep > > instance Show (CDynamic c) > instance Exception (CDynamic c) > > class NoC a where -- intentionally empty, can be used unsaturated > instance NoC a where -- also empty > type Dynamic = CDynamic NoC > > -- Specializations of all the above functions I think it's clear how to fill in the definitions. I added an apparently necessary function relaxCDyn that also does the obvious thing; I'm not really happy with its type signature but offhand I can't say how to generalize it. I think this is useful, and if I'm not missing anything (obvious or subtle) about it, I want to propose that it goes into Data.Dynamic.

2 1

Adding a member to the Haskell organization
by David Feuer 24 Dec '17

24 Dec '17

Matt Renaud (GitHub user m-renaud) has agreed to join the containers maintenance team. Could someone with the power please add him to the Haskell organization on GitHub?

2 1

Proposal: add `Proxy`fied versions of `bitSizeMaybe` and `finiteBitSize`
by M Farkas-Dyck 19 Dec '17

19 Dec '17

I propose to add the following methods to `Bits` and `FiniteBits` classes: class Bits a where ... bitSizeMaybe' :: Proxy a -> Maybe Int class FiniteBits b where ... finiteBitSize' :: Proxy b -> Int Rationale: working with an arbitrary `Bits a => a`, one may not have a value of type `a` as argument to `bitSizeMaybe` or `finiteBitSize`, and writing `undefined` makes me feel dirty.

8 14

Storable laws
by David Feuer 16 Dec '17

16 Dec '17

The documentation for pokeByteOff indicates that the following equality holds: pokeElemOff addr idx x = poke (addr `plusPtr` (idx * sizeOf x)) x Notably, this ignores alignment. It thus seems to imply that sizeOf must always be a multiple of alignment; otherwise, non-zero indices could access non-aligned addresses. Was this intentional? If so, I believe sizeOf and alignment should document the law. If not, then I believe the {poke,peek}ElemOff laws need to change to something like pokeElemOff addr idx x = poke (addr `plusPtr` (idx * lcm (sizeOf x) (alignment x))) x

4 9

Discussion: Storable instances for tuples
by David Feuer 16 Dec '17

16 Dec '17

It seems surprising that there are no Storable instances for tuple types. I would expect any tuple of Storable types to be Storable. To provide a sensible FFI experience, the order of the fields should be preserved. Since Storable generally aligns values, I believe elements should be aligned within tuples as well, in the default fashion used for C structs. We could offer a Packed newtype to override this behavior. Why store tuples like this, and not the way Data.Vector.Unboxed does? A moment's reflection will show that it simply can't. A Ptr is a single pointer and must remain one; there's no room in it to deal with multiple arrays or extra offset info.

2 1

Re: Proposal: add `Proxy`fied versions of `bitSizeMaybe` and `finiteBitSize`
by Ryan Scott 14 Dec '17

14 Dec '17

I don't have a particular opinion on this proposal, but I did want to chime in to note that there are several other functions in base besides biteSizeMaybe, finiteBitSize, sizeOf, and alignment that take a dummy argument. The last time I checked, all of these functions also fit the bill [1]: * Data.Bits.isSigned :: Bits a => a -> Bool * Data.Data.dataTypeOf :: Data a => a -> DataType * GHC.Generics.datatypeName :: Datatype d => t d f a -> String * GHC.Generics.moduleName :: Datatype d => t d f a -> String * GHC.Generics.isNewtype :: Datatype d => t d f a -> Bool * GHC.Generics.packageName :: Datatype d => t d f a -> String * GHC.Generics.conName :: Constructor c => t c f a -> String * GHC.Generics.conFixity :: Constructor c => t c f a -> Fixity * GHC.Generics.conIsRecord :: Constructor c => t c f a -> Bool * GHC.Generics.selName :: Selector s => t s f a -> String * GHC.Generics.selSourceUnpackedness :: Selector s => t s f a -> SourceUnpackedness * GHC.Generics.selSourceStrictness :: Selector s => t s f a -> SourceStrictness * GHC.Generics.selDecidedStrictness :: Selector s => t s f a -> DecidedStrictness * Prelude.floatRadix :: RealFloat => a -> Integer * Prelude.floatDigits :: RealFloat => a -> (Int, Int) * Text.Printf :: PrintfArg a => a -> ModifierParser Ryan S. ----- [1] This list was taken from http://hackage.haskell.org/package/proxied-0.3/docs/Data-Proxied.html

1 0

Proposal: `Enum` class overhaul
by M Farkas-Dyck 13 Dec '17

13 Dec '17

I propose to add some new methods of `Enum`: class Enum a where ... predMay, succMay :: a -> Maybe a toEnum' :: Integer -> Maybe a fromEnum' a -> Integer Rationale for `fromEnum'` and `toEnum'`: The docs for `Enum` now say the minimal complete definition is `toEnum` and `fromEnum`, but this is not enough to have sane default instances of the other methods, for example: data ABC = A | B | C deriving Show instance Enum ABC where toEnum 0 = A toEnum 1 = B toEnum 2 = C fromEnum A = 0 fromEnum B = 1 fromEnum C = 2 main = print [A ..] -- [A,B,C,*** Exception: Non-exhaustive patterns in function toEnum In this case one could merely derive `Enum`, but not in some other cases, e.g. numeric types or GADTs. It is not possible to do better defining `toEnum` and `fromEnum` alone. If we default-define `toEnum'` and `fromEnum'` and their evil (i.e. partial) syblings in terms of each other, the user need merely define the total methods. Using `Integer` rather than `Int` allows these methods to not fail for types larger than an `Int`, which are not uncommon on 32-bit systems. Rationale for `predMay` and `succMay`: I include these partly for completeness, but `predMay` can not now be defined in general, and `succMay` only cumbersomely in terms of `enumFrom`. Note: All rationales imply "unless one uses `unsafePerformIO`". I'd rather not, myself.

2 2

Maintenance of streaming and streaming-bytestring
by Andrew Martin 11 Dec '17

11 Dec '17

David Feuer brought this up two weeks ago [0]. The maintainer of streaming and streaming-bytestring has been unreachable, and provided his continued absence, I would like to become a maintainer of these two libraries. I have put up PRs fixing issues [1] and I've offered on the issue tracker to become a comaintainer [2]. I use this library a lot at work, so I have an interest in keeping it in good shape. [0] https://mail.haskell.org/pipermail/libraries/2017-August/028141.html [1] https://github.com/michaelt/streaming-bytestring/pull/11 [2] https://github.com/michaelt/streaming-bytestring/issues/19 -- -Andrew Thaddeus Martin

6 12

Add foldMapM to Data.Foldable
by Andrew Martin 07 Dec '17

07 Dec '17

Several coworkers and myself have independently reinvented this function several times: foldMapM :: (Foldable g, Monoid b, Monad m) => (a -> m b) -> g a -> m b foldMapM f xs = foldlM (\b a -> mappend b <$> (f a)) mempty xs I would like to propose that this be added to Data.Foldable. We have the triplet foldr,foldl,foldMap in the Foldable typeclass itself, and Data.Foldable provides foldrM and foldlM. It would be nice to provide foldMapM for symmetry and because it seems to be useful in a variety of applications. -- -Andrew Thaddeus Martin

3 6