- Libraries - Haskell.org

Monad instance for Monoid e => (,) e
by Nathan van Doorn 26 Jul '13

26 Jul '13

This is a relatively simple instance, so I was surprised that I couldn't find it in base. My proposal is to add the instance to Control.Monad.Instances, undeprecating the module.

8 7

Re: Proposal: Add Chris Done's "om" combinator to Control.Monad
by Stephen Tetley 26 Jul '13

26 Jul '13

Um (-1)... This just looks like a synthetic combinator to me (cue the arbitrary name). Naturally it can make some code shorter (that's the point of combinators) but I have reservations that the code is significantly clearer, more appealing.

3 3

Data.Foldable causes missed foldr/build opportunities
by Gabriel Gonzalez 25 Jul '13

25 Jul '13

I'm now in favor of the `Data.Foldable` proposal, but I just wanted to mention that the proposal needs to include some extra pragma work to ensure that build/foldr optimizations fire. I was just experimenting with the following combinator for `pipes` trying out the following two versions: each :: (Monad m) => [a] -> Producer a m () each = mapM yield each :: (Monad m, Foldable f) => f a -> Producer a m () each = Data.Foldable.mapM yield When I do a pure `pipes`-based fold over both `Producers`s, the version specialized to lists triggers a firing of the build/foldr fusion rule and runs about 20% faster. The true improvement for `mapM` by itself is probably even greater than that because I haven't optimized the folding code yet. The latter version does not trigger the rule firing. Either way I'm going to include the latter `Foldable` version but I just wanted to mention this because I remember people were asking if this would impact fusion or not.

3 5

Install cabal-install without root
by harry 25 Jul '13

25 Jul '13

I'm trying to bootstrap cabal-install on a shared system where I don't have root access. It got stuck on: Linking Setup ... Configuring zlib-0.5.4.0... Setup: Missing dependency on a foreign library: * Missing (or bad) header file: zlib.h * Missing C library: z This problem can usually be solved by installing the system package that provides this library (you may need the "-dev" version). If the library is already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where it is. So I unpacked zlib-dev into my home dir, and pointed $LIBRARY_PATH to it, but I'm still getting the same error. Do I need to modify the .cabal file for every package that I'm trying to install, or is there some way of telling it globally where to find libraries on non-standard paths? -- View this message in context: http://haskell.1045720.n5.nabble.com/Install-cabal-install-without-root-tp5… Sent from the Haskell - Libraries mailing list archive at Nabble.com.

2 3

Re: ListT proposal for `transformers`
by Gabriel Gonzalez 21 Jul '13

21 Jul '13

> It seems there are 140 packages on hackage using ListT (which surprised > me, given its flaws), so I don't think we can quickly remove it from > transformers or re-implement it under the same name Don't worry. I've decided to keep it under `pipes` anyway. It seems like a more natural fit for it to be in `pipes` because it is otherwise very hard to build or consume `ListT`-done-right computations. So consider this proposal to be retracted.

1 0

ANN: data-fin
by wren ng thornton 20 Jul '13

20 Jul '13

-------------------------------------------- -- data-fin 0.1.0 -------------------------------------------- The data-fin package offers the family of totally ordered finite sets, implemented as newtypes of Integer, etc. Thus, you get all the joys of: data Nat = Zero | Succ !Nat data Fin :: Nat -> * where FZero :: (n::Nat) -> Fin (Succ n) FSucc :: (n::Nat) -> Fin n -> Fun (Succ n) But with the efficiency of native types instead of unary encodings. -------------------------------------------- -- Notes -------------------------------------------- I wrote this package for a linear algebra system I've been working on, but it should also be useful for folks working on Agda, Idris, etc, who want something more efficient to compile down to in Haskell. The package is still highly experimental, and I welcome any and all feedback. Note that we implement type-level numbers using [1] and [2], which works fairly well, but not as nicely as true dependent types since we can't express certain typeclass entailments. Once the constraint solver for type-level natural numbers becomes available, we'll switch over to using that. [1] Oleg Kiselyov and Chung-chieh Shan. (2007) Lightweight static resources: Sexy types for embedded and systems programming. Proc. Trends in Functional Programming. New York, 2--4 April 2007. http://okmij.org/ftp/Haskell/types.html#binary-arithm [2] Oleg Kiselyov and Chung-chieh Shan. (2004) Implicit configurations: or, type classes reflect the values of types. Proc. ACM SIGPLAN 2004 workshop on Haskell. Snowbird, Utah, USA, 22 September 2004. pp.33--44. http://okmij.org/ftp/Haskell/types.html#Prepose -------------------------------------------- -- Links -------------------------------------------- Homepage: http://code.haskell.org/~wren/ Hackage: http://hackage.haskell.org/package/data-fin Darcs: http://community.haskell.org/~wren/data-fin Haddock (Darcs version): http://community.haskell.org/~wren/data-fin/dist/doc/html/data-fin -- Live well, ~wren

1 0

ListT proposal for `transformers`
by Gabriel Gonzalez 20 Jul '13

20 Jul '13

I've been working on a "ListT done right" for submission into `transformers`. I could split it off into its own package, but I would like to first run it by you all, particularly Ross, to see if this can be included this in `transformers` because I feel that `transformers` is where this belongs. I've lpasted the implementation here: http://lpaste.net/90890 I've written it to follow the spirit of the `transformers` library as closely as possible, both in API, documentation, and source code style. I'm fine with either replacing the old `ListT` implementation or providing both. I'll leave it to you guys to make the call on that. As long as the correct version is in `transformers` somewhere then I'm happy. If I *had* to pick a side, I suppose I would favor replacing the old one. Also, any suggestions for changes are welcome, particularly if they improve the likelihood of this getting into `transformers`.

5 5

Re: Void type in base
by wren ng thornton 20 Jul '13

20 Jul '13

On 7/17/13 3:48 PM, David Luposchainsky wrote: > +1 in genereal. A few remarks: I'm also +1 for the proposal. > 1. We don't live in a C world. Agreed. It's bad enough that C taught people to believe that "void" means the unit return type. But C aficionados will have to relearn all their terminology anyways when coming to Haskell. I don't see how renaming the Void type would really help them. -- Live well, ~wren

2 1

Proposal: Strict scanl, scanl1 and mapAccumL
by Bas van Dijk 18 Jul '13

18 Jul '13

Hi, Data.List exports strict versions of foldl an foldl1. I think it should also export these strict versions of scanl, scanl1 and mapAccumL: scanl' :: (a -> b -> a) -> a -> [b] -> [a] scanl' f q ls = q : (case ls of [] -> [] x:xs -> let q' = f q x in q' `seq` scanl f q' xs) scanl1' :: (a -> a -> a) -> [a] -> [a] scanl1' f (x:xs) = scanl' f x xs scanl1' _ [] = [] mapAccumL' :: (acc -> x -> (acc, y)) -> acc -> [x] -> (acc, [y]) mapAccumL' _ s [] = (s, []) mapAccumL' f s (x:xs) = (s'',y:ys) where (s', y ) = f s x (s'',ys) = s' `seq` mapAccumL' f s' xs Is there a good reason they're not included? Discussion deadline: 2 weeks (till Monday 26 November). Regards, Bas

9 18

System.Random - bugs? or am I just confused?
by Hans Georg Schaathun 18 Jul '13

18 Jul '13

Hi all, I have been digging into the System.Random module lately. Initially, I was concerned about the split method, but trying to understand the code and algorithm, there are a couple of other issues that bother me. I hope this is the right forum to ask about them ... I think at least some of them are bugs, but then, there may be some deliberate design choices which I don't see. If there aren't, I guess I will propose a patch. Any opinions? 1. The range of the Standard Generator. stdRange gives a lower bound of 0. As far as I can see, 0 is an impossible value. Should the range not start at 1? 2. randomIvalInteger. One error has already been noted in the comment. Is it not trivial to calculate b based on genRange? Is there some drawback which has prevented such a change? 3. randomIvalInteger again. The drawing of n random numbers, multiplying the ith one by b^i, before summing them all, would make sense to me if the n random numbers had range 0..b-1, and we started the sum at acc=0. As far as I can see, the pseudo-random have range 1..b+1 (assuming the standard generator), and the acc parameter to f starts at 1. Is this a bug? Or what am I missing? 4. A possible error is also indicated by a comment in iLogBase, where iLogBase b b = 2. Should the if-condition i < b be changed to i <= b? Or is it more tricky? Thanks a lot in advance, :-- George

3 2