December 2018 - Libraries

Deprecating fromIntegral
by Niklas Hambüchen 12 Aug '20

12 Aug '20

This is not a joke. I just found a bug in base (https://ghc.haskell.org/trac/ghc/ticket/14262) import System.IO hWaitForInput stdin 4294968296 This code should wait for 49.something days, but it waits for 1 second. It is caused by a quick use of `fromIntegral` to "convert" `Int -> CInt` (where CInt = Int32), causing an overflow. I argue that `fromIntegral` causes unnoticed data corruption without any warning, and thus are worse than partial functions. In this case, this data corruption occurs in the most fundamental code that we all use and have to rely upon (`base`). So I propose that we add a deprecation pragma to `fromIntegral` (however, keeping it forever, like Java does, as there's no benefit to removing it, we just want that people use safer functions over time), and instead provide a `safeFromIntegral` that can only widen ranges, and one or more `unsafeFromIntegral` or appropriately named functions that can error, wrap, return Maybe, or have whatever desired behaviour when the input value doesn't fit into the output type. For some inspiration, `foundation` provides ideas in that direction: http://hackage.haskell.org/package/basement-0.0.2/docs/Basement-From.html http://hackage.haskell.org/package/basement-0.0.2/docs/Basement-IntegralCon… It is a bit funny how we argue that Haskell is good for high assurance programming, and we build all sorts of fancy constructs to eliminate more run-time errors, when in fact we do worse than C in detecting errors in the most basic types a computer can use, such as converting between 64-bit and 32-bit integers. Let's fix that. It avoids real problems in real production systems that are difficult to debug when they happen (who writes a unit test checking that a timeout of 50 days still works? This is the kind of stuff where you have to rely on -- very basic -- types). I'd like to probe support for such a change before doing any work on it. Niklas

18 58

Deprecate First and Last in Data.Monoid
by Andrew Martin 13 Jun '20

13 Jun '20

I propose that the data types First and Last, provided by Data.Monoid, be marked deprecated in GHC 8.6 and removed in GHC 8.10. The Semigroup-Monoid Proposal (SMP) brought about changes that, I will argue, make these data types (1) unneeded and (2) confusing. Why are they no longer needed? Data.Semigroup provides two identically named data types (First and Last). These have Semigroup instances matches what their names suggest. Additionally, SMP corrects the Monoid instance for Maybe so that it now lifts Semigroup instances instead of Monoid instances. What this means is that, assuming the following imports: import qualified Data.Monoid as M import qualified Data.Semigroup as S We have the following equivalences: M.First a === Maybe (M.First a) M.Last a === Maybe (M.Last a) When I say "equivalence", I mean that their Monoid instances have the same behavior. Their Show/Read instances are certainly different, and I’m not sure about their Ord instances. Getting back to the second reason, removing these data types would eliminate confusion. It’s strange that Semigroup is a superclass of Monoid, yet they have Data types with conflicting names defined in their respective modules. When you see the data type First, you cannot tell what someone is talking additional context. In general, base strives to avoid duplicate identifiers. The only other exception to this rule I can think of is that Bifunctor and Arrow both use the identifiers first and second. But, the situation with Data.Semigroup and Data.Monoid is higher impact since people are more likely to import these modules unqualified together. (As an aside, and the confusion I’m talking about here isn’t entirely hypothetical. I got tripped up by this when I first started using the semigroups library. I had to train myself to stop importing Data.Monoid unqualified, because it kept stealing these identifiers) Again, the two reasons are that these are no longer necessary and that they cause confusion. I would appreciate any feedback, including simple nods of agreement or disagreement. Thanks. -- -Andrew Thaddeus Martin

7 8

Contacting bytestring-trie maintainers
by Tim McGilchrist 07 Feb '19

07 Feb '19

Hi All, I am trying to get in touch with the maintainers for bytestring-trie package ( http://hackage.haskell.org/package/bytestring-trie ), which appears to be Wren Romano. I have a patch to fix issues with GHC 8.4 support. I have sent 2 emails over the last few months using the contact details in the cabal file and haven’t received a reply. Email attached below. Could I ask if someone has a better contact address or is able to pass on the email that they would. Failing that I’d like to get access to push the fix to hackage without the need for making a forked package. Cheers, Tim McGilchrist ——————————————————— Hi Wren, I'm using your bytestring-trie library in a package (airship) and wanted to add support for GHC 8.4.3 to both airship and bytestring-trie. Please find attached a minor patch to add support which is mainly concerned with adding the Semigroup instances required. If you're happy with the changes I'd also appreciate a new release of the package to hackage. Regards, Tim McGilchrist

4 7

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

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 21 Dec '18

21 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 20 Dec '18

20 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