- Libraries - Haskell.org

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

Proposal: Remove Semigroup and Monoid instances for Data.Map, Data.IntMap, Data.HashMap
by David Feuer 17 Feb '18

17 Feb '18

Many people have recognized for years that the Semigroup and Monoid instances for Data.Map, Data.IntMap, and Data.HashMap are not so great. In particular, when the same key is present in both maps, they simply use the value from the first argument, ignoring the other one. This somewhat counter-intuitive behavior can lead to bugs. See, for example, the discussion in Tim Humphries's blog post[*]. I would like do do the following: 1. Deprecate the Semigroup and Monoid instances for Data.Map.Map, Data.IntMap.IntMap, and Data.HashMap.HashMap in the next releases of containers and unordered-containers. 2. Remove the deprecated instances. 3. After another several years (four or five, perhaps?), make a major release of each package in which the instances are replaced with the following: instance (Ord k, Semigroup v) => Semigroup (Map k v) where (<>) = Data.Map.Strict.unionWith (<>) instance (Ord k, Semigroup v) => Monoid (Map k v) where mempty = Data.Map.Strict.empty instance Semigroup v => Semigroup (IntMap v) where (<>) = Data.IntMap.Strict.unionWith (<>) instance Semigroup v => Monoid (IntMap v) where mempty = Data.IntMap.Strict.empty instance (Eq k, Hashable k, Semigroup v) => Semigroup (HashMap k v) where (<>) = Data.HashMap.Strict.unionWith (<>) instance (Eq k, Hashable k, Semigroup v) => Monoid(HashMap k v) where mempty = Data.HashMap.Strict.empty Why do I want the strict versions? That choice may seem a bit surprising, since the data structures are lazy. But the lazy versions really like to leak memory, making them unsuitable for most practical purposes. The big risk: Someone using old code or old tutorial documentation could get subtly wrong behavior without noticing. That is why I have specified an extended period between removing the current instances and adding the desired ones. Alternatives: 1. Remove the instances but don't add the new ones. I fear this may lead others to write their own orphan instances, which may not even all do the same thing. 2. Write separate modules with newtype-wrapped versions of the data structures implementing the desired instances. Unfortunately, this would be annoying to maintain, and also annoying to use--packages using the unwrapped and wrapped versions will use different types. Manually wrapping and unwrapping to make the different types work with each other will introduce lots of potential for mistakes and confusion. Discussion period: three weeks. [*] http://teh.id.au/posts/2017/03/03/map-merge/index.html

19 33

Proposal: Make size (from 'unordered-containers') run in constant time
by Alexandre Rodrigues 17 Feb '18

17 Feb '18

Greetings; This email's purpose is to request comments from this mailing list regarding a PR to ‘unordered-containers’ (here: https://github.com/tibbe/unordered-containers/pull/170) This PR modifies the existing code so that ‘size’ can calculate the size of a ‘Hash{Map, Set}’ in constant time instead of linear, which is its current performance. To avoid making this message too large, the benchmarking results are not included here, but you may find them in the PR’s discussion. In short, a penalty of about 10% to functions in the library may be expected, and both ‘filterWithKey’ and ‘fromListWith’ are much slower, which is an issue I’d like to solve. If this PR is mediocre, if you have any suggestions to make it better, or any other comment, please reply to this email. I'd like to thank David Feuer and Niklas Hambüchen for the many improvements suggested to this PR, and Johan Tibell for writing an excellent library.

1 0

Disabling deprecated functions
by David Feuer 14 Feb '18

14 Feb '18

The time has come to remove some deprecated functions from containers. As many know, lots of people ignore deprecation warnings. That means there are probably plenty of people still using the deprecated functions. Right now, the functions work, and give deprecation warnings telling users what alternatives to use. If I simply remove the functions, users will suddenly have to *actually* do something to fix their code, but they *won't* be given any useful information about how to do it. Ideally, GHC would add a REMOVED pragma, but I don't see any sign that that's happening. Pondering that conundrum today, I came up with something that seems to *mostly* solve the problem: -- We need this class to defer the type error to the call site, rather -- than getting it at the definition site. I think it basically takes advantage -- of the delayed resolution GHC uses to support overlapping instances, -- which is kind of gross. class Error (e :: ErrorMessage) instance TypeError e => Error e insertWith' :: Error ('Text "Data.IntMap.insertWith' is gone. Use Data.IntMap.Strict.insertWith.") => (a -> a -> a) -> Key -> a -> IntMap a -> IntMap a insertWith' _ _ _ _ = undefined Now if someone is still using Data.IntMap.insertWith', they'll get an error message, but a useful one. Great! But there are two downsides: 1. An unqualified, unrestricted import of the module will still use up a perfectly good name for as long as the export is still there. 2. User-defined type errors have only existed since GHC 8.0. So for earlier versions, I'd probably need to just remove the functions, in which case the exports depend on the GHC version, which is unfortunate. In these *particular* cases, I suspect the benefits of this hack outweigh the downsides, because unqualified and unrestricted imports of Data.Map and Data.IntMap are fairly rare. What are others' thoughts on the matter? David

1 1

Re: Proposal: Remove Semigroup and Monoid instances for Data.Map, Data.IntMap, Data.HashMap
by Daniel Cartwright 13 Feb '18

13 Feb '18

I am strongly in favour of this as well. I do not like the newtype approach, I think backwards-*incompatibility* with four to five year-old (or two to three year-old) code is OK. On Tue, Feb 13, 2018 at 3:04 PM, Daniel Cartwright <chessai1996(a)gmail.com> wrote: > I am strongly in favour of this as well. I do not like the newtype > approach, I think backwards-*incompatibility* with four to five year-old > (or two to three year-old) code is OK. > > On Tue, Feb 13, 2018 at 2:59 PM, David Feuer <david.feuer(a)gmail.com> > wrote: > >> I don't think the old proposal was really the right way. >> >> On Tue, Feb 13, 2018 at 2:54 PM, Mario Blažević <mblazevic(a)stilo.com> >> wrote: >> > +1. But whatever happened to your proposal from last May? I don't think >> > there were any objections to it. Would the two proposals be combined, or >> > have you decided to drop the previous one? >> > >> > https://mail.haskell.org/pipermail/libraries/2017-May/028036.html >> > >> > On 2017-05-25 12:55 PM, David Feuer wrote: >> >> A lot of people have wrappers around Data.Map and Data.IntMap to give >> >> them more useful (Semigroup and) Monoid instances. I'd like to add such >> >> wrappers to containers. What we need to be able to do that are *names* >> >> for the new modules. I can't think of any, so I'm reaching out to the >> >> list. Please suggest names! Another question is whether we should take >> >> the opportunity of new modules to modernize and streamline the API a >> >> bit. I'd like, at least, to separate "safe" from "unsafe" functions, >> >> putting the unsafe ones in .Unsafe modules. >> > >> > >> > >> > On 2018-02-13 02:33 PM, David Feuer wrote: >> >> >> >> Many people have recognized for years that the Semigroup and Monoid >> >> instances for Data.Map, Data.IntMap, and Data.HashMap are not so >> >> great. In particular, when the same key is present in both maps, they >> >> simply use the value from the first argument, ignoring the other one. >> >> This somewhat counter-intuitive behavior can lead to bugs. See, for >> >> example, the discussion in Tim Humphries's blog post[*]. I would like >> >> do do the following: >> >> >> >> 1. Deprecate the Semigroup and Monoid instances for Data.Map.Map, >> >> Data.IntMap.IntMap, and Data.HashMap.HashMap in the next releases of >> >> containers and unordered-containers. >> >> >> >> 2. Remove the deprecated instances. >> >> >> >> 3. After another several years (four or five, perhaps?), make a major >> >> release of each package in which the instances are replaced with the >> >> following: >> >> >> >> instance (Ord k, Semigroup v) => Semigroup (Map k v) where >> >> (<>) = Data.Map.Strict.unionWith (<>) >> >> instance (Ord k, Semigroup v) => Monoid (Map k v) where >> >> mempty = Data.Map.Strict.empty >> >> >> >> instance Semigroup v => Semigroup (IntMap v) where >> >> (<>) = Data.IntMap.Strict.unionWith (<>) >> >> instance Semigroup v => Monoid (IntMap v) where >> >> mempty = Data.IntMap.Strict.empty >> >> >> >> instance (Eq k, Hashable k, Semigroup v) => Semigroup (HashMap k v) >> >> where >> >> (<>) = Data.HashMap.Strict.unionWith (<>) >> >> instance (Eq k, Hashable k, Semigroup v) => Monoid(HashMap k v) >> where >> >> mempty = Data.HashMap.Strict.empty >> >> >> >> Why do I want the strict versions? That choice may seem a bit >> >> surprising, since the data structures are lazy. But the lazy versions >> >> really like to leak memory, making them unsuitable for most practical >> >> purposes. >> >> >> >> The big risk: >> >> >> >> Someone using old code or old tutorial documentation could get subtly >> >> wrong behavior without noticing. That is why I have specified an >> >> extended period between removing the current instances and adding the >> >> desired ones. >> >> >> >> Alternatives: >> >> >> >> 1. Remove the instances but don't add the new ones. I fear this may >> >> lead others to write their own orphan instances, which may not even >> >> all do the same thing. >> >> >> >> 2. Write separate modules with newtype-wrapped versions of the data >> >> structures implementing the desired instances. Unfortunately, this >> >> would be annoying to maintain, and also annoying to use--packages >> >> using the unwrapped and wrapped versions will use different types. >> >> Manually wrapping and unwrapping to make the different types work with >> >> each other will introduce lots of potential for mistakes and >> >> confusion. >> >> >> >> Discussion period: three weeks. >> >> >> >> [*] http://teh.id.au/posts/2017/03/03/map-merge/index.html >> >> _______________________________________________ >> >> Libraries mailing list >> >> Libraries(a)haskell.org >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> >> > >> > _______________________________________________ >> > Libraries mailing list >> > Libraries(a)haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> _______________________________________________ >> Libraries mailing list >> Libraries(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > >

3 2

Proposal: Debug.Trace.traceWith
by Kris Nuttycombe 10 Feb '18

10 Feb '18

When using Debug.Trace for debugging, a very common operation is to prefer to trace only some subset or function of an intermediate result. As a consequence, I propose adding the following function to Debug.Trace: traceWith :: (Show b) => (a -> b) -> a -> a traceWith f a = trace (show $ f a) a While it's trivial to define, I have found this to be one of the most useful functions in my trace-based debugging toolkit, hence my proposal that it be added to base. It generalizes `traceShowId` in a meaningful and useful fashion. As this is the first such proposal I've put forth, please let me know if I'm doing anything wrong with it! Thanks, Kris Nuttycombe

5 8