May 2017 - Libraries - Haskell.org

Map with a different Monoid instance
by David Feuer 25 May '17

25 May '17

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.

5 11

Re: Map with a different Monoid instance
by Ryan Trinkle 25 May '17

25 May '17

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 <david.feuer(a)gmail.com> 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. >

1 0

Proposal: rename Data.List.NonEmpty.sortWith to sortOn for consistency
by Ömer Sinan Ağacan 18 May '17

18 May '17

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

2 1

Compact Region Short-Circuiting
by Andrew Martin 11 May '17

11 May '17

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

1 1

ANNOUNCE: graphviz 2999.19.0.0
by Ivan Lazar Miljenovic 03 May '17

03 May '17

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(a)gmail.com http://IvanMiljenovic.wordpress.com

1 0