From ivan.miljenovic at gmail.com Wed May 3 04:56:42 2017 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Wed, 3 May 2017 14:56:42 +1000 Subject: ANNOUNCE: graphviz 2999.19.0.0 Message-ID: I've just released a new version of my Haskell bindings to the Graphviz graph visualisation toolkit. Note that the major version bump is solely because I had to remove what I thought was a useful feature (trying to allow you to do things like `"a" --> ["b", "c", "d"]` in Monadic graphs by automagically converting the "a" into ["a"]) turned out not to work in practice (as people will typically use this with literal values, but when combined with OverloadedStrings results in GHC getting confused as to what the type is). So unless you actually managed to use this functionality, then the API remains the same as 2999.18.* and you should just be able to bump your upper versions in your .cabal files (which you all do, right)? -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From andrew.thaddeus at gmail.com Thu May 11 01:43:06 2017 From: andrew.thaddeus at gmail.com (Andrew Martin) Date: Wed, 10 May 2017 21:43:06 -0400 Subject: Compact Region Short-Circuiting Message-ID: <20170511014306.GA3945@thadasaurus> In the paper on compact regions (http://ezyang.com/papers/ezyang15-cnf.pdf), we find the following: > However, if we want to apply a functional update to this tree, we may > want to specify the already existing compact region so we can reuse any > already compacted shared data... appendCompact, like newCompact, fully > evaluates a; however, it copies the result into the same compact region > as Compact b. Additionally, it short-circuits the evaluation/copying > process if a subgraph is already in the target compact region. However, in the docs for both the compact library and the ghc-compact library (still only on phabricator), this short-circuiting behavior is not mentioned. Did this end up in the final implementation on was it dropped? If it is implemented, I think it's worth mentioning in the docs for `compactAdd`. -Andrew Martin From andrew.thaddeus at gmail.com Thu May 11 12:51:16 2017 From: andrew.thaddeus at gmail.com (Andrew Martin) Date: Thu, 11 May 2017 08:51:16 -0400 Subject: Compact Region Short-Circuiting In-Reply-To: <20170511014306.GA3945@thadasaurus> References: <20170511014306.GA3945@thadasaurus> Message-ID: Nevermind. The docs for compactAdd say: > This will help you avoid copying when the value contains pointers into the compact region I had missed that. On Wed, May 10, 2017 at 9:43 PM, Andrew Martin wrote: > In the paper on compact regions (http://ezyang.com/papers/ezyang15-cnf.pdf > ), > we find the following: > > > However, if we want to apply a functional update to this tree, we may > > want to specify the already existing compact region so we can reuse any > > already compacted shared data... appendCompact, like newCompact, fully > > evaluates a; however, it copies the result into the same compact region > > as Compact b. Additionally, it short-circuits the evaluation/copying > > process if a subgraph is already in the target compact region. > > However, in the docs for both the compact library and the ghc-compact > library (still only on phabricator), this short-circuiting behavior is > not mentioned. Did this end up in the final implementation on was it > dropped? If it is implemented, I think it's worth mentioning in the > docs for `compactAdd`. > > -Andrew Martin > -- -Andrew Thaddeus Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From omeragacan at gmail.com Thu May 18 16:21:35 2017 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Thu, 18 May 2017 19:21:35 +0300 Subject: Proposal: rename Data.List.NonEmpty.sortWith to sortOn for consistency Message-ID: Proposal: Introduce `Data.List.NonEmpty.sortOn` for `Data.List.NonEmpty.sortWith` and deprecate `sortWith`. Motivation: Data.List.NonEmpty API is very similar to Data.List, except this same function is called `sortOn` in `Data.List`. I think for consistency it'd good to rename `sortWith` to `sortOn`. Why not rename `sortOn` to `sortWith`? I think `Data.List` is much more widely used than `Data.List.NonEmpty`, so renaming `sortWith` would lead to much less deprecation warnings. Ömer From yom at artyom.me Thu May 18 16:32:14 2017 From: yom at artyom.me (Artyom) Date: Thu, 18 May 2017 19:32:14 +0300 Subject: Proposal: rename Data.List.NonEmpty.sortWith to sortOn for consistency In-Reply-To: References: Message-ID: <80cec756-6e50-a788-f9d1-39632865fb1e@artyom.me> sortWith and sortOn have different implementations (specifically, they make a different tradeoff regarding performance – sortWith is faster for cheap functions, sortOn is faster for expensive functions). I'm +1 on adding sortOn, −1 on renaming sortWith to sortOn (as it would be very confusing to have a Data.List.NonEmpty.sortOn that doesn't match Data.List.sortOn), and −0.1 on removing sortWith. On 05/18/2017 07:21 PM, Ömer Sinan Ağacan wrote: > Proposal: Introduce `Data.List.NonEmpty.sortOn` for > `Data.List.NonEmpty.sortWith` and deprecate `sortWith`. > > Motivation: Data.List.NonEmpty API is very similar to Data.List, except this > same function is called `sortOn` in `Data.List`. I think for consistency it'd > good to rename `sortWith` to `sortOn`. > > Why not rename `sortOn` to `sortWith`? I think `Data.List` is much more widely > used than `Data.List.NonEmpty`, so renaming `sortWith` would lead to much less > deprecation warnings. > > Ömer > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From david.feuer at gmail.com Thu May 25 16:55:55 2017 From: david.feuer at gmail.com (David Feuer) Date: Thu, 25 May 2017 12:55:55 -0400 Subject: Map with a different Monoid instance In-Reply-To: References: Message-ID: 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mblazevic at stilo.com Thu May 25 17:38:37 2017 From: mblazevic at stilo.com (=?UTF-8?Q?Mario_Bla=c5=beevi=c4=87?=) Date: Thu, 25 May 2017 13:38:37 -0400 Subject: Map with a different Monoid instance In-Reply-To: References: Message-ID: <1cc4e9ee-3f13-01b1-3a17-669c60a34197@stilo.com> 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! Data.Map.Monoidal is not strictly correct but would give a pretty good idea at first glance. Data.Map.Symmetric would be more correct, since its Semigroup and Monoid instances would be symmetric, with no preference for the left argument as currently. > 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. I think it would be better to keep the API exactly the same, much like Data.Map.Strict does. I don't want to think about the incidental API differences when I switch from one module to another. If you're going to modernize, modernize all the modules at once. That's what version numbers are for. From ryan.trinkle at gmail.com Thu May 25 18:41:53 2017 From: ryan.trinkle at gmail.com (Ryan Trinkle) Date: Thu, 25 May 2017 14:41:53 -0400 Subject: Map with a different Monoid instance In-Reply-To: References: Message-ID: Hi David, Totally agreed. I'm not quite sure how to approach the naming issue, either - there's definitely potential for confusion, which we need to try very hard to avoid. However, the Monoid instance for Map is certainly something I've run into many times, and newtyping Map involves a pretty huge amount of boilerplate. I also agree about separating safe and unsafe functions. Especially with your new combinators in Data.Map.Merge and friends, I'd like to have a straightforward way to ensure we get rid of any unsafe functions in our code. Best, Ryan On Thu, May 25, 2017 at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Thu May 25 19:43:37 2017 From: michael at snoyman.com (Michael Snoyman) Date: Thu, 25 May 2017 13:43:37 -0600 Subject: Map with a different Monoid instance In-Reply-To: <1cc4e9ee-3f13-01b1-3a17-669c60a34197@stilo.com> References: <1cc4e9ee-3f13-01b1-3a17-669c60a34197@stilo.com> Message-ID: On Thu, May 25, 2017 at 11:38 AM, Mario Blažević wrote: > 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! >> > > Data.Map.Monoidal is not strictly correct but would give a pretty good > idea at first glance. > > Data.Map.Symmetric would be more correct, since its Semigroup and Monoid > instances would be symmetric, with no preference for the left argument as > currently. > > > Just to throw out an option here: Unbiased. I don't feel strongly about it, but thought throwing it out may be helpful. > 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. >> > > I think it would be better to keep the API exactly the same, much > like Data.Map.Strict does. I don't want to think about the incidental API > differences when I switch from one module to another. If you're going to > modernize, modernize all the modules at once. That's what version numbers > are for. > +1. I'd also argue against changing the API right now. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.trinkle at gmail.com Thu May 25 19:46:10 2017 From: ryan.trinkle at gmail.com (Ryan Trinkle) Date: Thu, 25 May 2017 15:46:10 -0400 Subject: Map with a different Monoid instance In-Reply-To: References: <1cc4e9ee-3f13-01b1-3a17-669c60a34197@stilo.com> Message-ID: Unbiased sounds good to me. That's a good point, Mario. I'm in favor of the modernization, but I don't have a strong preference that it happen along with this other change. On Thu, May 25, 2017 at 3:43 PM, Michael Snoyman wrote: > > > On Thu, May 25, 2017 at 11:38 AM, Mario Blažević > wrote: > >> 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! >>> >> >> Data.Map.Monoidal is not strictly correct but would give a pretty good >> idea at first glance. >> >> Data.Map.Symmetric would be more correct, since its Semigroup and Monoid >> instances would be symmetric, with no preference for the left argument as >> currently. >> >> >> > Just to throw out an option here: Unbiased. I don't feel strongly about > it, but thought throwing it out may be helpful. > > >> 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. >>> >> >> I think it would be better to keep the API exactly the same, much >> like Data.Map.Strict does. I don't want to think about the incidental API >> differences when I switch from one module to another. If you're going to >> modernize, modernize all the modules at once. That's what version numbers >> are for. >> > > +1. I'd also argue against changing the API right now. > > Michael > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Thu May 25 20:08:09 2017 From: david.feuer at gmail.com (David Feuer) Date: Thu, 25 May 2017 16:08:09 -0400 Subject: Map with a different Monoid instance In-Reply-To: References: <1cc4e9ee-3f13-01b1-3a17-669c60a34197@stilo.com> Message-ID: Unbiased sounds nice, but I'm a bit concerned that it might suggest bigger differences than just the Monoid instance. I assume people still want the same left-biased union function. On Thu, May 25, 2017 at 3:43 PM, Michael Snoyman wrote: > > > On Thu, May 25, 2017 at 11:38 AM, Mario Blažević > wrote: >> >> 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! >> >> >> Data.Map.Monoidal is not strictly correct but would give a pretty good >> idea at first glance. >> >> Data.Map.Symmetric would be more correct, since its Semigroup and Monoid >> instances would be symmetric, with no preference for the left argument as >> currently. >> >> > > Just to throw out an option here: Unbiased. I don't feel strongly about it, > but thought throwing it out may be helpful. > >>> >>> 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. >> >> >> I think it would be better to keep the API exactly the same, much >> like Data.Map.Strict does. I don't want to think about the incidental API >> differences when I switch from one module to another. If you're going to >> modernize, modernize all the modules at once. That's what version numbers >> are for. > > > +1. I'd also argue against changing the API right now. > > Michael > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > From michael at snoyman.com Thu May 25 20:37:38 2017 From: michael at snoyman.com (Michael Snoyman) Date: Thu, 25 May 2017 14:37:38 -0600 Subject: Map with a different Monoid instance In-Reply-To: References: <1cc4e9ee-3f13-01b1-3a17-669c60a34197@stilo.com> Message-ID: That's a really good question, and could theoretically even generalize more than that: should `insert` have a `Monoid` or `Semigroup` constraint on the key as well? Should this API explicitly avoid any form of throwing away values, and insist that, if that's the behavior you want, you do something like `insertWith const`? I think my guess is in line with yours, that the rest of the API functions should continue with the discard behavior of the current API, but it's worth at least raising the question. On Thu, May 25, 2017 at 2:08 PM, David Feuer wrote: > Unbiased sounds nice, but I'm a bit concerned that it might suggest > bigger differences than just the Monoid instance. I assume people > still want the same left-biased union function. > > On Thu, May 25, 2017 at 3:43 PM, Michael Snoyman > wrote: > > > > > > On Thu, May 25, 2017 at 11:38 AM, Mario Blažević > > wrote: > >> > >> 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! > >> > >> > >> Data.Map.Monoidal is not strictly correct but would give a pretty good > >> idea at first glance. > >> > >> Data.Map.Symmetric would be more correct, since its Semigroup and Monoid > >> instances would be symmetric, with no preference for the left argument > as > >> currently. > >> > >> > > > > Just to throw out an option here: Unbiased. I don't feel strongly about > it, > > but thought throwing it out may be helpful. > > > >>> > >>> 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. > >> > >> > >> I think it would be better to keep the API exactly the same, > much > >> like Data.Map.Strict does. I don't want to think about the incidental > API > >> differences when I switch from one module to another. If you're going to > >> modernize, modernize all the modules at once. That's what version > numbers > >> are for. > > > > > > +1. I'd also argue against changing the API right now. > > > > Michael > > > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.trinkle at gmail.com Thu May 25 21:01:15 2017 From: ryan.trinkle at gmail.com (Ryan Trinkle) Date: Thu, 25 May 2017 17:01:15 -0400 Subject: Map with a different Monoid instance In-Reply-To: References: <1cc4e9ee-3f13-01b1-3a17-669c60a34197@stilo.com> Message-ID: I tend to avoid Map.union and the other biased combining functions, simply because they seem a bit too easy for someone to accidentally come along later and exchange the order by accident. On the other hand, having Map.insert use a Monoid instance seems like it would be quite unwieldy. On Thu, May 25, 2017 at 4:37 PM, Michael Snoyman wrote: > That's a really good question, and could theoretically even generalize > more than that: should `insert` have a `Monoid` or `Semigroup` constraint > on the key as well? Should this API explicitly avoid any form of throwing > away values, and insist that, if that's the behavior you want, you do > something like `insertWith const`? > > I think my guess is in line with yours, that the rest of the API functions > should continue with the discard behavior of the current API, but it's > worth at least raising the question. > > On Thu, May 25, 2017 at 2:08 PM, David Feuer > wrote: > >> Unbiased sounds nice, but I'm a bit concerned that it might suggest >> bigger differences than just the Monoid instance. I assume people >> still want the same left-biased union function. >> >> On Thu, May 25, 2017 at 3:43 PM, Michael Snoyman >> wrote: >> > >> > >> > On Thu, May 25, 2017 at 11:38 AM, Mario Blažević >> > wrote: >> >> >> >> 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! >> >> >> >> >> >> Data.Map.Monoidal is not strictly correct but would give a pretty good >> >> idea at first glance. >> >> >> >> Data.Map.Symmetric would be more correct, since its Semigroup and >> Monoid >> >> instances would be symmetric, with no preference for the left argument >> as >> >> currently. >> >> >> >> >> > >> > Just to throw out an option here: Unbiased. I don't feel strongly about >> it, >> > but thought throwing it out may be helpful. >> > >> >>> >> >>> 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. >> >> >> >> >> >> I think it would be better to keep the API exactly the same, >> much >> >> like Data.Map.Strict does. I don't want to think about the incidental >> API >> >> differences when I switch from one module to another. If you're going >> to >> >> modernize, modernize all the modules at once. That's what version >> numbers >> >> are for. >> > >> > >> > +1. I'd also argue against changing the API right now. >> > >> > Michael >> > >> > _______________________________________________ >> > Libraries mailing list >> > Libraries at haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > >> > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Thu May 25 21:57:44 2017 From: david.feuer at gmail.com (David Feuer) Date: Thu, 25 May 2017 17:57:44 -0400 Subject: Map with a different Monoid instance In-Reply-To: References: <1cc4e9ee-3f13-01b1-3a17-669c60a34197@stilo.com> Message-ID: I think we definitely don't want a Semigroup constraint on the key. Aside from the (potentially severe) performance issues, I think the semantics would be pretty awful. Inserting a key-value pair could potentially collapse a large map into a singleton! On Thu, May 25, 2017 at 4:37 PM, Michael Snoyman wrote: > That's a really good question, and could theoretically even generalize more > than that: should `insert` have a `Monoid` or `Semigroup` constraint on the > key as well? Should this API explicitly avoid any form of throwing away > values, and insist that, if that's the behavior you want, you do something > like `insertWith const`? > > I think my guess is in line with yours, that the rest of the API functions > should continue with the discard behavior of the current API, but it's worth > at least raising the question. > > On Thu, May 25, 2017 at 2:08 PM, David Feuer wrote: >> >> Unbiased sounds nice, but I'm a bit concerned that it might suggest >> bigger differences than just the Monoid instance. I assume people >> still want the same left-biased union function. >> >> On Thu, May 25, 2017 at 3:43 PM, Michael Snoyman >> wrote: >> > >> > >> > On Thu, May 25, 2017 at 11:38 AM, Mario Blažević >> > wrote: >> >> >> >> 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! >> >> >> >> >> >> Data.Map.Monoidal is not strictly correct but would give a pretty good >> >> idea at first glance. >> >> >> >> Data.Map.Symmetric would be more correct, since its Semigroup and >> >> Monoid >> >> instances would be symmetric, with no preference for the left argument >> >> as >> >> currently. >> >> >> >> >> > >> > Just to throw out an option here: Unbiased. I don't feel strongly about >> > it, >> > but thought throwing it out may be helpful. >> > >> >>> >> >>> 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. >> >> >> >> >> >> I think it would be better to keep the API exactly the same, >> >> much >> >> like Data.Map.Strict does. I don't want to think about the incidental >> >> API >> >> differences when I switch from one module to another. If you're going >> >> to >> >> modernize, modernize all the modules at once. That's what version >> >> numbers >> >> are for. >> > >> > >> > +1. I'd also argue against changing the API right now. >> > >> > Michael >> > >> > _______________________________________________ >> > Libraries mailing list >> > Libraries at haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > > > From lemming at henning-thielemann.de Thu May 25 22:00:15 2017 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 26 May 2017 00:00:15 +0200 (CEST) Subject: Map with a different Monoid instance In-Reply-To: References: Message-ID: On Thu, 25 May 2017, 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. There are a lot notions of "unsafe", some mean "partial" others mean "breaks abstraction" others mean "can do IO although type signature promises not to do so". I think we should stick to the notion of "safe" as in "unsafePerformIO" and "SafeHaskell". In this respect all functions in Data.Map are safe, aren't they? Functions that may break abstraction can be exported by "Internal" modules - which already exist. From mblazevic at stilo.com Thu May 25 22:10:52 2017 From: mblazevic at stilo.com (=?UTF-8?Q?Mario_Bla=c5=beevi=c4=87?=) Date: Thu, 25 May 2017 18:10:52 -0400 Subject: Map with a different Monoid instance In-Reply-To: References: <1cc4e9ee-3f13-01b1-3a17-669c60a34197@stilo.com> Message-ID: <0446c761-9a20-6ca9-1369-5141150f4cd4@stilo.com> On 2017-05-25 04:08 PM, David Feuer wrote: > Unbiased sounds nice, but I'm a bit concerned that it might suggest > bigger differences than just the Monoid instance. I assume people > still want the same left-biased union function. I agree. Quite apart from the compatibility issues, I'd rather use mappend or (<>) once the instances are fixed than any union function, biased or not. > > On Thu, May 25, 2017 at 3:43 PM, Michael Snoyman wrote: >> >> >> On Thu, May 25, 2017 at 11:38 AM, Mario Blažević >> wrote: >>> >>> 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! >>> >>> >>> Data.Map.Monoidal is not strictly correct but would give a pretty good >>> idea at first glance. >>> >>> Data.Map.Symmetric would be more correct, since its Semigroup and Monoid >>> instances would be symmetric, with no preference for the left argument as >>> currently. >>> >>> >> >> Just to throw out an option here: Unbiased. I don't feel strongly about it, >> but thought throwing it out may be helpful. >> >>>> >>>> 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. >>> >>> >>> I think it would be better to keep the API exactly the same, much >>> like Data.Map.Strict does. I don't want to think about the incidental API >>> differences when I switch from one module to another. If you're going to >>> modernize, modernize all the modules at once. That's what version numbers >>> are for. >> >> >> +1. I'd also argue against changing the API right now. >> >> Michael >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> -- Mario Blazevic mblazevic at stilo.com Stilo International This message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure, copying, or distribution is strictly prohibited. If you are not the intended recipient(s) please contact the sender by reply email and destroy all copies of the original message and any attachments. From ryan.trinkle at gmail.com Thu May 25 22:31:12 2017 From: ryan.trinkle at gmail.com (Ryan Trinkle) Date: Thu, 25 May 2017 18:31:12 -0400 Subject: Map with a different Monoid instance In-Reply-To: <0446c761-9a20-6ca9-1369-5141150f4cd4@stilo.com> References: <1cc4e9ee-3f13-01b1-3a17-669c60a34197@stilo.com> <0446c761-9a20-6ca9-1369-5141150f4cd4@stilo.com> Message-ID: There's also some nice interplay here with 'coerce', namely that by coercing NewMap k v to Map k (Data.Semigroup.First v), we can recover the original behavior. On Thu, May 25, 2017 at 6:10 PM, Mario Blažević wrote: > On 2017-05-25 04:08 PM, David Feuer wrote: > >> Unbiased sounds nice, but I'm a bit concerned that it might suggest >> bigger differences than just the Monoid instance. I assume people >> still want the same left-biased union function. >> > > I agree. Quite apart from the compatibility issues, I'd rather use > mappend or (<>) once the instances are fixed than any union function, > biased or not. > > > > >> On Thu, May 25, 2017 at 3:43 PM, Michael Snoyman >> wrote: >> >>> >>> >>> On Thu, May 25, 2017 at 11:38 AM, Mario Blažević >>> wrote: >>> >>>> >>>> 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! >>>>> >>>> >>>> >>>> Data.Map.Monoidal is not strictly correct but would give a pretty good >>>> idea at first glance. >>>> >>>> Data.Map.Symmetric would be more correct, since its Semigroup and Monoid >>>> instances would be symmetric, with no preference for the left argument >>>> as >>>> currently. >>>> >>>> >>>> >>> Just to throw out an option here: Unbiased. I don't feel strongly about >>> it, >>> but thought throwing it out may be helpful. >>> >>> >>>>> 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. >>>>> >>>> >>>> >>>> I think it would be better to keep the API exactly the same, >>>> much >>>> like Data.Map.Strict does. I don't want to think about the incidental >>>> API >>>> differences when I switch from one module to another. If you're going to >>>> modernize, modernize all the modules at once. That's what version >>>> numbers >>>> are for. >>>> >>> >>> >>> +1. I'd also argue against changing the API right now. >>> >>> Michael >>> >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >>> > > -- > Mario Blazevic > mblazevic at stilo.com > Stilo International > > This message, including any attachments, is for the sole use of the > intended recipient(s) and may contain confidential and privileged > information. Any unauthorized review, use, disclosure, copying, or > distribution is strictly prohibited. If you are not the intended > recipient(s) please contact the sender by reply email and destroy > all copies of the original message and any attachments. > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Thu May 25 23:22:19 2017 From: david.feuer at gmail.com (David Feuer) Date: Thu, 25 May 2017 19:22:19 -0400 Subject: Map with a different Monoid instance In-Reply-To: References: Message-ID: Yes, all of these should be safe from a SafeHaskell perspective (if they're not, that's a bug!). I would like to remove abstraction-breaking functions from the primary modules (or at least refrain from introducing them into new map-with-different-monoid modules), and put them in .Unsafe modules. While I think users should generally avoid using partial functions, they don't have nearly as much potential to confuse the heck out of someone downstream from them as, say, a Map whose keys are duplicated or out of order. Internal modules serve a different purpose: their APIs are intentionally allowed to be completely unstable, but people willing to put up with that can implement "low-level" operations the library does not itself support as efficiently. A .Unsafe module would be subject to the PVP and follow a conservative deprecation policy; a .Internal module would not. On Thu, May 25, 2017 at 6:00 PM, Henning Thielemann wrote: > > On Thu, 25 May 2017, 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. > > > There are a lot notions of "unsafe", some mean "partial" others mean "breaks > abstraction" others mean "can do IO although type signature promises not to > do so". I think we should stick to the notion of "safe" as in > "unsafePerformIO" and "SafeHaskell". In this respect all functions in > Data.Map are safe, aren't they? Functions that may break abstraction can be > exported by "Internal" modules - which already exist.