February 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

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

Re: Storable laws
by Henning Thielemann 07 Mar '18

07 Mar '18

On Sun, 17 Dec 2017, Merijn Verstraaten wrote: > Tools like hsc2hs already pad the result of sizeOf to the appropriately > aligned size (at least the ones I've used), so this is a non-issue for > that scenario. But that's tailored to C. If I understand Sven correctly, then this is not valid for Storable.

5 7

Re: Proposal: Add Eq1 and Ord1 instances in GHC.Generics, and synchronize with Data.Functor.* types
by Ryan Scott 25 Feb '18

25 Feb '18

> - GHC.Generics is missing Eq1, Ord1, Show1, Read1 instances I'd be in favor of this idea. However, see my caveat below. > Data.Functor.* is missing Semigroup and Monoid instances (that my > previous proposal would add to GHC.Generics) This is (or was) by design. See [1] for the full story. We migrated the Data.Functor.* module hierarchy from transformers, which is a library that is very much committed to using a Haskell98 style of code. The style of Semigroup/Monoid instances you're proposing to be added would not be Haskell98, since an instance like this: instance Monoid (f (g p)) => Monoid (Compose f g p) Would not be Haskell98 due to its use of FlexibleContexts. Of course, there are other ways one could conceivably define Monoid instances for these classes that are Haskell98, but as Edward noted in [1], they each had subtle flaws. So, we punted on the idea of adding Semigroup/Monoid instances at the time. Now granted, we didn't adhere to this Haskell98 philosophy everywhere. We did add Data instances for Compose et al., for example, and those require FlexibleContexts due to the way they work. But Data is a GHC-specific class, so this exception is somewhat understandable. However, you're proposing we make an exception for Semigroup/Monoid. Is this OK? Granted, the Haskell Report mentions neither to my knowledge, but at the same time, nothing about them requires FlexibleContexts on the surface. So I'm a bit ambivalent about the idea. Now, back to Eq1, Ord1, Show1, and Read1. The arrival of these classes into base predates GHC.Generics, so when Eq, Ord, Read, and Show instances were added for the data types in GHC.Generics, they were of the form: instance (Eq (f (g p)) => Eq ((f :.: g) p) instance (Ord (f (g p)) => Ord ((f :.: g) p) ... Of course, this is not what is done for the data types in the Data.Functor.* hierarchy. For instance, there we have: instance (Eq1 f, Eq1 g) => Eq (Compose f g p) instance (Ord1 f, Ord1 g) => Ord (Compose f g p) ... So while we could add Eq1, Ord1, Read1, and Show1 instances for the data types in GHC.Generics, it does serve as a reminder that the corresponding Eq, Ord, Read, and Show instances are inconsistent with the ones from the Data.Functor.* space. Personally, I don't think this need be a dealbreaker—after all, Eq1 et al. simply weren't around at the time. It just means that if we ever have a (theoretical) merger of the data types between Data.Functor.* and GHC.Generics, we'd have to pick one style of Eq/Ord/Read/Show instances over the other. But this is a bridge we need not cross now. *tl;dr* I'm +1 in favor of your first idea, and ambivalent about your second idea. Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/ticket/11135#comment:25

1 0

Proposal: Add Eq1 and Ord1 instances in GHC.Generics, and synchronize with Data.Functor.* types
by Li-yao Xia 25 Feb '18

25 Feb '18

Eq1 and Ord1 are two more useful classes to implement in GHC.Generics, and would be useful to derive Eq1 and Ord1 generically. Note that we can currently use transformers-compat to derive these. Moreover, most of the GHC.Generics types are equivalent to types in the Data.Functor.* modules. Would it be a good idea for them to have the same instances? Concretely, the current differences are: - GHC.Generics is missing Eq1, Ord1, Show1, Read1 instances - Data.Functor.* is missing Semigroup and Monoid instances (that my previous proposal would add to GHC.Generics) Li-yao

1 0

Re: Proposal: Add Applicative (and Monoid) instances in GHC.Generics (Libraries Digest, Vol 174, Issue 27)
by Ryan Scott 23 Feb '18

23 Feb '18

Those Monoid instances (and Semigroup instance for V1) you propose sound reasonable. I'd also be fine with adding Monoid instances for Par1, Rec1, and (:.:), since we already define other instances like Eq, Ord, Read, and Show for them. Besides, if we don't add them this time around, someone else will just ask for them later :) Ryan S.

1 0

Re: Proposal: Add Applicative (and Monoid) instances in GHC.Generics
by Ryan Scott 22 Feb '18

22 Feb '18

In response to each of your proposals: > 1. Add an instance (Monoid c => Applicative (K1 i c)) This seems like a no-brainer to me. +1 > 2. Add helpers > > gmempty :: (Generic a, Applicative (Rep a)) => a > gmempty = to (pure ()) > > gmappend :: (Generic a, Applicative (Rep a)) => a -> a -> a > gmappend a b = to (from a <*> from b) > > -- also gpure, gap for generic Applicative I'm weakly -1 on this. I don't think GHC.Generics should be a place where we collect combinators for generically implementing various type class methods. I'd prefer that these be left to downstream libraries, especially since they're usually extremely straightforward to implement and wouldn't cross the Fairbairn threshold for me. > 3. Add Monoid instances I think I support this idea. But just to be sure we're on the same page: can you say which instances in particular you're adding, and how you'd implement them? Ryan S.

4 3

Spam on Hackage
by Marco Zocca 22 Feb '18

22 Feb '18

Hi all, I've just noticed two clearly fraudulent/spammy library entries: https://hackage.haskell.org/package/my-test-docs https://hackage.haskell.org/package/Facebook-Password-Hacker-Online-Latest-… I think it would be appropriate to delete them and ban the user (which seems to be a sock puppet account anyway). Kind regards, Marco

2 1

Proposal: Add Applicative (and Monoid) instances in GHC.Generics
by Li-yao Xia 20 Feb '18

20 Feb '18

I propose to implement Applicative (and Monoid) instances in GHC.Generics, where possible. Note that we already have Applicative instances for most of those types, with the notable exceptions of sums (:+:) (for good reason), and K1 (which is basically Const). This would make it possible to easily derive Applicative and Monoid for generic product types. That can be useful to merge large configuration records, for example. For that purpose, the missing Applicative instance for K1 is the actual limiting factor, as it is sufficient in order to derive the product Monoid and Applicative via Generic and Generic1, respectively. The Monoid instances for the GHC.Generics constructors might just be fluff on top of this. Current alternatives include: roll your own, semigroups [1], or some generic programming library (e.g., one-liner). This proposal offers a more lightweight solution. To summarize, and to organize bikeshedding, I would split this proposal in three parts, in order of perceived usefulness: 1. Add an instance (Monoid c => Applicative (K1 i c)) 2. Add helpers gmempty :: (Generic a, Applicative (Rep a)) => a gmempty = to (pure ()) gmappend :: (Generic a, Applicative (Rep a)) => a -> a -> a gmappend a b = to (from a <*> from b) -- also gpure, gap for generic Applicative 3. Add Monoid instances Regards, Li-yao [1] https://hackage.haskell.org/package/semigroups-0.18.4/docs/Data-Semigroup-G…

1 0

Re: [core libraries] Re: Proposal: Debug.Trace.traceWith
by Gershom B 20 Feb '18

20 Feb '18

From: Joachim Breitner <mail(a)joachim-breitner.de> > But on the other hand, pointfree.io tells me that you can write > > trace =<< f > trace =<< show . f > > so I'm not sure how urgent these are. Nifty! If we add this prominently to the docs in Data.Trace, wouldn’t that suit us better? If I’m not mistaken, those make use of the unwrapped reader monad? In my opinion, that is an instance that is confusing and unidiomatic to many people. I don’t think that “easy to write with unwrapped reader” is the same as “easy to write” (or “easy to understand”). I wouldn’t want core docs to recommend this as an approach. -g

3 2