September 2013 - Libraries

Missing Traversable instances
by hsyl20 . 29 Sep '13

29 Sep '13

Hi, I would like to use a Traversable instance for "Either e". I have read it is a recurrent demand [1][2] to integrate it in base. Could we do it for the next release? Thanks Sylvain [1] http://haskell.1045720.n5.nabble.com/Proposal-Add-the-missing-instances-for… [2] http://osdir.com/ml/libraries@haskell.org/2011-01/msg00325.html

3 3

cabal-install error messages
by Harry Garrood 27 Sep '13

27 Sep '13

I recently was trying to `cabal install` (with a sandbox) a package I'd made, which depends on scotty-0.5.0. Cabal-install was giving me this message: $ cabal install Resolving dependencies... cabal: Could not resolve dependencies: trying: multicopter-0.0.1 (user goal) next goal: scotty (dependency of multicopter-0.0.1) rejecting: scotty-0.4.6, 0.4.5, 0.4.4, 0.4.3, 0.4.2, 0.4.1, 0.4.0, 0.3.0, 0.2.0, 0.1.0, 0.0.1 (conflict: multicopter => scotty>=0.5.0) Dependency tree exhaustively searched. Note: when using a sandbox, all packages are required to have consistent dependencies. Try reinstalling/unregistering the offending packages or recreating the sandbox. My first assumption was that scotty, and some other package that my package depend on, both want different versions of a third package. I tried removing everything else from the build-depends field, but I got the same message. Then I did a `cabal update` which appears to have fixed it. My question is: Should cabal-install, in this situation, say something like "I'm not aware of a version 0.5.0 for the 'scotty' package. Try `cabal update`" instead?

1 0

add INLINEABLE to maybe, either, bool
by Carter Schonwald 26 Sep '13

26 Sep '13

Its come to my attention that maybe, either, and its new sibling bool, all lack the INLINEABLE attribute, or its more aggressive sibling INLINE this seems like one of those operations where inlining in client use sites is a good option to have, and currently not possible! theres probably other stuff that would benefit from an INLINEABLE pragma in base, but this is an obvious, simple, "easy win" that I noticed when Oliver's patch got merged into base. Thoughts? Time scale: sometime this week? (ghc 7.8 merge window is landing!) cheers

12 21

Re: I've moved the primitive package to github
by Roman Leshchinskiy 26 Sep '13

26 Sep '13

Can't post to ghc-devs from the other address so here it is again... I'm awfully sorry to have gone silent but I just can't find the time for hacking any longer. If someone wants to take over primitive and vector please feel free to do so, I'd be very grateful. Roman On 24/09/13 14:30, Bryan O'Sullivan wrote: > Roman seems to have gone silent, and primitive being broken with GHC > HEAD means that there's a ton of packages we can't build right now. > > Accordingly, I've imported the old darcs repo into git and published it > on github. > > https://github.com/haskell/primitive > > Austin, please plan to fix the GHC build to get its copy of primitive > from here, once we have it working with HEAD.

2 1

findExecutable patch and additions
by Muhaimin Ahsan 22 Sep '13

22 Sep '13

http://ghc.haskell.org/trac/ghc/ticket/2184#comment:13 I've provided a new implementation of findExecutable which actually checks for the executable bit on non-windows platforms. In addition to that, there are also new functions implemented (see the #2184 comment 13). --- Muhaimin Ahsan

1 0

Re: Proposal: Add hasBitSize to Data.Bits.Bits
by John Lato 19 Sep '13

19 Sep '13

> From: Edward Kmett <ekmett(a)gmail.com> > > On Fri, Jul 27, 2012 at 3:42 PM, Ian Lynagh <igloo(a)earth.li> wrote: > >> On Fri, Jul 27, 2012 at 03:06:04PM -0400, Edward Kmett wrote: >> > There is currently no way to know whether or not calling >> > Data.Bits.bitSizewill crash your program. >> > >> > I propose extending the Bits class to include: >> > >> > hasBitSize :: Bits b => b -> Bool >> > >> > such that it returns False for Integer and True for the other instances > > Would it be better to move bitSize into a separate class? > > > I don't think so. Ultimately, you should be able to know for every numeric > type if it has a fixed or variable number of bits. In a perfect world 'd > rather just have bitSize return a Maybe that way we don't have to truck > with partial functions in the API. > > However, the case for just adding hasBitSize is that it avoids breaking > existing code. Given that existing code using bitSize can already cause a crash when used with Integer or other infinite types, wouldn't it be better to break existing code so authors can fix (or at least examine) their use of bitSize? I'm in favor of changing the type of bitSize, although since none of my code uses that function it's an easy position for me to take. John L.

13 40

Proposal: Replace Text.Printf with extensible, complete version
by Bart Massey 18 Sep '13

18 Sep '13

Greetings. This proposal is an extension of previous discussion on the libraries list about replacing Text.Printf with my updated version that provides extensibility of printf to user datatypes and implements much more of the C printf spec, while maintaining backward-compatibility with existing users of printf. There is a separable proposal to move Text.Printf from base into its own package. I support that proposal, but believe that we can take them in either order, and this is the part I know how to do :-). Attached please find a patch that implements the proposal. Note that it also makes slight, backward-compatible modification to Numeric and GHC.Float to avoid a whole bunch of pointless code duplication. The printf patch is kind of ugly because so much of Text/Printf.hs has been replaced. Let me know if it would be better to just provide the whole source. The patch applies and builds against my current top-of-tree GHC. While I would welcome shortening the discussion given how much has already been discussed, Monday 30 September is two weeks from today, so I will treat that as the discussion deadline unless I hear otherwise. Thanks much for the potential opportunity to contribute to the Haskell libraries! Bart Massey bart(a)cs.pdx.edu

2 8

Proposal: Add bool to Data.Bool
by Oliver Charles 15 Sep '13

15 Sep '13

Hello, I would like to propose that the following is added to Data.Bool in base: bool :: a -> a -> Bool -> a bool f _ False = f bool _ t True = t (Aka, bool f t b = if b then t else f) The purpose of this is hopefully evident from its definition. I find myself reaching for this in cases similar to where I would use 'maybe' - often when I'm working with 'fmap' and don't want to start introducing names for the function I am using to map over some functor. I suggested this in #haskell and other people also seem frustrated this doesn't exist, and would like to see it happen - hopefully they will voice their support as a reply here. A quick search on FPComplete's Hoogle [1] shows five equivalent functions on the first page - and I'm sure there are more on subsequent pages. Thoughts? - ocharles --- [1]: https://www.fpcomplete.com/hoogle?q=Bool+-%3E+a+-%3E+a+-%3E+a&env=ghc-7.4.2…

17 29

Proposal: infixr 9 `Compose`
by Bas van Dijk 13 Sep '13

13 Sep '13

I was just bitten by the fact that the type constructor Compose from Data.Functor.Compose associates to the left instead of to the right like function composition. I would like to propose adding the following to Data.Functor.Compose: infixr 9 `Compose` -- analogous to the fixity of (.) This will likely break existing code which uses Compose infix like in the following type: a `Compose` b `Compose` c Discussion deadline: 13 September 2013. Bas

2 5

Data instance for Data.Version
by David Lazar 13 Sep '13

13 Sep '13

Hi, Can we derive Data for Data.Version.Version? It would benefit Cabal. Thanks, David

4 4