May 2008 - Libraries - Haskell.org

Proposal #2316: Add Applicative instances for all MTL Monads
by Spencer Janssen 29 May '08

29 May '08

This proposal is very straightforward: add Applicative instances for all the Monads in the MTL. Deadline for discussion is two weeks from today, June 12 2008. Cheers, Spencer Janssen

6 8

darcs patch: Better handling of the vararg el_get function
by Judah Jacobson 29 May '08

29 May '08

The following patch fixes the issue reported today in: http://www.haskell.org/pipermail/glasgow-haskell-users/2008-May/014801.html Mon May 26 11:01:19 PDT 2008 Judah Jacobson <judah.jacobson(a)gmail.com> * Better handling of the vararg el_get function. M ./System/Console/Editline.hsc -2 +2 M ./cbits/HsEditline.c +4 M ./include/HsEditline.h -2 +1

2 1

Re: [Haskell-cafe] library for drawing charts
by Peter Gammie 29 May '08

29 May '08

Tim, Thanks for the pointer. Just to clarify: On 26/05/2008, at 9:09 AM, Tim Docker wrote: >> I'd like 2D pie charts, bar charts and something like a google-o- >> meter. > > An the moment it does line charts and a few variants of these. I'll > add > pie and bar charts when I need them - patches in the meantime > gratefully > accepted. So the library itself supports drawing these other types of charts? Can you steer me towards some sample outputs? One thing I was most unhappy to discover was the lack of Unicode support in Google charts. Another is the lack of control over some colours (the arrow in the google-o-meter, e.g.) and labelling. When one wants to build an accessible website, these things end up breaking the deal. BTW Bjorn has written a binding to libgd. Does Cairo have similar functionality, e.g. quizzing an image file for geometry info? cheers peter

2 2

the Network.URI parser
by Peter Gammie 27 May '08

27 May '08

Hello, I'm wondering what the state of this parser is. It parses the contents of the src attribute in the following: <p><img src="javascript:alert('XSS');" alt=""/></p> which causes IE 5.5 (and probably 6) to show a dialog box. (I lifted this example from the list at http://ha.ckers.org/xss.html) I was hoping the parser in Network.URI would choke on it - the parentheses are reserved, at least. cheers peter

3 5

IntSet.findMax generates garbage
by Scott Dillard 23 May '08

23 May '08

Hi, I noticed IntSet.findMax is defined (more or less) as "fst . maxView", but maxView allocates thunks on its way down to the max leaf, only to have findMax throw them away. Same for IntMap. I wrote a patch to fix this. I didn't test it for speed (couldn't think of a good test. I did test for correctness.) However, I looked at the core and the old version did indeed have "let"s in the loop. The new version does not. Also I changed the API a bit. Previously, IntMap.findMin only returned the bound value, not the key. Data.Map returns the pair, so I changed IntMap to do the same. (This seems like common sense to me.) Patch is attached. Can you tell I'm using this library a lot lately? Scott

4 7

Linear time IntSet / IntMap construction from sorted input
by Scott Dillard 21 May '08

21 May '08

Hi, It's always bugged me that IntSet.fromAscList is an alias for fromList, which is basically (foldr insert), even though a sorted list is (almost) already in tree order. Is there a reason for this? Or was it just that fromList is good enough? (which it is.) Assuming the latter, and somewhat bored, I wrote a function to build an IntSet from sorted input in linear time. This goes in Data.IntSet.hs : data Stack = Push {-# UNPACK #-} !Prefix !IntSet !Stack | Nada fromAsc xs = make Nada xs where make stk [] = finish stk make Nada (z:zs) = make (Push z (Tip z) Nada) zs make stk@(Push _ y Nada) (z:zs) = make (Push z (Tip z) stk) zs make stk@(Push py y stk') zs@(z:zs') = make (Push z (Tip z) (reduce (branchMask py z) stk)) zs' reduce _ stk@(Push _ x Nada) = stk reduce m stk@((Push px x (Push py y stk'))) = let !mxy = branchMask px py !pxy = mask px mxy in if shorter m mxy then reduce m (Push pxy (Bin pxy mxy y x) stk') else stk finish Nada = Nil finish (Push _ x Nada) = x finish (Push px x (Push py y stk)) = finish (Push p (join px x py y) stk) where m = branchMask px py p = mask px m Every trie node is allocated exactly once, and so the burden on the heap is significantly less, even if its only a little bit faster. I tested it by building a list from -n to n for big n, and computing the sum. It alloc's 50% less and the MUT time is like 40% less, but the GC time is more (why would that be?) so it runs in maybe 7/8ths the time, versus fromList. I have another, prettier version that uses [] instead of this hacky Stack type, but its slower, breaking even with fromList on speed, still allocating much less. Is this something you guys feel would be worth including? Should I make a proper patch? One could even use this to write an O(n) mapKeysMonotonic, bringing the IntMap and Map APIs further into alignment. Or is 8/7x speedup not worth the extra code weight? Scott

2 3

building a helper binary with cabal
by Evan Martin 17 May '08

17 May '08

[resent after subscribing to the list] I'm working on a package that requires building a helper binary as part of its install process. This binary is written in C (with good reason), and on a Debian system would be installed into a path like /usr/lib/myproject/mybinary, because it's only used internally by the main program binary. My setup is up to this point: > gccProgram :: Program > gccProgram = simpleProgram "gcc" > type BuildHook = PackageDescription -> LocalBuildInfo > -> UserHooks -> BuildFlags -> IO () > creplChildBuild :: BuildHook -> BuildHook > creplChildBuild oldhook desc buildinfo hooks flags = do > oldhook desc buildinfo hooks flags > rawSystemProgramConf (buildVerbose flags) gccProgram (buildPrograms flags) > ["child.c", "-o", buildDir buildinfo </> "child", "-ldl"] > buildHooks = simpleUserHooks { > hookedPrograms = [gccProgram], > buildHook = creplChildBuild (buildHook simpleUserHooks) > } > main = defaultMainWithHooks buildHooks However, it's unclear to me how to set up the install rule that would copy that binary into the appropriate place. Any tips? It seems I want to grab the "install" hook, but from there how do I specify where to install the file? There seem to be no helper functions to facilitate installing. (I appreciate that all of this is pretty new. So if it's not possible for me to do what I want, take it as an example of the sort of thing I'd like for Cabal to support...)

2 8

IntMap intersectionWith type is too restrictive
by Scott Dillard 16 May '08

16 May '08

Hi, This is a simple bug report, more or less. The type of Data.IntMap.intersectionWith is too restrictive. Presently (GHC 8.2, http://darcs.haskell.org/packages/containers/Data/) it's declared as (a->b->a) -> IntMap a -> IntMap b -> IntMap a, but if you just remove the type declarations it's inferred as (a->b->c) -> IntMap a -> IntMap b -> IntMap c. Similarly for intersectionWithKey. The more general a->b->c type is also the type of Data.Map.intersectionWith, and it's quite useful, such as (intersectionWith (,)) Scott

2 3

Proposal/Idea: Split up base even further
by Twan van Laarhoven 16 May '08

16 May '08

Hello librarians, Here is an idea to resolve some of the problems that remain with the base package: The problem: Users can not update their version of the 'base' package, since it is tied to Ghc. If a useful new function is added using it requires updating the compiler. On the one hand this puts people off using these new functions. On the other hand it also makes updates to for instance Data.List take way longer to reach the users because we have to wait for the next Ghc release. The proposal: User code should NEVER import the library that is now called 'base', it should provide an internal API only. For example, base can include the modules Internal.Data.List Internal.Control.Monad Internal.IO etc. Which are as minimal and low level as possible, containing just the things that Ghc RELIES on like: - type classes for which instances can be derived (Eq, Ord, etc.) - data types and classes with syntactic sugar (Bool, [], Num, Monad) - low level stuff like IO and ST and primitives In short, everything that is now under Ghc.*, and hopefully less, becomes the new base library. In my opinion half of that can still be moved out, like most of Ghc.List, Ghc.Enum, Ghc.IO and Ghc.Read. The next layer can then consist of many packages like "containers", "control", "numeric", "concurrent", "ioref", "file-io", "foreign", etc. For example the Data.List module imports Internal.Data.List for the basic list data type. It re-exports this, and adds many additional functions that don't belong in the minimal base library. Thoughts? Twan

2 1

Data.Time questions
by Bjorn Buckwalter 13 May '08

13 May '08

Dear all, I've implemented 'ParseTime' and 'Read' instances for 'AbsoluteTime'. Before submitting a patch I want to confirm with you that they belong in 'Data.Time.Format.Parse' as opposed to 'Data.Time.Clock.TAI'. Is this correct? I'm doing work on additional time coordinates of interest to e.g. astrodynamicists. In particular Terrestrial Time (TT = TAI + 32.184 seconds, previously known as Terrestrial Dynamical Time or TDT) and perhaps Geocentric Coordinate Time (TCG) and others. Would you be interested in receiving patches with these rather esoteric time coordinates? If not I'll release them in a new "time-astro" package. Thanks, Bjorn Buckwalter

3 6