- Libraries - Haskell.org

hackage, package list, trac, some suggestions/questions
by Claus Reinke 07 Jun '08

07 Jun '08

hope this is the right list for hackage issues?-) 1. hackage trac does not seem to have a "register" option (compare hackage trac with ghc trac). individual logins are nice because: - gives individual rather than anonymous reporters - one place less to support spam email harvesters (account name instead of full email address) - "register" is always there, hence easy to find, unlike the hint hidden on the trac home page that hackage is still abusing the haskell' trac.. (i had started this email before i found that hint;-) 2. the hackage package list ought to have a link to an alphabetical index (i often know the package name, but not the likely categories, so i tend to 'search' on that page..). 3. the hackage package list ought to list successful and failed builds (simply a list of compiler versions, each one green or red, depending on success, with direct link to build/ failure log; this would fit into the one-line-per-package format) for each entry, and report them to package authors. build failures currently seem to be created automatically where package authors may not notice them? at least, that would explain things like (just examples of things i happened to have looked at, no offence intended;-) - hint: advertised to work with ghc 6.8.x on the same package page that lists a build failure for ghc-6.8 - haskell-src-exts: lists a build failure for ghc-6.8 the first is probably a too optimistic cabal version spec, the second is a haddock issue. but that makes two out of two for package i looked up recently.. 4. is there an cross-package index of builds/failures, so that one might see trends (cabal issues, base package issues, bytestring issues, next big thing issues,..) and statistics (how many hackage packages fail/build, which compiler/ cabal/haddock versions are successful for the largest number of packages, etc.)? 5. generally, i've always thought that hackage works the wrong way round; instead of yet another push-based place for people to put and forget copies of things, it should work as a pull-based cache: - author registers package, with author/maintainer email and package url - hackage retrieves package, tries to build, and either accepts or not, reporting all to author - occasionally, hackage scans for new versions to be retrieved, again notifying authors of uploads and problem reports - the maintainer email on each hackage package page ought to be (a) protected, not plain text (b) annotated with last successful contact date if i understand #243, authors are not even notified when someone uploads their packages? claus

6 10

type-level integers using type families
by Peter Gavin 04 Jun '08

04 Jun '08

Has anyone else tried implementing type-level integers using type families? I tried using a couple of other type level arithmetic libraries (including type-level on Hackage) and they felt a bit clumsy to use. I started looking at type families and realized I could pretty much build an entire Scheme-like language based on them. In short, I've got addition, subtraction, & multiplication working after just a days worth of hacking. I'm going to post the darcs archive sometime, sooner if anyone's interested. I really like the type-families based approach to this, it's a lot easier to understand, and you can think about things functionally instead of relationally. (Switching back and forth between Prolog-ish thinking and Haskell gets old quick.) Plus you can do type arithmetic directly in place, instead of using type classes everywhere. One thing that I'd like to be able to do is lazy unification on type instances, so that things like data True data False type family Cond x y z type instance Cond True y z = y type instance Cond False y z = z will work if the non-taken branch can't be unified with anything. Is this planned? Is it even feasible? I'm pretty sure it would be possible to implement a Lambda like this, but I'm not seeing it yet. Any ideas? Pete

4 4

Re: type-level integers using type families
by Peter Gavin 31 May '08

31 May '08

Benedikt Huber wrote: >> data True >> data False >> >> type family Cond x y z >> type instance Cond True y z = y >> type instance Cond False y z = z > > I'm not sure if this is what you had in mind, but I also found that e.g. > > > type instance Mod x y = Cond (y :>: x) x (Mod (Sub x y) y) > > won't terminate, as > > > Mod D0 D1 ==> Cond True D0 (Mod (Sub D0 D1) D0) ==> <loop> Right, because it always tries to infer the (Mod (Sub x y) y) part no matter what the result of (y :>: x) is. > > rather than > > > Mod D0 D1 ==> Cond True D0 ? ==> D0 > > For Mod, I used the following (usual) encoding: > > > type family Mod' x y x_gt_y > > type instance Mod' x y False = x > > type instance Mod' x y True = Mod' (Sub x y) y ((Sub x y) :>=: y) > > type family Mod x y > > type instance Mod x y = Mod' x y (x :>=: y) > Yes, it's possible to terminate a loop by matching the type argument directly. > 1) One cannot define type equality (unless total type families become > available), i.e. use the overlapping instances trick: >> instance Eq e e True >> instance Eq e e' False I didn't want to mix type classes and families in my implementation. All the predicates are implemented like so: > type family Eq x y > type instance Eq D0 D0 = True > type instance Eq D1 D1 = True ... > type instance Eq (xh :* xl) (yh :* yl) = And (Eq xl yl) (Eq xh yh) then I've added a single type-class > class Require b > instance Require True so you can do stuff like > f :: (Require (Eq (x :+: y) z)) => x -> y -> z or whatever. I haven't yet tested it (but I think it should work) :) Pete > > Consequently, all type-level functions which depend on type equality > (see HList) need to be encoded using type classes. > > 2) One cannot use superclass contexts to derive instances e.g. to define >> instance Succ (s,s') => Pred (s',s) > > In constrast, when using MPTC + FD, one can establish more than one TL > function in one definition > > > class Succ x x' | x -> x', x' -> x > > 3) Not sure if this is a problem in general, but I think you cannot > restrict the set of type family instances easily. > > E.g., if you have an instance > > > type instance Mod10 (x :* D0) = D0 > > then you also have > > > Mod10 (FooBar :* D0) ~ D0 > > What would be nice is something like > > > type instance (IsPos x) => Mod10 (x :* D0) = D0 > > though > > > type family AssertThen b x > > type instance AssertThen True x = x > > type instance Mod10 (x :* D0) = AssertThen (IsPos x) D0 > > seems to work as well. > > 4) Not really a limitation, but if you want to use instance methods of > Nat or Bool (e.g. toBool) on the callee site, you have to provide > context that the type level functions are closed w.r.t. to the type class: > >> test_1a :: forall a b b1 b2 b3. >> (b1 ~ And a b, >> b2 ~ Not (Or a b), >> b3 ~ Or b1 b2, >> Bool b3) => a -> b -> Prelude.Bool >> test_1a a b = toBool (undefined :: b3) > > Actually, I think the 'a ~ b' syntax is very nice. > > I'm really looking forward to type families. > > best regards, > > benedikt

1 0

System.Posix.Temp
by Peter Gammie 30 May '08

30 May '08

The docs for mkstemp are somewhat short. (One must add XXXXXX to the end of the template for things to go, and probably prepend a path as well.) Apparently it is better to use tmpfile(3) now. How difficult would it be to provide that function as well? (Note the return type is FILE *.) cheers pete -- http://peteg.org/

1 0

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

30 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 22 May '08

22 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