- Libraries - Haskell.org

Re: Proposal: add integer division to GHC.TypeLits
by Ryan Scott 08 Jun '17

08 Jun '17

To be clear, I don't think Alexey is proposing that we implement inductive definitions of Div/Mod/DivMod to base (which, as you note, would require implementing type-level Fst and Snd as well). One of the motivations for this proposal is that we _did_ implement and inductive DivMod in the singletons library [1], and it is horribly slow. What I believe Alexey wants is a built-in type family that leverages machine instructions to perform the div/mod calculations behind the hood, much like we currently do for other type-level arithmetic operators, such as (+), (-), and (*). > Yet, how about the rest of families in `Data.Constraint.Nat` Obviously, adding more built-in type families is perhaps not an ideal solution, and there are certainly many more things we _could_ add. But I think integer division is a common-enough use case that it makes sense to support it in base. We need not bog down this proposal with whataboutism. > Note: If we add them, let's only add them to GHC.TypeNats. Agreed. > Note: current type families form decidable system, which > `ghc-typelits-natnormalize` can solve. Adding division complicates > that story. Sure, but then again, there are many type families that you could throw into this system that this particular GHC plugin couldn't reason about. I don't see how Div/Mod are unique in that regard. > What would be the semantics, especially what > > Div n 0 > > would reduce to: `TypeError` or be irreducible i.e. be stuck? I would propose that it would be stuck. There is precedent for this already: (2 - 3) is a stuck type, for instance. This is also the approach that the ghc-typelits-extra plugin takes. Ryan S. ----- [1] https://github.com/goldfirere/singletons/blob/75dae57bbe06b21b3adbb82158c47… [2] http://hackage.haskell.org/package/ghc-typelits-extra

1 0

Proposal: add integer division to GHC.TypeLits
by Alexey Vagarenko 07 Jun '17

07 Jun '17

I'd like to propose adding Div, Mod and DivMod type families to GHC.TypeLits, which would be promoted versions of methods of Integral class. type family Div :: Nat -> Nat -> Nat type family Mod :: Nat -> Nat -> Nat type family DivMod :: Nat -> Nat -> (Nat, Nat) I've made trac ticket for this https://ghc.haskell.org/trac/ghc/ticket/13652 some time ago, but it hasn't got much attention.

3 2

Re: Proposal: add integer division to GHC.TypeLits
by Ryan Scott 07 Jun '17

07 Jun '17

+1 from me as well. Ryan S.

1 0

Deprecate KProxy
by Vladislav Zavialov 02 Jun '17

02 Jun '17

Now that we have -XTypeInType, there's no need for KProxy anymore. The deprecation warning can advise to use regular Proxy instead.

3 2

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

Re: Civility notes (was "Traversable instances for (,,) a b")
by Theodore Lief Gannon 30 Apr '17

30 Apr '17

I'm also -1 to an explicit code of conduct. Sure, once in a while someone has to step in with Wheaton's Law or what I can't resist calling Simon Says; but all it takes is a gentle reminder. Nobody here is genuinely contemptuous toward anyone else. The barrier of entry is too high -- the trolls are happy enough on reddit. ;) On Apr 6, 2017 6:17 AM, "Andreas Abel" <andreas.abel(a)ifi.lmu.de> wrote: On 03.04.2017 10:42, Henning Thielemann wrote: > On Mon, 3 Apr 2017, Simon Peyton Jones via Libraries wrote: > > I’ve been talking to a couple of people about whether it would be >> useful to have an explicit Haskell Community Code of Conduct. Many >> online communities have one (e.g. Rust), and it might be helpful for >> everyone to have a concrete baseline rather than an unwritten >> standard. Any views on that? >> > > I think these Code of Conducts make things even worse because then some > people start to check every word against these codes. Instead I suggest > we make more use of humor. E.g. Carter Schonwald's comment about grumpy > people made me think about renaming my prelude-compat package to > grumpy-prelude. :-) > I agree with Henning. The discussion gets heated because people are passionate about Haskell; and the latter is a good thing. I rather stomach some insults on a mailing list than having a formal code of conduct. Severe violations of politeness can be pointed out without having such a formal code. We can apply common sense. -- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel(a)gu.se http://www.cse.chalmers.se/~abela/ _______________________________________________ Libraries mailing list Libraries(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

6 6