- Libraries - Haskell.org

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

Proposal: Change Alternative law for some and many
by David Feuer 14 Dec '18

14 Dec '18

Currently, we document this law: > If defined, some and many should be the least solutions of the equations: > > some v = (:) <$> v <*> many v > many v = some v <|> pure [] This seems a bit too strong. I believe we should weaken "should be the least solutions of" to "should obey". This allows non-bottoming implementations for more types. I would be surprised if the change would meaningfully weaken the value of the law for reasoning about real programs. For example, we currently require some Nothing = Nothing some (Just x) = _|_ many Nothing = Just [] many (Just x) = _|_ But if we weaken the law, we could instead use some Nothing = Nothing some (Just x) = Just (repeat x) many Nothing = Just [] many (Just x) = Just (repeat x) This seems strictly, albeit slightly, more interesting. More significantly, I think, the instance for functor products can also get much better-defined: some (x :*: y) = some x :*: some y many (x :*: y) = many x :*: many y That strikes me as an improvement that may actually be of some practical value.

3 9

TestEquality for references
by Edward Kmett 13 Dec '18

13 Dec '18

I'd like to propose adding a bunch of instances for TestEquality and TestCoercion to base and primitive types such as: IORef, STRef s, MVar as well as MutVar and any appropriately uncoercible array types we have in primitive. With these you can learn about the equality of the types of elements of an STRef when you go to testEquality :: STRef s a -> STRef s b -> Maybe (a :~: b) I've been using an ad hoc versions of this on my own for some time, across a wide array of packages, based on Atze van der Ploeg's paper: https://dl.acm.org/citation.cfm?id=2976008 and currently I get by by unsafeCoercing reallyUnsafePointerEquality# and unsafeCoercing the witness that I get back in turn. =/ With this the notion of a "Key" introduced there can be safely modeled with an STRef s (Proxy a). This would make it {-# LANGUAGE Safe #-} for users to construct heterogeneous container types that don't need Typeable information about the values. Implementation wise, these can either use the value equality of those underlying primitive types and then produce a witness either by unsafeCoerce, or by adding new stronger primitives in ghc-prim to produce the witness in a type-safe manner, giving us well typed core all the way down. -Edward

5 11

Safe FFI and Blocking IO
by Andrew Martin 04 Dec '18

04 Dec '18

According to the FFI chapter [1] in the GHC manual, the safe FFI is useful when you need to call a C function that can call back into haskell code. I had always assumed that the scheduler could somehow interrupt safe FFI calls, but the manual does not indicate this, and in some recent testing I did in the posix library [2], I found that scheduling interrupts definitely do not happen. With the non-threaded runtime, the following test always hangs: testSocketsD :: IO () testSocketsD = do (a,b) <- demand =<< S.socketPair P.unix P.datagram P.defaultProtocol _ <- forkIO $ do bytesSent <- demand =<< S.sendByteArray b sample 0 5 mempty when (bytesSent /= 5) (fail "testSocketsD: bytesSent was wrong") actual <- demand =<< S.receiveByteArray a 5 mempty actual @=? sample sample :: ByteArray sample = E.fromList [1,2,3,4,5] demand :: Either Errno a -> IO a demand = either (\e -> ioError (errnoToIOError "test" e Nothing Nothing)) pure In the above example, sendByteArray and receiveByteArray are safe FFI wrappers around send and recv. It is necessary to use threadWaitRead and threadWaitWrite before these calls to predictably get the correct behavior. This brings to my question. In issue #34 on the github library for the unix package [3], there is a discussion about whether to use the safe or unsafe FFI for various POSIX system calls. On the issue there is strong consensus that the safe FFI calls lead to better performance. Simon Marlow writes [4] that "Unsafe foreign imports which can block for unpredictable amounts of time cause performance problems that only emerge when scaling to multiple cores, because they delay the GC sync. This is a really annoying problem if it happens to you, because it's almost impossible to diagnose, and if it happens due to an unsafe call in a library then it's also really hard to fix." And Gregory Collins adds that "If the call would ever block (and that includes most filesystem functions) that means you want 'safe'." There's something I'm definitely missing. My experience is that safe FFI calls do not help with blocking IO (again, I've been using the non-threaded runtime, but I doubt this makes a difference), that they only help with C functions that call back into haskell. However, a lot of other people seem to have a difference experience. [1] https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ffi-chap.ht… [2] https://github.com/andrewthad/posix [3] https://github.com/haskell/unix/issues/34 [4] https://github.com/haskell/unix/issues/34#issuecomment-68683424 -- -Andrew Thaddeus Martin

3 5

Proposal: Add Semigroup/Monoid instance to Data.Functor.Compose
by Daniel Cartwright 30 Nov '18

30 Nov '18

Data.Functor.Compose: newtype Compose f g a = Compose { getCompose :: f (g a) } there's clear-cut, more traditional instances if `f` and `g` are Applicative: instance (Applicative f, Applicative g, Semigroup a) => Semigroup (Compose f g a) where (<>) = liftA2 (<>) instance (Applicative f, Applicative g, Monoid a) => Monoid (Compose f g a) where mempty = pure mempty There's an alternative with `QuantifiedConstraints`, but it's arguable that this is desirable: instance (forall x. Semigroup x => Semigroup (f x), forall x. Semigroup x => Semigroup (g x), Semigroup a) => Semigroup (Compose f g a) where Compose x <> Compose y = Compose (x <> y) Both to seem to fit the commonplace spirit of lifting monoids up through applicative contexts.

2 5