- Libraries - Haskell.org

PVP proposal: don't require major version bump when adding non-orphan instances
by Johan Tibell 18 Mar '14

18 Mar '14

Hi all, (This email is about trying to improve the PVP. If you think the PVP is a bad idea to begin with, please discuss that in a separate email thread.) The PVP [1] states that A.B is known as the major version number, and C the minor version number. > When a package is updated, the following rules govern how the version > number must change relative to the previous version: > > - If any entity was removed, or the types of any entities or the > definitions of datatypes or classes were changed, or instances were added > or removed, then the new A.B must be greater than the previous A.B. Note > that modifying imports or depending on a newer version of another package > may cause extra instances to be exported and thus force a major version > change. > > > - Otherwise, if only new bindings, types, classes or modules (but see > below) were added to the interface, then A.B may remain the same but the > new C must be greater than the old C. > > > - Otherwise, A.B.C may remain the same (other version components may > change). > > Bumping the major version number often introduce a number of downstream changes, as package author need to loosen dependency constraints to allow the new package version to be used. This creates quite a bit of work for maintainers. A particular onerous requirement is to have to bump the major version whenever you add a new instance. In spirit adding a new instances feels like adding a new function, like making an extension to the API, something ought to not break clients who use qualified imports and/or explicit import lists. For this reason and because of the cost to downstream maintainers, I've sometimes avoided bumping the major version in the past when adding a new instance. However, introducing a new instance can only break other packages if those packages define orphan instance. Here's my reasoning: 1. Assume there are no orphan instances. 2. Package D defines a data type and package C defines a type class (it's possible that D=C.) 3. An instance can only be added by either D or C. 4. D and C cannot both depend on each other, so both cannot add the same instance. 5. Another package O cannot add an instance (remember that orphans are disallowed). 6. Since O cannot define an instance, there cannot be any conflicts in O if D or C (whichever depends on the other) adds an instance. If this is true, we could change the first two PVP rules to (differences in *italics*): - If any entity was removed, or the types of any entities or the definitions of datatypes or classes were changed, or *orphan* instances were added or *any instances were* removed, then the new A.B must be greater than the previous A.B. Note that modifying imports or depending on a newer version of another package may cause extra instances to be exported and thus force a major version change. - Otherwise, if only new bindings, types, classes, *non-orphan instances*, or modules (but see below) were added to the interface, then A.B may remain the same but the new C must be greater than the old C. and add the following clarifying sentence: *If a package defines an orphan instance, it must depend on the minor version of the packages that define the data type and the type class to be backwards compatible. For example, build-depends: mypkg >= 2.1.1 && < 2.1.2.* I believe this would result in less work for maintainers. 1. http://www.haskell.org/haskellwiki/Package_versioning_policy Discussion period: 3 weeks. -- Johan

13 18

Re: breath of life for dataenc lib
by Carter Schonwald 16 Mar '14

16 Mar '14

ccing Libraries (forgot) On Sat, Mar 15, 2014 at 1:36 PM, Carter Schonwald < carter.schonwald(a)gmail.com> wrote: > Hey All, > Dataenc is needed for building darcs, and currently doesn't build on 7.8 > without some easy patching (i'm also trying to mod the tesing code to use > the cabal test suite support but that doesn't seem to work). I couldn't > find a repo online so i started one here > https://github.com/cartazio/dataenc > > @magnus, Are you still game for continuing to maintain it? (the hackage > docs indicate that you have uploader acls but also that theres no > maintainer per se and theres no repo online) > > thoughts? > > thanks > -Carter >

3 3

Avoid passing unnecessary dictionaries in Data.Complex
by Edward Kmett 15 Mar '14

15 Mar '14

We removed the data type context from Data.Complex some time ago. However, when we did so, we left the rest of the API in that module intact. Many of the accessors in that module (should) work with much more general types now! e.g. realPart :: Complex a -> a instead of realPart :: RealFloat a => Complex a -> a I propose we stop passing around dictionaries we don't need to methods that don't use them. Concretely, I'm proposing we simplify the signatures of the following functions, which in the current API all unnecessarily take a RealFloatconstraint that they don't use. realPart :: Complex a -> a imagPart :: Complex a -> a conjugate :: Num a => Complex a -> Complex a mkPolar :: Floating a => a -> a -> Complex a cis :: Floating a => a -> Complex a Discussion Period: 2 weeks -Edward Kmett

5 4

adoption or NMU for arithmoi
by Daniel Bergey 13 Mar '14

13 Mar '14

The arithmoi package[1] does not build on GHC 7.8.1, and the maintainer does not appear to be reachable. diagram-contrib[2] depends on arithmoi, which is why I and others have been working on this. Brent reported the build failure on 2013-12-23[3]. Carter Schonwald and I wrote a patch[4] mid-February. After Austin Seipp provided ghc-prim-compat[5], I wrote an new patch[6] using that module. Daniel Fischer, the author of arithmoi, has not replied to either pull request, nor to an email I sent him a week ago today. Unless someone knows other channels by which to reach Daniel Fischer, I'd like to request that someone upload my patched version of arithmoi to Hackage. I'm not sure how this process usually works; are there other steps I should take? Thank you, Daniel Footnotes: [1] http://hackage.haskell.org/package/arithmoi [2] http://hackage.haskell.org/package/diagrams-contrib [3] https://bitbucket.org/dafis/arithmoi/issue/4/equality-primop-type-error-und… [4] https://bitbucket.org/carter/arithmoi/ [5] https://github.com/thoughtpolice/ghc-prim-compat [6] https://bitbucket.org/bergey/arithmoi/

3 3

[containers] Proposal: Add traverseKeys, traverseKeysWith, traverseKeysMonotonic to Data.Map
by Niklas Haas 11 Mar '14

11 Mar '14

Hello all, While programming a specific type of map update I came across a great need for a 'traverseKeys' function. I ended up making it myself but it was still less efficient than it needed to be because my traversal function was actually monotonic. I went ahead and added this along with some variants to Data.Map. > traverseKeys :: (Applicative f, Ord k2) => (k1 -> f k2) -> Map k1 a -> f (Map k2 a) > traverseKeysWith :: (Applicative f, Ord k2) => (a -> a -> a) -> (k1 -> f k2) -> Map k1 a -> f (Map k2 a) > traverseKeysMonotonic :: (Applicative f, Ord k2) => (k1 -> f k2) -> Map k1 a -> f (Map k2 a) A full patch can be found here: https://github.com/nandykins/containers/commit/a8b0ebd57653bc0a309af69d7323… Let me know what you think, Discussion period: 2 weeks

4 5

Data.Dynamic: Any vs existential
by Roman Cheplyaka 10 Mar '14

10 Mar '14

In Data.Dynamic, Dynamic is defined as data Dynamic = Dynamic TypeRep Any Does this have any advantage over a safer data Dynamic = forall a. Typeable a => Dynamic a ? Roman

6 13

Alex and GHC 7.8
by wren ng thornton 08 Mar '14

08 Mar '14

Hello, In testing my packages for the impending GHC 7.8 release, I ran into some issues with Alex-generated code. In particular, it looks like the (>=#) and (==#) operators now return Int# instead of Bool, so expressions like if (offset >=# 0#) && (check ==# ord_c) then ... no longer type check. Is this a known issue? Are there any plans to fix it? I'd offer to submit a pull-request, but I'm not familiar with the Alex codebase so that'd take a while -- Live well, ~wren

4 5

Proposal: Explicitly require "Data.Bits.bit (-1) == 0" property
by Herbert Valerio Riedel 08 Mar '14

08 Mar '14

Hello *, Right now, there seems to be no "defined" way to create a zero 'Bits'-value (w/o requiring also a 'Num' instance), that has all bits cleared without involving at least two operations from the 'Bits' class (e.g. `clearBit (bit 0) 0` or `let x = bit 0 in xor x x`). OTOH, introducing a new method 'class Bits a where bitZero :: a' seems overkill to me. However, "bit (-1)"[1] seems to result in just such a zero-value for all 'Bits' instances from base, so I'd hereby propose to simply document this as an expected property of 'bit', as well as the recommended way to introduce a zero-value (for when 'Num' is not available). Discussion period: 2 weeks [1]: ...or more generally 'bit n == 0' for n<0, as it's usually implemented as 'bit n = 1 shift n'

36 147

ANN: time-1.4.2
by Ashley Yakeley 03 Mar '14

03 Mar '14

time-1.4.2 is now available from Hackage. <http://hackage.haskell.org/package/time> This update is one contributed improvement, Safe Haskell annotation, from Omari Norman. Thanks! -- Ashley Yakeley

1 0

[PATCH 0/3] Implement nand/nor/nany/nall in Data.List
by Alexander Berntsen 27 Feb '14

27 Feb '14

Hi. I'm a complete GHC newbie (and, really, a Haskell newbie still as well). To dive in and learn, I hacked together this. I did it primarily to familiarise myself with GHC workflow, formalities and procedures. Things like style conventions, using Trac, learning how to build GHC, how the files are structured and so on. However, my primary intention of learning does not mean that I don't find these patches valuable. I'm sick of typing (not . and), and even more sick of reading it. I find nand much more intuitive to read. Herbert told me to send these here since they affect base. I can imagine people are vary of putting stuff in base, and certainly prelude. But if I seem ignorant and ahistorical, that's because I *am*. So please, if there is something wrong with my patches, don't hesitate to educate me. Learning the ways of GHC hacking is after all my long-term goal. :-) Alexander Berntsen (3): Implement nand, nor, nany and nall in Data.List Inline nand, nor, nany and nall Put nand, nor, nany and nall in Prelude Data/List.hs | 4 ++++ GHC/List.lhs | 38 ++++++++++++++++++++++++++++++++++++-- Prelude.hs | 2 +- changelog.md | 3 +++ 4 files changed, 44 insertions(+), 3 deletions(-) -- 1.8.3.2

10 15