- Libraries - Haskell.org

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 14 May '08

14 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

Specifying dependencies on Haskell code
by Duncan Coutts 12 May '08

12 May '08

All, In the initial discussions on a common architecture for building applications and libraries one of the goals was to reduce or eliminate untracked dependencies. The aim being that you could reliably deploy a package from one machine to another. We settled on a fairly traditional model, where one specifies the names and versions of packages of Haskell code. An obvious alternative model is embodied in ghc --make and in autoconf style systems where you look in the environment not for packages but rather for specific modules or functions. Both models have passionate advocates. There are of course advantages and disadvantages to each. Both models seem to get implemented as reactions having the other model inflicted on the author. For example the current Cabal model of package names and versions was a reaction to the perceived problem of untracked dependencies with the ghc --make system. One could see implementations such as searchpath and franchise as reactions in the opposite direction. The advantages and disadvantages of specifying dependencies on module names vs package names and versions are mostly inverses. Module name clashes between packages are problematic with one system and not a problem with the other. Moving modules between packages is not a problem for one system and a massive pain for the other. The fact is that both module name and package name + version are being used as proxies to represent some vague combination of required Haskell interface and implementation thereof. Sometimes people intend only to specify an interface and sometimes people really want to specify (partial) semantics (eg to require a version of something including some bug fix / semantic change). In this situation the package version is being used to specify an implementation as a proxy for semantics. Neither are very good ways of identifying an interface or implementation/semantics. Modules do move from one package to another without fundamentally changing. Modules do change interface and semantics without changing name. There is no guarantee about the relationship between a package's version and its interface or semantics though there are some conventions. Another view would be to try and identify the requirements about dependent code more accurately. For example to view modules as functors and look at what interface they require of the modules they import. Then we can say that they depend on any module that provides a superset of that interface. It doesn't help with semantics of course. Dependencies like these are not so compact and easy to write down. I don't have any point here exactly, except that there is no obvious solution. I guess I'd like to provoke a bit of a discussion on this, though hopefully not just rehashing known issues. In particular if people have any ideas about how we could improve either model to address their weak points then that'd be well worth discussing. For example the package versioning policy attempts to tighten the relationship between a package version and changes in its interface and semantics. It still does not help at all with modules moving between packages. Duncan

7 17

Re: [Haskell-cafe] ANN: unix-2.4.0.0 additional POSIX real time support
by Don Stewart 10 May '08

10 May '08

vigalchin: > so Don you are saying that mqueue and RTsched I should put on Hackage to > avoid putting in the Unix package? Vis-a-vis fsync and fdatasync I have no > choice .. they both IMO belong in Files.hsc. Right, there are two options: 1) put it in a new package. unix-extensions or 2) submit it as a patch to the libraries(a)haskell.org mailing list, and it can be put in the main 'unix' darcs repository, which then gets uploaded to hackage in the next release cycle. It's currently a bug that anyone can (accidentally) release their own versions of the core libraries. Cheers, Don

6 10

Patch: fixed typo in base modules comments
by Andriy Palamarchuk 10 May '08

10 May '08

Replaced "iff" with "if". Please apply. Andriy ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

3 2