- Libraries - Haskell.org

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

08 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 08 Jan '19

08 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 07 Jan '19

07 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 05 Jan '19

05 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

Data.List.maximumBy uses counter-intuitive ordering
by Wiebe-Marten Wijnja 28 Dec '18

28 Dec '18

//>/> my summary: Data.List.maximumBy is right-biased, />/> minimumBy is left-biased, and none of this is documented. / > Btw. Data.Semigroup exports Min and Max that are both left-biased The difference between these two pairs of functions that are very similar (and one will with high probability first or more frequently use `Data.Semigroup.min/max` until one encounters a data-structure that e.g. needs to be sorted in different ways in different contexts, which is when minimumBy/maximumBy enter the stage.) All five Haskell developers I know personally that I asked about what they expected of the code snippet (that was also given in the GHC issue, #15921): ``` Data.List.maximumBy (Data.Ord.comparing snd) [(0, 1), (3, 2), (2, 2), (1, 1)] ``` expected it to use right-biased ordering in the implementation. (making the outcome `(3, 2)` whereas in reality it will be `(2, 2)` I believe that we should: - align the implementations of minimumBy/maximumBy with Data.Semigroup.min/max to make sure it follows the principle of least surprise. - If not possible (for instance, if there is a good reason that is as of yet unknown to me to keep the current behaviour), we should improve the current documentation with the current bias behaviour. (or potentially instead make it explicitly implementation-defined with a statement like 'you should not assume a specific ordering between items that are considered equal by the chosen relation'). Thank you, ~Wiebe-Marten Wijnja/Qqwy

1 0

Benchmarks for the Event Manager?
by Andrew Martin 22 Dec '18

22 Dec '18

Are there any easy-to-build benchmarks for the GHC event manager? There's some stuff in https://github.com/tibbe/event, but that repo hasn't been touched in 9 years, and it looks like the benchmarks in it were not pulled into GHC itself. I've found some stuff for benchmarking the event manager against stdio (an alternative event manager than builds on top of libuv), but I wanted to check and see if there are any other benchmark suites out there. -- -Andrew Thaddeus Martin

3 4

Fwd: Applicative-based definitions in Data.Foldable
by Isaac Elliott 20 Dec '18

20 Dec '18

With the introduction of the 'Ap' monoid in base-4.13, it seems like Applicative based definitions for common folds would be appropriate in base. For example: > allA :: (Applicative f, Foldable t) => (a -> f Bool) -> t a -> f Bool > allA f = fmap getAll . getAp . foldMap (Ap . fmap All . f) > > all :: Foldable t => (a -> Bool) -> t a -> Bool > all f = runIdentity . allA (Identity . f) I've personally written the Applicative version in everyday code. Thoughts? Isaac

2 1

Dump core of base
by Andrew Martin 19 Dec '18

19 Dec '18

How does one go about using -ddump-simpl -dsuppress-all -ddump-to-file (or variations of this) when building base? I've got some strong suspicions that that are arguments to event manager functions that are morally strict that go unnoticed by demand analysis. However, I need to dump base's core to confirm this. -- -Andrew Thaddeus Martin

5 5