- Libraries - Haskell.org

Re: Compact Normal Form and ST
by David Feuer 19 Jun '17

19 Jun '17

Can you explain how things could go wrong in ST, perhaps with an example? It's hard to see the potential problem. On Jun 18, 2017 11:49 PM, "Edward Z. Yang" <ezyang(a)mit.edu> wrote: There are two senses of referential transparency here which should be considered. First is whether or not you will get the same value results if you use the compact functionality in ST. Here, the answer is yes. Compact normal form has very trivial semantics in this domain, and it would have been OK even to make compact normal forms be pure functions. Second is whether or not the performance characteristics are preserved. Here, the situation is different. Most notably, pure expressions and invocations of the same runST block may be commoned up (via an optimization pass like CSE.) In that case, what was previously two separate compact blocks may be commoned up into a single one. This could be disaster if you were planning to use these blocks as separate allocation buffers for subsequent modifications. This motivated specializing compact to IO. It won't segfault if you put it in ST, but the performance characteristics might change. Edward Excerpts from Andrew Martin's message of 2017-06-18 10:24:09 -0400: > In the primops file where the compact normal form functions are > documented (https://github.com/ghc/ghc/blob/adcd1c62b6d372f100ccf1d5d7cd94 f79aaac194/compiler/prelude/primops.txt.pp#L2487), > I noticed that all of the functions have type signatures that constrain > them to only being used in IO. For example: > > compactAdd# :: Compact# -> a -> State# RealWorld -> (# State# RealWorld, a #) > > I would like to know if generalizing these to allow them to work in ST would > be sound. That is, changing the type signature to: > > compactAdd# :: Compact# -> a -> State# s -> (# State# s, a #) > > I'm not requesting that this change actually be made. I only want to > know if using unsafeCoerce to create the second function for my own > project would actually be sound. > > For those interested in knowing why I want this, it's because there are > situation where I'm interested in building up a giant structure in a > compact region, but in a way that doesn't actually require IO. I think > it's a pity to have to use a type signature with IO and then call > unsafePerformIO at the end instead of using the more constrained ST, > and runST, which makes it clear that I'm not doing anything observable > form the outside. > > As a minor bonus, the ST version of the Compact data type shouldn't need > the lock that the IO version does, since concurrent calls to compactAdd > are not possible. > > -Andrew Martin > _______________________________________________ Libraries mailing list Libraries(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

3 2

Compact Normal Form and ST
by Andrew Martin 19 Jun '17

19 Jun '17

In the primops file where the compact normal form functions are documented (https://github.com/ghc/ghc/blob/adcd1c62b6d372f100ccf1d5d7cd94f79aaac194/co…) I noticed that all of the functions have type signatures that constrain them to only being used in IO. For example: compactAdd# :: Compact# -> a -> State# RealWorld -> (# State# RealWorld, a #) I would like to know if generalizing these to allow them to work in ST would be sound. That is, changing the type signature to: compactAdd# :: Compact# -> a -> State# s -> (# State# s, a #) I'm not requesting that this change actually be made. I only want to know if using unsafeCoerce to create the second function for my own project would actually be sound. For those interested in knowing why I want this, it's because there are situation where I'm interested in building up a giant structure in a compact region, but in a way that doesn't actually require IO. I think it's a pity to have to use a type signature with IO and then call unsafePerformIO at the end instead of using the more constrained ST, and runST, which makes it clear that I'm not doing anything observable form the outside. As a minor bonus, the ST version of the Compact data type shouldn't need the lock that the IO version does, since concurrent calls to compactAdd are not possible. -Andrew Martin

2 1

Add DList to base
by Dr.Koster 14 Jun '17

14 Jun '17

Currently GHC already defined DList for internal use in serveral places. This data type is a nature choice when you need CPS your append, which is a common need. I think base should provide it. Cheers~ Winter

5 10

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