December 2017 - Libraries

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