October 2012 - Libraries

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

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

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

Proposal: packages in GHC should have different versions from hackage if the packages differ
by Henning Thielemann 31 Oct '12

31 Oct '12

I opened the following ticket [1] about the versioning of packages shipped with GHC, but was told to start a discussion first. I hope libraries(a)haskell.org is the right place to do that. [1] http://hackage.haskell.org/trac/ghc/ticket/6053 Let me repeat the issue description here: I try to compile a package with many dependencies using GHC-7.5.20120426 in order to check whether #5970 is resolved. This turns out to be difficult because this temporary GHC version seems to use packages with the same version as their counterparts on Hackage but different content. For example GHC-7.5.20120426 is bundled with unix-2.5.1.0 and bytestring-0.10.0.0. However the unix-2.5.1.0 on Hackage excludes bytestring-0.10.0.0. Thus cabal-install refuses to install something that depends on unix-2.5.1.0. Another example: Both GHC-7.4.1 and GHC-7.5.20120426 are bundled with base-4.5.0.0. However in GHC-7.5, Num is no longer superclass of Bits. I think such a change requires a version bump to base-4.6. In my opinion the condition should be that if you publish a package on Hackage then there should not be a package with the same version but different content somewhere else. Thus I propose that package versions are increased immediately in the repository according to the PVP if something is changed. That's how I handle versioning for my private packages, too.

5 5

Time to add the Traversable laws to the Documentation
by roconnor＠theorem.ca 30 Oct '12

30 Oct '12

Based on recent work of Edward Kmett and myself and older work by Twan van Laarhoven, we have derived a set of laws for Traversable that are essentially the same to the Laws given by Jeremey Gibbons, Bruno Oliveria in "The Essence of the Iterator Pattern" and which are again the same as the laws given by Mauro Jaskelioff and Ondrej Rypacek in "An Investigation of the Laws of Traversals". With such wide spread agreement going back at least 6 years, I think it is time to add the following 2 laws to the documentation for Data.Traversable.Traversable. (1) traverse Identity == Identity (2) traverse (Compose . fmap g . f) == Compose . fmap (traverse g) . traverse f (and adding a link to the paper titled "An Investigation of the Laws of Traversals" is probably also worthwhile.) In some publications you will see law 1 written as traverse (Identity . f) == Identity . fmap f This is form is equivalent to law 1 by parametricity. Another alterantive formulation of law 1 is traverse pure == pure which is equivalent to law 1 by the Applicative typeclass parametricity. I can provide short proofs of these two equivalences on demand. Of these different formulations of law (1), I think "traverse Identity == Identity" is the nicest because it is concise, mirrors the analogous functor law, and Identity is the natural identity element for Compose. But more importantly, some choice of formal specification of the traversal laws needs to be added to the documentation. -- Russell O'Connor <http://r6.ca/> ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.''

3 8

Re: Proposal: split Chan and TChan into read and write ends
by Brandon Simmons 30 Oct '12

30 Oct '12

> On 10/27/12 12:28 PM, Johan Tibell wrote: >> I think this makes for a great package or perhaps an extra >> Unidirectional module nested inside the Chan module. Breaking the well >> used Chan API doesn't seem necessary in this case. > > I agree. I like the idea, and I'd like to see it gain traction, but I'm > not so keen on breaking the Chan/TChan API. Also, there seem to be some > API issues to be ironed out (e.g., someone proposed > > newBrodcastTChan :: STM (InTChan a, STM (OutTChan a)) > > which has an obvious meaning, over > > newInTChan :: STM (InTChan a) > > which is going to take some explaining.) I assume you mixed those up? `newBroadcastTChan` naturally turns into the (IMHO) much simpler `newInTChan` when the chan ends are split. > > > It sounds like many people have implemented versions of this and > uploaded them to Hackage already. Perhaps the best approach would be to > (1) unify all those packages into a single "blessed" package, to reduce > redundancy; (2) advertise that package as the way to go for new > projects; (3) add it to the Platform if it gains traction; (4) maybe get > around to deprecating the current Chan/TChan API some years down the > road when it's no longer popular. The best approach then for this route would be to go through the Chan and TChan package and to turn it into a "split" version with minimum edits (should only take a few minutes), perhaps changing a few names where a better one obviously exists or the original no longer makes sense (e.g. newBroadcastTChan). That way people can both see it's correct, and easily port their code over. I also wanted to link to in my original post, but couldn't find for some reason, Leon P Smith's library: http://hackage.haskell.org/package/split-channel It uses the name 'listen' for the equivalent function to the old 'dupTChan' which I think is an excellent choice. Brandon

1 0

Re: Proposal: split Chan and TChan into read and write ends
by Brandon Simmons 27 Oct '12

27 Oct '12

On Sat, Oct 27, 2012 at 8:48 PM, Shachaf Ben-Kiki <shachaf(a)gmail.com> wrote: > On Fri, Oct 26, 2012 at 8:23 PM, Brandon Simmons > <brandon.m.simmons(a)gmail.com> wrote: >> 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. >> > > To (1), it's probably worth mentioning the idiom of pre-applying > readTChan and writeTChan to a channel to produce values of types "STM > a" and "a -> STM ()", which gives you something pretty similar to > read-only and write-only channels. It doesn't solve every problem, but > for many things it's much simpler than introducing special-purpose > types that only ever have one operation applied to them (similarly you > could use values "STM (STM a)" with dupTChan/newBroadcastTChan, and so > on). > > Shachaf Ah! I use that myself in a library because it let me create Functor and Contravariant instances for the read and write ends respectively, and I didn't require any additional operations beyond read and write.

2 1

Release Candidates for Haskell Platform 2012.4.0.0
by Mark Lentczner 26 Oct '12

26 Oct '12

The second release candidate of HP 2012.4.0.0 is now available: - Source tarball: haskell-platform-2012.4.0.0-rc2.tar.gz<http://ozonehouse.com/mark/platform/haskell-platform-2012.4.0.0-rc2.tar.gz> - Mac 32-bit installer: Haskell Platform 2012.4.0.0 32bit rc2 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 rc2 signed.pkg<http://ozonehouse.com/mark/platform/Haskell%20Platform%202012.4.0.0%2064bit…> - Windows installer: HaskellPlatform-2012.4.0.0-rc1-setup.exe<http://code.haskell.org/~refold/HaskellPlatform-2012.4.0.0-rc1-setup.exe> Tickets closed for this release: http://trac.haskell.org/haskell-platform/query?status=closed&group=componen… If you can, please test the release candidate and let us know how it works out. We are on track for final release on November 5th. - Mark

1 0

Re: [Haskell-cafe] Release Candidate 2: HP 2014.4.0.0
by Mark Lentczner 19 Oct '12

19 Oct '12

On Fri, Oct 19, 2012 at 9:30 AM, Colin Adams <colinpauladams(a)gmail.com>wrote: > That's VERY efficient (2014 editions out in 2012). Silly me! Of course, the links are correct: no time travel this cycle - just plain ole' 20*12*.4.0.0 .. aaaaaand: Mac OS 64-bit candidate is out: Haskell Platform 2012.4.0.0 64bit rc2 signed.pkg<http://www.ozonehouse.com/mark/platform/Haskell%20Platform%202012.4.0.0%206…> *NOTE:* You can only have one architecture per HP version at a time installed on Mac OS X. If you want to switch architectures within the same version of the platform, please use the *uninstaller-hs* utility to remove the one you have *before* installing the other one. If you don't, you'll get an installer error at the end -- it will all work, but your documentation will be less than perfect. *NOTE:* If you use macports <http://www.macports.org/> or homebrew<http://mxcl.github.com/homebrew/>, then be sure that you choose the same architecture (32bit / 64bit) as macports or brew is using, since I believe those systems do not install universal libs (both architectures) by default. - Mark

1 0