November 2012 - Libraries

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

Proposal: split Chan and TChan into read and write ends
by Brandon Simmons 05 Nov '12

05 Nov '12

Hi everybody, Just discovered all the great discussion here, and although my google-fu turned up no prior discussions on this subject, I apologize if it has already been discussed. I propose that Chan and TChan should be implemented as a pair of read and write ends, initialized as follows: newSplitChan :: IO (InChan a, OutChan a) I've implemented this already here: http://hackage.haskell.org/package/chan-split . You can ignore the type classes I've defined; they're there for my own reasons and not part of the proposal. Here is my best defense: 1) My own (and I assume others') use of Chans involves some bits of code which do only reads, and others which do only writes; a split implementation lets us use the type-checker to allocate read or write "permissions" when we pass around either end, and generally makes things easier to reason about. Others have independently reached this conclusion as well. 2) The API is simpler (and in the case of TChans *much* simpler) with a split approach; some examples: in TChan the types of the 'duplicate' functions actually suggest (IMHO) the details of how they treat existing messages, and require a less roundabout explanation dupTChan :: InTChan a -> STM (OutTChan a) cloneTChan :: OutTChan a -> STM (OutTChan a) another example, 'newBroadcastTChan' is actually just: -- | Create a new write end of a TChan. Use dupTChan to get an OutChan that values can be read from. newInTChan :: STM (InTChan a) and doesn't require any explanation beyond that. 3) It's trivial to modify the *Chan libs in this way with a few edits (really, they're already implemented this way, but with some added contortions to return both a read and write end for each operation), so there're no new tricky concurrency issues to reason about. 4) Values written to the write end can be reliably GC'd when readers go away, although recent GHC seems to be able to do this on the current implementation with -O2 on my simple tests. 5) While this is a big API change, I imagine the vast majority of users would only have to change a few type signatures and the Chan initialization action. An `OldChan` module could easily be implemented in terms of the new split version. Alternatively, a *Chan.Split module could be added, and the current Chan module defined in terms of it. So two weeks of discussion? Thanks all, Brandon http://brandon.si

9 10

very last HP mac release candidates for 2012.4.0.0
by Mark Lentczner 05 Nov '12

05 Nov '12

Haskellistas - The third release candidate of the Mac OS X build of HP 2012.4.0.0 is now available: - Mac 32-bit installer: Haskell Platform 2012.4.0.0 32bit rc3 signed.pkg<http://ozonehouse.com/mark/platform/Haskell%20Platform%202012.4.0.0%2032bit…> - Mac 64-bit installer: Haskell Platform 2012.4.0.0 64bit rc3 signed.pkg<http://ozonehouse.com/mark/platform/Haskell%20Platform%202012.4.0.0%2064bit…> Unless I hear hew and cry, I'll bless these, and the rest of 2012.4.0.0 as released tomorrow night. - Mark

1 0

Proposal: Num instance for tuples
by Twan van Laarhoven 01 Nov '12

01 Nov '12

Dear list, One piece of utility code that I find myself writing over and over again is the pointwise Num instance for tuples, i.e. instance (Num a, Num b) => Num (a,b) where fromInteger x = (fromInteger x, fromInteger x) (a,b) + (a',b') = (a + a', b + b') (a,b) - (a',b') = (a - a', b - b') (a,b) * (a',b') = (a * a', b * b') negate (a,b) = (negate a, negate b) abs (a,b) = (abs a, abs b) signum (a,b) = (signum a, signum b) I therefore propose that this instance be added to the base library. If we do that, the equivalent instances for (,,) (,,,) etc. should perhaps also be added, as well as instances for other numeric classes such as Fractional and Floating. Discussion period: 2 weeks, ends 2012-11-01. Twan

15 18