- Libraries - Haskell.org

Re: Proposal: Add (&) to Data.Function
by John Lato 21 Nov '12

21 Nov '12

> > From: David Menendez <dave(a)zednenem.com> > > On Tue, Nov 20, 2012 at 11:59 AM, Yitzchak Gale <gale(a)sefer.org> wrote: > > > It is a common idiom to write a sequence of composed combinators in > > reverse order to the way they would be written with ($) or (.). That > > naturally expresses the idea of the combinators as operations being > > applied in the given order. > > > > I think the bar should be pretty high before we add a third way to write > function application to base. How common is this? Common among whom? Why > can't the existing idioms of (.) and ($) work just as well? > I guardedly agree with Dave Menendez. There are a very limited number of convenient 1-character operators available, and I'm not certain that function application should take up 3 of them. On the other hand, this is a common enough idiom to have emerged in both diagrams and lens at least. (I'm not taking a position at this time) John L.

1 0

Proposal: Add setEnv/unsetEnv to "base"
by Simon Hengel 19 Nov '12

19 Nov '12

Hi, setting environment variables is possible on both POSIX and Windows systems. Currently this functionally is missing from System.Environment; the "unix" package provides an implementation for POSIX systems. I propose to add setEnv/unsetEnv to System.Environment, so that it is easier to write applications that behave the same on POSIX and Windows systems. I implemented both in a way, so that they behave exactly the same on POSIX and Windows (modulo case sensitivity on Windows). For now I prepared a standalone implementation [1] and corresponding tests [2]. That implementation depends on the "unix" package. If the proposal is accepted, I will prepare a patch against "base" that includes the relevant code from "unix". Discussion Period: 2 Weeks Cheers, Simon [1] https://github.com/sol/setenv/blob/master/src/System/SetEnv.hs [2] https://github.com/sol/setenv/blob/master/test/System/SetEnvSpec.hs

8 13

intersectionSet, differenceSet
by Henning Thielemann 16 Nov '12

16 Nov '12

When using the new Data.Map.fromSet function I encountered that I use it many times in connection with Map.intersection and Map.difference like so Map.intersection m (Map.fromSet (const ()) s) Map.difference m (Map.fromSet (const ()) s) Actually the element types of the second operands of Map.intersection and Map.difference are completely independent and the values of these maps are not touched. Thus I think that intersection and difference with a Set are the more natural operation. How about adding Map.intersectionSet :: Ord k => Map k a -> Set k -> Map k a Map.differenceSet :: Ord k => Map k a -> Set k -> Map k a to Data.Map?

3 3

Cabal: download dependencies for later offline build
by Bram Neijt 14 Nov '12

14 Nov '12

Dear reader, I'm experimenting with creating my own little build server using disk images as job input/output and KVM to run them[1]. As a security measure, the build process does not have any network access during the build, so I need to make sure everything is available before the build starts. What is the easiest way to "take a cabal build offline" as it were, so I can make sure a cabal build will work without a network connection? Greetings, Bram [1] https://github.com/bneijt/construir/

2 2

mtl-2.1 severly broken, cabal needs blacklisting
by Andreas Abel 14 Nov '12

14 Nov '12

After 2 days of shrinking 251 modules of source code to a few lines I realized that modify in MonadState causes <<loop>> in mtl-2.1. http://hackage.haskell.org/packages/archive/mtl/2.1/doc/html/src/Control-Mo… The bug has been fixed, apparently seven month ago. https://github.com/ekmett/mtl/pull/1 However, the "malicious" mtl-2.1 still lingers on: it is available from hackage and installed in many systems. This calls for a means of blacklisting broken or malicious packages. cabal update should also pull a blacklist of packages that will never be selected by cabal install (except maybe by explicit user safety overriding). I think such a mechanism is not only necessary for security purposes, but also to safe the valuable resources of our community. Cheers, Andreas -- Andreas Abel <>< Du bist der geliebte Mensch. Theoretical Computer Science, University of Munich Oettingenstr. 67, D-80538 Munich, GERMANY andreas.abel(a)ifi.lmu.de http://www2.tcs.ifi.lmu.de/~abel/

5 8

Re: [Haskell-cafe] hackageDB haddock errors
by Andreas Abel 13 Nov '12

13 Nov '12

I found that for the recently uploaded Agda-2.3.2 there is no haddockumentation. Stumbling over the build protocol by chance http://hackage.haskell.org/packages/archive/Agda/2.3.2/logs/success/ghc-7.6 I searched for whether haddock had been executed and found, yes, but also, it failed: ... 40% ( 2 / 5) in 'Agda.Syntax.Abstract.Pretty' haddock: internal error: /tmp/ghc17357_0/ghc17357_126.s: hPutBuf: resource exhausted (No space left on device) Q: Could this build be run again, with sufficient disk space? For gtk-0.12.4 there is another explanation: it has build failures: http://hackage.haskell.org/packages/archive/gtk/0.12.4/logs/failure/ghc-7.6 On 13.11.2012 16:41, timothyhobbs(a)seznam.cz wrote: > Hello, > There are several packages without haddock documentation on hackage. > The one that bugs me right now, is the latest version of gtk2hs: > http://hackage.haskell.org/package/gtk > I've been told that this may be due to hackage updating docs with an > infrequent cron job, so that new packages don't get their docs for a > long time. Whatever is causing it, the fact that hayoo > http://holumbus.fh-wedel.de/hayoo/hayoo.html always uses the most > frequent docs, means that I cannot currently search for anything gtk2hs > related :( > > Can someone please look into prodding this cron job so it doesn't take > days to run, or look into resolving any errors that might be causing > this unfortunate behaviour? > > Thank you for your time, > and happy hacking, > Timothy -- Andreas Abel <>< Du bist der geliebte Mensch. Theoretical Computer Science, University of Munich Oettingenstr. 67, D-80538 Munich, GERMANY andreas.abel(a)ifi.lmu.de http://www2.tcs.ifi.lmu.de/~abel/

1 0

Proposal: Remove Control.Concurrent{QSem,QSemN,,SampleVar,mergeIO,nmergeIO} from base
by Ian Lynagh 12 Nov '12

12 Nov '12

Hi all, I propose that we remove Control.Concurrent.QSem Control.Concurrent.QSemN Control.Concurrent.SampleVar Control.Concurrent.mergeIO Control.Concurrent.nmergeIO from base. Rationale: There is no real need for them to be in base, and they are not being well-maintained there (e.g. see [3160]). Chris Kuklewicz has already made a SafeSemaphore package that provides fixed versions of the 3 modules. Patch is attached (but basically it just removes the above). Suggested discussion deadline: Fri 22 June 2012. [3160] http://hackage.haskell.org/trac/ghc/ticket/3160 Thanks Ian

15 22

Proposal: alpha-rename the type signatures of foldl, foldl', and scanl to be consistent with foldr and scanr
by Gábor Lehel 10 Nov '12

10 Nov '12

Currently we have: foldl :: (a -> b -> a) -> a -> [b] -> a foldr :: (a -> b -> b) -> b -> [a] -> b I find this confusing. My brain doesn't do automatic alpha-renaming, so I end up thinking that these types are very different because they look very different. In fact, they are almost the same. Embarrassingly, it took me longer than it took to understand monads, GADTs, PolyKinds, and several other things before I realized it! So I propose that we use 'a' consistently to denote the type of the list elements, and 'b' to denote the type of the result: foldl :: (b -> a -> b) -> b -> [a] -> b foldr :: (a -> b -> b) -> b -> [a] -> b making it obvious that the only difference is the order of parameters to the accumulator. The total change would be to replace Prelude.foldl :: (a -> b -> a) -> a -> [b] -> a Prelude.scanl :: (a -> b -> a) -> a -> [b] -> [a] Data.List.foldl' :: (a -> b -> a) -> a -> [b] -> a Data.Foldable.foldl :: (a -> b -> a) -> a -> t b -> a Data.Foldable.foldl' :: (a -> b -> a) -> a -> t b -> a with Prelude.foldl :: (b -> a -> b) -> b -> [a] -> b Prelude.scanl :: (b -> a -> b) -> b -> [a] -> [b] Data.List.foldl' :: (b -> a -> b) -> b -> [a] -> b Data.Foldable.foldl :: (b -> a -> b) -> b -> t a -> b Data.Foldable.foldl' :: (b -> a -> b) -> b -> t a -> b I've attached a patch. Discussion period: 2 weeks Previously discussed at: http://www.reddit.com/r/haskell/comments/10q2ls/ -- Your ship was destroyed in a monadic eruption.

19 34

Improving Data.Char.isSpace performance
by John MacFarlane 08 Nov '12

08 Nov '12

I think that 'isSpace' from Data.Char (and hence also 'words' from the Prelude) is not as fast as it could be. Here is the definition (which is actually found in GHC.Unicode): isSpace :: Char -> Bool isSpace c = c == ' ' || c == '\t' || c == '\n' || c == '\r' || c == '\f' || c == '\v' || c == '\xa0' || iswspace (fromIntegral (C.ord c)) /= 0 I presume that the point of the disjuncts at the beginning is to avoid the call to iswspace for the most common space characters. The problem is that most characters (in most texts) are not space characters, and for nonspace characters iswspace will always be called. So I investigated a possible optimization that would also check for the most common nonspace characters before calling iswspace: isSpace_Alt :: Char -> Bool isSpace_Alt c | c > '\x20' && c < '\xa0' = False | c == ' ' = True | '\t' <= c && c <= '\r' = True | c == '\xa0' = True | otherwise = iswspace (fromIntegral (C.ord c)) /= 0 In my benchmarks, this function significantly outperforms isSpace. I also found that a version of isSpace that does not check for nonspace characters, but uses case matching instead of a disjunction of equality tests, outperformed isSpace (but was usually not as fast as isSpace_Alt, and the difference mostly disappears with -O2): isSpace_Pattern :: Char -> Bool isSpace_Pattern c | c == ' ' = True | '\t' <= c && c <= '\r' = True | c == '\xa0' = True | otherwise = iswspace (fromIntegral (C.ord c)) /= 0 I benchmarked all three functions against five types of text (all ascii, all Greek, Haskell code, characters 0..255, and all spaces), and here are the (normalized) results: Compiled with 'ghc --make': -------------------------------------------------------------- Input isSpace_DataChar isSpace_Pattern isSpace_Alt --------------- ---------------- --------------- ----------- ascii text 1.0 0.54 0.17 greek text 1.0 0.57 0.71 haskell code 1.0 0.57 0.24 chars 0..255 1.0 0.54 0.39 all space chars 1.0 0.70 0.90 -------------------------------------------------------------- Compiled with 'ghc --make -O2': -------------------------------------------------------------- Input isSpace_DataChar isSpace_Pattern isSpace_Alt --------------- ---------------- --------------- ----------- ascii text 1.0 0.93 0.40 greek text 1.0 0.98 0.99 haskell code 1.0 1.03 0.58 chars 0..255 1.0 0.92 0.62 all space chars 1.0 0.88 0.92 -------------------------------------------------------------- My benchmark program can be found here: https://gist.github.com/3967761 I'd like to propose that we consider replacing the definition of isSpace with isSpace_Alt. John

10 19

Announce: Haskell Platform 2012.4.0.0
by Mark Lentczner 07 Nov '12

07 Nov '12

I'm pleased to announce that Haskell Platform 2012.4.0.0<http://www.haskell.org/platform/index.html#2012.4.0.0>is now available. This release contains three new packages to the platform: - async-2.0.1.3<http://lambda.haskell.org/platform/doc/current/packages/async-2.0.1.3/doc/h…> - split-0.2.1.1<http://lambda.haskell.org/platform/doc/current/packages/split-0.2.1.1/doc/h…> - vector-0.10.0.1<http://vector-0.10.0.1http://lambda.haskell.org/platform/doc/current/packag…> The remainder of the changes are small updates to the versions of GHC (now 7.4.2) and several other packages. Installers for Windows <http://www.haskell.org/platform/windows.html>, Mac OS X <http://www.haskell.org/platform/mac.html>, and the source tar ball<http://www.haskell.org/platform/linux.html>are all now available from the site. Linux distribution packages should be available shortly. On behalf of the Haskell Platform team<http://trac.haskell.org/haskell-platform/wiki/Members> , - Mark "mzero" Lentczner, Release Manager

5 5