February 2010 - 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

[darcs patch] filepath: normalise trailing dot
by Conrad Parker 21 Dec '10

21 Dec '10

Hi, the attached darcs patch modifies the behaviour of normalise to handle trailing dots in a path. The previous behaviour yielded this: Prelude System.FilePath> normalise "../." "../." Prelude System.FilePath> normalise ".././" ".././" Prelude System.FilePath> normalise ".././.." "../.." This patch modifies dropDots such that the check for (".":[]) only occurs once for the path, after which a driver function dropDots' is used which skips this check. Hence "." can be removed from the end of a longer path, but a path of just "." is unchanged. (my trac account is pending verification, I'll reply with a trac ticket # later if needed) cheers, Conrad.

4 7

Network library patches
by Neil Mitchell 20 Apr '10

20 Apr '10

Hi I finally got the network library (darcs) building, installing and basically working on Windows with GHC 6.12.1. To do this I set up my environment as follows: 1) Install Cygwin 1.7 (include autoreconf) 2) Install GHC 6.12.1 3) export PATH=/cygdrive/c/ghc/ghc-6.12.1/mingw/bin:$PATH I then did the network steps: 1) Grab network from darcs 2) autoreconf 3) Apply the patch attached, which just changes the .cabal file 4) Change all instances of CALLCONV to stdcall 5) cabal install Please can you apply the attached patch, which should be compatible with Linux/Mac too. I found lots of references to CALLCONV all over the place, but couldn't figure out where it started/ended up - my attempts at #define were rather unsuccessful. Could you please change the logic so Windows gets stdcall as standard? I'm happy to test any patches you come up with. Having a working network library on Windows will be really nice, as it's stopped me upgrading to GHC 6.12.1 for a while now. Thanks, Neil

3 5

Bug in Parsec.Token
by Greg Fitzgerald 04 Mar '10

04 Mar '10

In Text.Parsec.Token, the list of reserved names is not necessarily sorted for case-insensitive languages. When the list of reserved names contains a string with capital letters, the 'identifier' combinator can accept identifiers that conflict with reserved names. Attached are patches for Parsec 2.1 and 3.0. Please let me know if there's anything else I can do to ensure this patch makes it to the next release of the Haskell Platform. Thanks, Greg

6 11

Text.PrettyPrint bug or doc bug
by Marcus D. Gabriel 04 Mar '10

04 Mar '10

Hello, The documentation for Text.PrettyPrint.HughesPJ states that vcat is the "List version of $$", but it works as the list version ($+$). In the source code, this is because vcat = reduceAB . foldr (above_' True) empty instead of vcat = reduceAB . foldr (above_' False) empty So either the documentation needs to be changed or the code. It would be nice to have both versions. Cheers, - Marcus

3 4

Proposed addition to stm: atomicallyIO and afterCommit
by Simon Marlow 25 Feb '10

25 Feb '10

John Lauchbury has proposed the following addition to Control.Concurrent.STM. John's proposal is below, comments welcome. Personally I'm in two minds about this. It certainly captures a useful idiom, but it fails the "don't name compositions" test, and one of the additions is just a renaming of 'return', which makes it hard to justify. Cheers, Simon ----- I find I often write STM code with the structure: do ... IO code ... v <- atomically $ do ... STM code ... if ..... then do ... STM code ... return (Left ...) else do ... STM code ... return (Right ...) case v of Left ... -> ... IO actions ... Right ... -> ... IO actions ... where I have to communicate the result of choices inside STM code to corresponding code in the outer IO monad. This means that two separate parts of the code have to be kept in sync. In this simple case it's merely irritating. With larger and more complex structures it can be quite tricky to keep right. Now I use the functions 'atomicallyIO' and 'afterCommit', and can structure the code as do ... IO code ... v <- atomicallyIO $ do ... STM code ... if ..... then do ... STM code ... afterCommit $ ... IO actions ... else do ... STM code ... afterCommit $ ... IO actions ... As you see, it allows the IO code to be placed in the appropriate part of the STM code, ready to be executed when that STM branch is committed. Here's the code to would be added to the STM module: ---------------------------------------------------------------------- -- 'atomicallyIO' and 'afterCommit' are useful syntactic sugar for a -- simple continuation paradigm. They allow IO code to be placed within -- the same block of STM code in which control decisions are made -- (avoiding the need to communicate those decisions with a data type -- sent to a subsequent matching case). atomicallyIO :: STM (IO a) -> IO a atomicallyIO ioSTM = join $ atomically ioSTM afterCommit :: IO a -> STM (IO a) afterCommit mIO = return mIO ---------------------------------------------------------------------- Obviously the code is very simple, but I still find it useful to name the paradigm, and to have the specific type declarations to catch errors.

4 4

Re: Status of nubOrd (Proposal #2629)
by Gwern Branwen 24 Feb '10

24 Feb '10

On Wed, Feb 24, 2010 at 4:39 PM, Barton C Massey <bart(a)cs.pdx.edu> wrote: > I think in the end everyone agreed that putting nubOrd in > Data.Set (and nubInt in Data.IntSet?) would be a good thing. > I just never got it done; I was burned out by the process, > and I really struggled with getting Darcs to produce a > reasonable-sized patch that could be submitted. That sounds odd. You ask for help in #darcs? > I'll pick it up again if folks want, or someone else can. > I've attached a nubOrd patch I had lying around; it's > against ancient libraries and isn't even a context diff, but > it should be sufficient to reconstruct what needs to be > done. It includes QuickCheck tests and benchmarked as quite > fast IIRC. > Some of the false positives in sort.txt, BTW, will be > because the values often need to be sorted anyway. > In this case, the speed win of nubOrd over > (map head . group . sort) isn't so clear---it probably > depends on the degree of replication in the input list. > Somebody should do some benchmarking, probably. On the > other hand, nubOrd preserves the input ordering, which is > occasionally handy. Looking over the various versions of 'nub' I've collected and my notes, I wonder if we might not be best off with 3 nubs: the current stable Eq, a stable Ord (using Sets), and an unstable Ord. > I have to wonder if some sort of nubOrdWith that uses a > specified equality test wouldn't be a good thing also, Hm. Seems kind of redundant with the Eq typeclass, and I don't think I saw any uses which were equivalent to nubOrdWith. > but I > hate to spend any more time beating on this proposal. > > Bart Massey > bart(a)cs.pdx.edu It just needs someone to take the time to put together a criterion benchmark module and figure out which of the bikesheds are best. It only took a year or so for Control.Monad.void, so no reason we couldn't have faster nubs in the 2011 GHC, -- gwern

1 0

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

darcs patch: Monoid instance for Html
by anotheraddress＠gmx.de 20 Feb '10

20 Feb '10

Thu Feb 18 05:58:09 CET 2010 Daniel Schüssler <daniels(a)community.haskell.org> * Monoid instance for Html Will unfortunately break packages which already define their own instance. Possibly useful for use with things such as HoleyMonoid, though.

3 2