July 2009 - Libraries

Proposal #3339: Add (+>) as a synonym for mappend
by Bryan O'Sullivan 08 Nov '11

08 Nov '11

Ticket: http://hackage.haskell.org/trac/ghc/ticket/3339 >From the ticket: This proposal was, I think, originally suggested by Jules Bean. The idea is to add two functions to the Data.Monoid module, (+>) and (<+), corresponding to different uses of mappend. These should not be methods of the Monoidtypeclass, but top-level functions. I hope (but slightly doubt) that the visual nature of the two operators might help to counter the thought that monoids are just for gluing things together. (+>) :: (Monoid a) => a -> a -> a a +> b = a `mappend` b (<+) :: (Monoid a) => a -> a -> a a <+ b = b `mappend` a infixl 4 +> infixl 4 <+ Proposed deadline: two weeks. If this looks reasonable, I'll attach darcs patches.

30 75

There are too many error handling conventions used in library code!
by dons＠cse.unsw.edu.au 13 Aug '11

13 Aug '11

This article on the 8 different error handling strategies various common Haskell libs use: http://www.randomhacks.net/articles/2007/03/10/haskell-8-ways-to-report-err… got me thinking: we need to standardise/recommend a small set of methods for library error handling. The lack of consistent error reporting between libs results in verbose code, as we're not able to use a single error handling technique when gluing together code from different libs (i.e. we can't just use Maybe or Either/ErrorT). (It's always nice when you *can* use, say, a Maybe monad to glue code from a number of sources, but eventually you reach code with a different error system, and the Maybe monad breaks down). So, some questions I think we can tackle: * can we identify error handling strategies from the list that should not be used anymore? (throwDyn?) * can we move some of the outlying libraries to a more consistent error framework? * do we need more support for gluing together our different error systems? (it should be easier to glue code using , say, Maybe/Either). * what role does MonadError play here, as a generic error handler? * can we make precise recommendations about which error strategies to use? -- Don

11 16

Proposal #2629: Data.List: Replace nub; add nubOrd, nubInt, nubWith
by Bart Massey 24 Feb '10

24 Feb '10

http://hackage.haskell.org/trac/ghc/ticket/2629 Everyone always complains about nub, but nobody ever does anything about it except (map head . group . sort), which isn't lazy and isn't always faster. :-) I've implemented a new function nubWith that takes a "stop list" as an argument and filters its target list against the stop list. I've then re-implemented nub and implemented nubOrd and nubInt in terms of nubWith: the stop list is a typeclass, so these implementations are trivial and new implementations are easily added. nubBy is left alone, since there's nothing obvious to be done about it. All of the nubs are still fully lazy. Basic QuickCheck tests are provided, and pass. Performance benchmarking code is provided. The performance of my nub implementation is quite comparable to that of the standard one. My nubOrd and nubInt implementations are dramatically faster, since they use a Set and IntSet respectively for the stop list. In particular, they are performant on long lists with long nubs, unlike the basic nub. My implementation is available via git at git://svcs.cs.pdx.edu/git/nub.git or can be browsed at http://svcs.cs.pdx.edu/gitweb?p=nub.git;a=tree and has a maybe-outdated tarball at http://svcs.cs.pdx.edu/haskell/nub.tar.gz The Nub.hs file itself is attached to the proposal. If the proposal is accepted, I will prepare a patch against current GHC library top-of-tree, but for now it seems easier for everyone to just look at the bits in their current natural habitat.

15 31

Adding an ignore function to Control.Monad
by Gwern Branwen 12 Jan '10

12 Jan '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 So while writing my wp-archivebot, I ran into the issue that forkIO requires IO () but returns IO ThreadId, and that many useful IO functions will return IO a instead of IO (). This forces some awkward contortions. Suppose I want to ping the WebCite website at a particular address, and this request makes WebCite archive a URL embedded in that address. Presumably I could venture into the depths of Network.HTTP to figure out how to ping an URL without also pulling down the server's HTML, but why do that when I already have obviously 'openURL :: String -> IO String'? Much easier to do something like 'openURL "webcite.org" ++ foo ++ "other stuff" '. But my bot needs to handle quite a few URLs; one at a time, what with all the waits and timeouts, isn't going to hack it. So for a given link, I forkIO the openURL request. But of course, forkIO demands IO (), so I toss in a '>> return ()'. Fair enough. So I examine the performance, and it's still too slow. Recent Changes has hundreds of different pages a minute. I'd better fork each page (and then fork for each link). But wait, all those forkIOs are returning IO ThreadIds, and my top-level forkIO call demands IO ()... So another >> return (). At this point, the code is starting to look pretty silly - something like '...stuff >> return ()) >> return ())'. So I see the repeated pattern, and by the rule of 3, factor it out to: - -- | Convenience function. 'forkIO' and 'forM_' demand return types of 'IO ()', but most interesting - -- IO functions don't return void. So one adds a call to 'return ()'; this just factors it out. ignore ∷ (Monad m) ⇒ m a → m () ignore x = x >> return () Not the most complex convenience function I've ever written, but not any simpler than, say Control.Monad.forever or for that matter, most of the stuff in Control.Monad. I'd think it'd be useful for more than just me. Agda is lousy with calls to '>> return ()'; and then there's ZMachine, arrayref, whim, the barracuda packages, binary, bnfc, buddha, bytestring, c2hs, cabal, chesslibrary, comas, conjure, curl, darcs, darcs-benchmark, dbus-haskell, ddc, dephd, derive, dhs, drift, easyvision, ehc, filestore, folkung, geni, geordi, gtk2hs, gnuplot, ginsu, halfs, happstack, haskeline, hback, hbeat... You get the picture. I realize the specific name of 'ignore' can be bikeshedded to death, but it's clear, it's short, Hoogle turns up one other function with ignore in its name (Distribution.ParseUtils ignoreUnrec), and it's been independently named 'ignore' by another Haskeller (lilac). Existing uses of the string 'ignore are rare - it's in a few places as a variable, cabal and cabal-install and ehc and tar have where definitions of an ignore, a test for directory defines an ignore and imports Control.Monad unqualified, fit defines an 'ignore' but doesn't seem to use it in any module that also imports Control.Monad unqualified, halipeto defines an ignore but doesn't import Control.Monad, shim/yi has a let definition of an ignore, yhc has a where definition of an ignore. And that's about it. One of directory's tests would break, and the rest might have an additional -Wall warning. - -- gwern -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREKAAYFAkov5Q0ACgkQvpDo5Pfl1oIsRQCghUqynThzcT+OYV1KaYJhGFhv 6yYAnjf7CVOm0+Fg1FBa9IpdVIrRpCZm =Cd8V -----END PGP SIGNATURE-----

18 32

export toDescList from Data.Map
by Evan Laforge 25 Nov '09

25 Nov '09

So, I mentioned this a long time ago but didn't get any responses and then I got distracted. So this time I added a ticket and patch and everything: 2580 Here's the text: It's even implemented, but not exported. Without this, there's apparently no way to iterate over a map from high to low, since foldl is also not exported. Also, I implemented a toDescList for IntMap, and could do the same for Set, and could add those patches, if people agree it's a good idea. In addition, is there any problem with exporting foldl aka descending for the three modules? I implemented a foldl for IntMap and it seems to work, but I'd want someone smarter to look for problems with it. In addition, Set and Map are inconsistent with folds: Set exports 'fold' and says "no order is guaranteed", but it's just defined to foldr, which is in ascending order. Set.foldr itself is not exported. Meanwhile, Map also exports fold, but heavily implies from the doc that it's guaranteed to be ascending. Would it restrict implementation changes too much to export a descending fold for all three? Other languages that have tree oriented general purpose maps all let you start anywhere and iterate in either direction. Anyway, is 2-3 weeks ok for discussion period? The library submission wiki doesn't say how long.

6 13

Three patches for cabal
by Niklas Broberg 09 Nov '09

09 Nov '09

(Trying again since my previous patches were too big for the list.) While doing a survey[1] of the extensions registered with Cabal, I came across two warts in the list of constructors, and one constructor that should be deprecated. First there's the constructor called TransformListComp, which should really be named GeneralizedListComp, since the constructor should describe the extension and not the implementation scheme. Second there's the constructor NoMonoPatBinds, which actually describes the default Haskell 98 behavior, even if GHC has a different default. It's GHC's behavior that is the extension, so the constructor in cabal should really be named MonoPatBinds. Also, the PatternSignatures constructor has been deprecated in GHC and superceded by ScopedTypeVariables. The attached patches (three in one file) adds the proposed new constructors, deprecates the old ones, and adds documentation. Cheers, /Niklas

8 15

proposal #3335: make some Applicative functions into methods, and split off Data.Functor
by Ross Paterson 19 Aug '09

19 Aug '09

The proposal is that the following functions (<$) :: Functor f => a -> f b -> f a (*>) :: Applicative f => f a -> f b -> f b (<*) :: Applicative f => f a -> f b -> f a some :: Alternative f => f a -> f [a] many :: Alternative f => f a -> f [a] are moved into the corresponding classes, with the existing implementations as default definitions. This gives people creating instances the option of defining specialized implementations of these functions, though they should be equivalent to the default definitions. Although (<$) is now a method of the Functor class, it is hidden in the re-export by the Prelude, Control.Monad and Monad. The new module Data.Functor exposes the full class, plus the function (<$>). These are also re-exported by Control.Applicative. Deadline: 20th July 2009.

7 24

hasktags enhancements ? How to contribute?
by Marc Weber 18 Aug '09

18 Aug '09

Hi, more than a year ago I enhanced hasktags. Now I had another look at my code ensuring that it finds at least as many tags as the hackage implementation does. It also adds a small test suite ensuring progress. So let me know how well it works for you. If some tags aren't found send me a test case so that I can add it to the test suite. Where to get it from: darcs get http://mawercer.de/~marc/my-hasktags So what's different ? - it finds more tags (see details below) - it adds tag kinds (vim only) Example: SpacingCombiningMark ./2/testcase2.hs 154;" cons Surrogate ./2/testcase2.hs 175;" cons TitlecaseLetter ./2/testcase2.hs 150;" cons UppercaseLetter ./2/testcase2.hs 148;" d digitToInt ./2/testcase2.hs 131;" ft digitToInt ./2/testcase2.hs 132;" fi cons = contstructor ft = funtion type fi = function implementation m = module - adds the flag --ignore-close-implementation eg if you have abc,def :: Int abc = 7 {- 20 line comment .. -} def = 8 abc is added once (because the type definition and the implementation is very close) but def is added twice because you may want to jump to either one directly. That's important because :tjump (vim) won't bother you asking you which one to take. So the list of tags is shorter in general. details about finding more tags: a) it finds more tags -> [1] Example (by testcase) 1) module Main where import Text.JSON func = ... using this strange indentation the hackage hasktags fails horribly (test case 1) 2) from Data.Char #ifndef __GLASGOW_HASKELL__ isAsciiUpper, isAsciiLower :: Char -> Bool isAsciiLower c = c >= 'a' && c <= 'z' isAsciiUpper c = c >= 'A' && c <= 'Z' #endif this isAsciiUpper isn't found by the hackage version for some reason 4) the basic rootLoggerName isn't found! module System.Log.Logger rootLoggerName = "" 5) Saying those aren't found isn't quite true. the hackage version just doesn't remove the parenthesis and adds (@?) to the tag file. 8) ABCD isn't found because of this parenthesis class (Show a) => (ABCD a) where Again (ABCD is found instead. You can test this yourself by running my testsuite (cd testcases; sh test.sh) Marc Weber

1 1

Re: Adding an ignore function to Control.Monad
by John Lato 14 Aug '09

14 Aug '09

> From: Henning Thielemann <lemming(a)henning-thielemann.de> > > Isaac Dupree schrieb: >> On the other hand, maybe it's also an argument to change all the >> functions like forkIO from >> :: IO () -> IO ThreadID >> to >> :: IO a -> IO ThreadID >> >> I mean, surely they don't rely on the value of a () return-type, other >> than to pass on to other places that artificially require the ()-type? > > No, I think it is already bad enough, that (>>) has type (m a -> m b -> > m b) instead of (m () -> m b -> m b). It is like automatically ignoring > return values in C. It is too easy to ignore a result that is important. I agree with Henning on forkIO and the like, but I think the current type of (>>) is right. The name of the function is "anonymous bind" (at least that's what I learned), and its whole purpose of existence is to ignore the value of the first computation while maintaining the context. It would be nice if there were greater differentiation between (>>) and (>>=), though. Ideally, (>>) would be changed to something longer than (>>=) to prevent accidental mis-typing (i.e. on the keyboard). Not that I expect much support for this proposal! John

12 25

Re: Proposal #3271: new methods for Data.Sequence
by Louis Wasserman 06 Aug '09

06 Aug '09

Ross, fromList2 takes perhaps 3ms off the time when n=50000. (It is essentially a two-liner, so I consider this acceptable.) Nevertheless, I have slightly improved the performance of the stable heapsort; essentially, when labeling values with their index, the index is left as a lazy thunk, but the computation is organized so computing any index takes O(log n). The speed increase from fromList . Data.List.sort . toList is still but 40% of the speed increase from the heapsort. Again, I'd like to propose a compromise: make Data.Sequence.sortBy cmp be either fromList2 . Data.List.sortBy cmp . toList, or use the stable pairing-heap sort, and add a second sorting method, sortBy', that is unstable but faster. Times (ms) min mean +/-sd median max to/from list: 113.561 119.800 5.470 118.678 139.390 pairing heap: 62.440 67.032 3.861 65.174 80.499 stable pheap: 93.402 102.253 11.854 98.529 158.922 fromList2 . toList: 110.221 118.364 6.525 116.265 136.683 Louis Wasserman wasserman.louis(a)gmail.com

4 6