March 2014 - Libraries

vector: ‘ANN type’ without GHCi
by Nikita Karetnikov 01 Apr '14

01 Apr '14

The latest Hackage version and HEAD fail to build on mips64el due to the ANN pragma in ‘Data/Vector/Fusion/Stream/Monadic.hs’: [ 5 of 21] Compiling Data.Vector.Fusion.Stream.Monadic ( Data/Vector/Fusion/Stream/Monadic.hs, dist/build/Data/Vector/Fusion/Stream/Monadic.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for mipsel-unknown-linux): Cant do annotations without GHCi {Data/Vector/Fusion/Stream/Monadic.hs:104:19-33} base:GHC.Exts.ForceSpecConstr{d r2i8} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Here’s the relevant part of the code: data SPEC = SPEC | SPEC2 #if __GLASGOW_HASKELL__ >= 700 {-# ANN type SPEC ForceSpecConstr #-} #endif Is it possible to use CPP along with some configure flag to determine if GHCi is available, and if it is not, skip the said pragma? I tested the Hackage version, and it builds fine if I comment out the mentioned lines. Does the lack of the pragma make a big difference? (The relevant section of the GHC manual is very brief.)

5 4

riak-haskell-client maintainers
by Mark Hibberd 30 Mar '14

30 Mar '14

All, Hi. I rely heavily on the riak-haskell-client library (http://hackage.haskell.org/package/riak) and at the moment it is unmaintained for all intents and purposes. Evidenced by: - I have patches outstanding (as do others), that have not been responded to for 8 months (https://github.com/janrain/riak-haskell-client/pull/19) - It doesn't support most of the riak APIs due to only being built against a very old version of the API (#19 addresses this partially). - And there was a comment last week indicating that janrain were no longer supporting it (https://github.com/janrain/riak-haskell-client/pull/10) Carter suggested I send a message to this list to see if there is anyone who is able to help, either as a maintainer, or by allowing me to be added as a maintainer so I can start getting things updated. I have requested the same via the maintainers email and a github issue (https://github.com/janrain/riak-haskell-client/issues/25) about a week ago, but have not received any response yet. Cheers Mark

2 1

Burning more bridges (mostly numeric ones)
by Carter Charbonneau 26 Mar '14

26 Mar '14

The Burning Bridges thread got lots done, but seemed to miss a few things, and didn't even touch on the Numeric classes. The Numeric classes should be fixed at some point, and sooner is better than later. However, it would be a large change and would go nicely with a major version bump in base. 5 is coming up soon. Proposals, ordered from relatively controversial to insanely so (at least IMO): 1. Replace (.) and id from versions from Control.Category in Prelude This is a small change, and has close to the same effect as the Foldable/ Traversable change. The key difference is that this is a much smaller change and there is little current use for the versions from Control.Category However, historically they have seen use with the other lens-ish libraries, and AFAICT are the reason the lenses in `lens` are "backwards", or at least called so my some. 1.2 Use Semigroupoid for (.) and Ob for id instead. Personally, I really like this idea, but I think it would be much more controversial. 2. Move Semigroup into Prelude 2.1 Make Monoid depend on Semigroup. 3. Do something with the Numeric classes. This isn't so much of a proposal as a request for discussion from people more experienced than me, but I still think a general idea if people think that doing *anything* is a good idea would be useful. 3.1 Split each numeric operation into it's own class. Say no to 3.2 and yes here for no hierarchy in them/ConstraintKinds/empty classes. Pros: EDSLs, convenience. Cons: Would be major breakage, would need ConstraintKinds/empty classes to have a hierarchy. 3.2 Hierarchy. the classes are TBD, this is here for a straw poll.

13 24

PROPOSAL(S): threadWaitError and threadWaitErrorSTM
by Merijn Verstraaten 21 Mar '14

21 Mar '14

Hola! Control.Concurrent currently has: threadWaitRead :: Fd -> IO () threadWaitWrite :: Fd -> IO () threadWaitReadSTM :: Fd -> IO (STM (), IO ()) threadWaitWriteSTM :: Fd -> IO (STM (), IO ()) (btw, whoever added the STM versions, I <3 you) I would like to propose adding: threadWaitError :: Fd -> IO () threadWaitErrorSTM :: Fd -> IO (STM (), IO ()) to allow for blocking on detecting error condition on file descriptors, similar to what C's select() allows. Cheers, Merijn

3 5

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