January 2019 - Libraries

Re: taking over `bitvec`, `gamma`, `hs-hd5f` etc.
by Marco Zocca 18 Jan '19

18 Jan '19

Hi all, I had also tried recently to contact James Cook regarding maintainership of `gamma` (https://github.com/mokus0/gamma/pull/4) and three years ago about `hs-hdf5` (https://github.com/mokus0/hs-hdf5/issues/4#issuecomment-244511986) but he seldom checks email and github issues it seems. First of all, I hope he is well, and second, I once more volunteer to help with the maintenance of these packages. Best, Marco > Today's Topics: > > 1. Taking over maintainership of bitvec (Andrew Lelechenko) > > I would like to take over `bitvec` package > (https://hackage.haskell.org/package/bitvec) > > Unfortunately, the source code has not been updated for years and the > test suite does not build nowadays. There are also known issues. I > have prepared patches and tried to reach its maintainer James Cook > (cced) by email, but have not heard back. > > There was a takeover of another James' package in October 2018 > (https://mail.haskell.org/pipermail/libraries/2018-October/029062.html) > In that case James appeared to be out of reach. > > -- > Best regards, > Andrew >

2 1

Taking over maintainership of bitvec
by Andrew Lelechenko 17 Jan '19

17 Jan '19

I would like to take over `bitvec` package (https://hackage.haskell.org/package/bitvec) Unfortunately, the source code has not been updated for years and the test suite does not build nowadays. There are also known issues. I have prepared patches and tried to reach its maintainer James Cook (cced) by email, but have not heard back. There was a takeover of another James' package in October 2018 (https://mail.haskell.org/pipermail/libraries/2018-October/029062.html) In that case James appeared to be out of reach. -- Best regards, Andrew

1 0

How about a "deriving defaulted" deriving strategy
by Andrew Martin 15 Jan '19

15 Jan '19

I was just doing the usual incantation for an exception type: data DatagramException = ... deriving stock (Eq,Show) instance Exception Datagram And it suddenly hit me what a shame it was that I cannot put the Exception instance in a deriving clause like the others. It would be more visually pleasing to write: data DatagramException = ... deriving stock (Eq,Show) deriving defaulted (Exception) -- -Andrew Thaddeus Martin

2 2

Data.List.maximumBy uses counter-intuitive ordering
by Johannes Waldmann 09 Jan '19

09 Jan '19

Dear all, this was brought up on the GHC tracker (not by me) https://ghc.haskell.org/trac/ghc/ticket/15921 and it was suggested for discussion here. my summary: Data.List.maximumBy is right-biased, minimumBy is left-biased, and none of this is documented. - J.W.

8 7

Crazy suggestion: ByteString -> Bytes
by Merijn Verstraaten 09 Jan '19

09 Jan '19

Ok, so I think there is a fairly wide consensus that the name ByteString is a pretty misleading historical naming mistake. On the other hand, I also realise bytestring is at the very core of the Haskell ecosystem and any breakage has to be avoided at all cost... So I was just wondering on IRC what (if any?) problems we'd run into if we released a "bytes" package that's just s/ByteString/Bytes of bytestring (Data.Bytes, Bytes type, etc) then turn bytestring into a hollow shell that just re-exports Data.Bytes as Data.ByteString, etc. and defines "type ByteString = Bytes". I realise there's no way we'll get rid of bytestring itself any time soon (if ever), but at least we could point new code and beginners at a less confusingly named type. Added bonus Bytes is considerably shorter to type! Cheers, Merijn

3 2

re: cabal bootstrap
by Harley Leyton 08 Jan '19

08 Jan '19

Output is the same as in https://github.com/haskell/cabal/issues/5391 [ 1 of 215] Compiling Distribution.Compat.Binary ( Distribution/Compat/Binary.hs, Distribution/Compat/Binary.o ) [ 2 of 215] Compiling Distribution.Compat.Directory ( Distribution/Compat/Directory.hs, Distribution/Compat/Directory.o ) [ 3 of 215] Compiling Distribution.Compat.Exception ( Distribution/Compat/Exception.hs, Distribution/Compat/Exception.o ) [ 4 of 215] Compiling Distribution.Compat.Internal.TempFile ( Distribution/Compat/Internal/TempFile.hs, Distribution/Compat/Internal/TempFile.o ) [ 5 of 215] Compiling Distribution.Compat.MonadFail ( Distribution/Compat/MonadFail.hs, Distribution/Compat/MonadFail.o ) [ 6 of 215] Compiling Distribution.Compat.Newtype ( Distribution/Compat/Newtype.hs, Distribution/Compat/Newtype.o ) [ 7 of 215] Compiling Distribution.Compat.Semigroup ( Distribution/Compat/Semigroup.hs, Distribution/Compat/Semigroup.o ) [ 8 of 215] Compiling Distribution.Compat.Stack ( Distribution/Compat/Stack.hs, Distribution/Compat/Stack.o ) [ 9 of 215] Compiling Distribution.Compat.Prelude ( Distribution/Compat/Prelude.hs, Distribution/Compat/Prelude.o ) [ 10 of 215] Compiling Distribution.Compat.ReadP ( Distribution/Compat/ReadP.hs, Distribution/Compat/ReadP.o ) [ 11 of 215] Compiling Distribution.Compat.Parsing ( Distribution/Compat/Parsing.hs, Distribution/Compat/Parsing.o ) [91m [0m[91mDistribution/Compat/Parsing.hs:61:1: error: [0m[91m Could not find module[0m[91m `Text.Parsec' [0m[91m Use -v to see a list of the files searched for. [0m[91m | 61 | import qualified Text.Parsec as Parsec [0m[91m | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [0m[ 12 of 215] Compiling Distribution.Compat.Graph ( Distribution/Compat/Graph.hs, Distribution/Compat/Graph.o ) [ 13 of 215] Compiling Distribution.Compat.GetShortPathName ( Distribution/Compat/GetShortPathName.hs, Distribution/Compat/GetShortPathName.o ) [ 14 of 215] Compiling Distribution.Compat.DList ( Distribution/Compat/DList.hs, Distribution/Compat/DList.o ) [ 15 of 215] Compiling Distribution.Compat.Lens ( Distribution/Compat/Lens.hs, Distribution/Compat/Lens.o ) [91m [0m[91mDistribution/Compat/Lens.hs:55:1: error:[0m[91m Could not find module `Control.Monad.State.Class' Perhaps you meant Control.Monad.Trans.Class (from transformers-0.5.2.0) Control.Monad.IO.Class (from base-4.10.0.0) Use -v to see a list of the files searched for. | 55 | import Control.Monad.State.Class (MonadState (..), gets, modify) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Do you have the output or something? I recall that the bootstrap.sh > script worked last time I tried it. Perhaps GHC used to ship with parsec > and now it doesn't? > > If you provide some broader context I may be able to help - if you're > porting cabal to a new platform you may consider cross-compiling cabal > > On 1/6/19 7:08 AM, Harley Leyton wrote: >> Is there any way to install cabal-install on top of a fresh installation of ghc with bootsrap.sh? I keep getting stuck on https://github.com/haskell/cabal/issues/5391. >> Libraries mailing list >> Libraries at haskell.org> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

1 1

cabal bootsrap
by Harley Leyton 06 Jan '19

06 Jan '19

Is there any way to install cabal-install on top of a fresh installation of ghc with bootsrap.sh? I keep getting stuck on https://github.com/haskell/cabal/issues/5391.

2 1

Consider operator fixity when deriving Show or Read
by Dannyu NDos 06 Jan '19

06 Jan '19

For the following code as an example: {-# LANGUAGE TypeOperators #-} infixr 5 :. data List a = Null | a :. List a deriving (Eq, Ord, Show, Read) The Show instance and the Read instance are inaware of the fixity of (:.): *Main> 2 :. 3 :. Null 2 :. (3 :. Null) *Main> read "2 :. 3 :. Null" :: List Int *** Exception: Prelude.read: no parse *Main> read "2 :. (3 :. Null)" :: List Int 2 :. (3 :. Null) The derived instances should be: instance Show a => Show (List a) where showsPrec p Null = showParen (11 <= p) (showString "Null") showsPrec p (x :. xs) = showParen (5 <= p) (go p (x :. xs)) where go _ Null = showString "Null" go p (x :. xs) = showsPrec p x . showString " :. " . go p xs instance Read a => Read (List a) where readPrec = parens $ do Ident "Null" <- lexP return Null +++ (do x <- readPrec Symbol ":." <- lexP xs <- readPrec return (x :. xs) )

3 3

Proposal: Rename HashMap.lookupDefault to HashMap.findWithDefault
by Matt Renaud 06 Jan '19

06 Jan '19

*What* *====* Rename unordered-container's Data.HashMap.lookupDefault <https://hackage.haskell.org/package/unordered-containers-0.2.8.0/docs/Data-…> to findWithDefault. findWithDefault :: (Eq k, Hashable k) => v -> k -> HashMap k v -> v Note: There are no functionality changes, this is purely a rename. *Why* *===* This aligns the Data.HashMap API with containers' Data.Map.findWithDefault <https://hackage.haskell.org/package/containers-0.5.11.0/docs/Data-Map-Stric…> . Data.Map.findWithDefault :: Ord k => a -> k -> Map k a -> a The map APIs provided by the two packages are *almost* drop in replacement compatible if you aren't using any of the implementation specific functions (like ordering based functions from Data.Map), this change brings us one step closer. API consistency reduces the cognitive overhead when learning a new package. Having to learn different function names for the same functionality depending on which "map" implementation you're using is a poor developer experience. We chose the containers' name findWithDefault over unordered-containers' lookupDefault for two reasons: 1. Existing lookupX functions returns a Maybe value, while findX functions return a non-wrapped value. 2. The containers package ships with GHC and is a "core" package. *Pros:* *-----* - Consistent API between different "map" implementations (Data.Map, Data.IntMap, Data.HashMap). This makes switching implementations an import change. - Naming matches other similar functions (lookupX return Maybe-wrapped values) *Cons:* *-----* - API change requires users to update their code + unordered-containers has A LOT of users: 358815 total (13325 in the last 30 days) *How* *===* https://github.com/tibbe/unordered-containers/pull/176/commits/152f8818ee13… *Code Changes:* *-------------* - Rename the function in Data.HashMap.Base (and expose it from Strict and Lazy modules) - Make lookupDefault an INLINE alias of findWithDefault - Add DEPRECATION notice to lookupDefault - Bump unordered-containers version to 0.2.9.0 *Migration - Option 1:* *---------------------* *- *Announce on Haskell communication channels (haskell-cafe@, haskell-community@, #haskell on Twitter, Reddit thread, etc.) - Users of unordered-containers >= 0.2.9.0 receive warning about deprecated function - Code can be updated by find and replace: s/lookupDefault/findWithDefault/ - lookupDefault with deprecation notice remains for 1 year (subject to change) - after 1 year the lookupDefault function is removed, unordered-containers version bumped to 0.3.0.0 (major version bump due to breaking change) *Migration - Option 2:* *---------------------* - Announce on Haskell communication channels (haskell-cafe@, haskell-community@, #haskell on Twitter, Reddit thread, etc.) - Users of unordered-containers >= 0.2.9.0 receive warning about deprecated function - Code can be updated by find and replace: s/lookupDefault/findWithDefault/ - lookupDefault function is never removed *Discussion: * *===========* I would like to get some comments on this proposal. In particular: - Is the small API churn worth the increase in consistency? - Should migration option 1 (completely remove the old function) or 2 (keep old function indefinitely) be taken? We can punt on this and go with option 2 to start and revisit later if desired. I hope a decision about the proposal can be reached by 2018-02-09. Thanks!

6 10