January 2009 - Libraries

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

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

template-haskell depends on packedstring
by Gwern Branwen 18 May '09

18 May '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 So I was trying to compile lambdabot with cabal-install. Lambdabot uses Template Haskell for generating some boilerplate, and it was a failed dependency. Template Haskell uses packedstring for... something... and packedstring was a failed dependency: Data/PackedString.hs:83:7: Could not find module `Data.Data': it is a member of package base, which is hidden Now this is a problem, but it's not the problem I am interested in. I am interested in: why is template-haskell using packedstring? Wasn't packedstring obsoleted years ago? I downloaded the TH tarball to see what fascinating things it was using packedstring for, and I found that it's hardly doing anything - it apparently is just encoding module (ModName) and OccName (whatever that is), and then the other functions shift back from PackedString/ModName-OccName to String. (This is all in Language/Haskell/TH/Syntax.hs) I replaced all the PackedString stuff with normal ol' String and compiled fine, and indeed seems to work fine at Template-Haskelly stuff. So here's my suggestions: 1) Remove the packedstring dep and calls from the TH code. It is useless, it shackles the package to a long obsolete one, and so on. Even if we assume that the packedstring code is still faster than native String, and that there's no performance penalty for the conversions back and forth from String to PackedString, and that the possible size increase from linking in PackedString code is not worth worrying about, and we also assume that PackedString is being used on Names large enough to make up for any overhead - even if we assume all that, TH is a compile-time process and so it doesn't matter all that much if we shave a few microseconds off one small part of the compilation process. Installability and cleaner code would be worth that price. 2) If just String is not acceptable, then I understand from dons that the reason we can't use just plain ol' ByteString is because the Names may well be in UTF-8, and ByteString's [Word8]s apparently don't treat that well. Given that, we need some sort of UTF8 bytestring. As it happens, we do in fact have such a thing: Data.ByteString.UTF8 . It looks a bit incomplete, but utf8-string in general is pretty widely-used and reliable (also builds on 6.10): just about every XMonad user uses XMonadContrib which uses utf8-string, and I can count the number of complaints because utf8-string on one hand. Thoughts? I searched thoroughly through various bug-trackers and mailing lists, but this doesn't seem to've come up before. - -- gwern -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREKAAYFAkkqJTsACgkQvpDo5Pfl1oLYoQCgjRSqno+DtyZiLbAS5Pk4l8Ao sqkAn15sBq+alBy5ZVLHIMthjZ6eU6E6 =N8Qj -----END PGP SIGNATURE-----

3 6

[network] #4: sIsReadable and sIsWritable return true after socket is closed.
by network 13 May '09

13 May '09

#4: sIsReadable and sIsWritable return true after socket is closed. ---------------------+------------------------------------------------------ Reporter: igloo | Owner: Type: defect | Status: new Priority: major | Milestone: Component: network | Version: Keywords: | ---------------------+------------------------------------------------------ First reported here: http://hackage.haskell.org/trac/ghc/ticket/2774 ---- {{{ > import Network.Socket > s <- socket AF_INET Stream 6 Loading package parsec-2.1.0.1 ... linking ... done. Loading package network-2.2.0.1 ... linking ... done. > bindSocket s (SockAddrInet 0 0) > listen s 1 > sClose s > sIsReadable s True > sIsWritable s True }}} sIsReadable and sIsWritable return true when the !SocketStatus is Connected or Listening. sClose does not change the status. Perhaps a new status Closed should be added to !SocketStatus. -- Ticket URL: <http://trac.haskell.org/network/ticket/4> network <http://projects.haskell.org/network/> Networking-related facilities

1 1

[network] #5: getAddrInfo and addrFamily not in scope on Windows GHC 6.8
by network 13 May '09

13 May '09

#5: getAddrInfo and addrFamily not in scope on Windows GHC 6.8 ---------------------+------------------------------------------------------ Reporter: igloo | Owner: Type: defect | Status: new Priority: major | Milestone: Component: network | Version: Keywords: | ---------------------+------------------------------------------------------ Originally reported here: http://hackage.haskell.org/trac/ghc/ticket/2726 ---- import Network.Socket ... getAddrInfo ... addrFamily -- gives me not in scope on Windows. The same code works on Unix. ---- Looking at the code, these are only available if `IPV6_SOCKET_SUPPORT` is defined. I don't know more than that off the top of my head. -- Ticket URL: <http://trac.haskell.org/network/ticket/5> network <http://projects.haskell.org/network/> Networking-related facilities

1 2

[network] #1: unpackFamily on Windows fails match
by network 13 May '09

13 May '09

#1: unpackFamily on Windows fails match ------------------------+--------------------------------------------------- Reporter: igloo | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: component1 | Version: Keywords: | ------------------------+--------------------------------------------------- Initially reported here: http://hackage.haskell.org/trac/ghc/ticket/2250 ---- In the HostEntry returned by Network.BSD.getHostByName, evaluating the hostFamily field causes the following error, which is pointing at the unpackFamily function: {{{ *** Exception: Network/Socket.hsc:(1711,17)-(1777,13): Non-exhaustive patterns in case }}} This occurs with 6.8.2 and 6.9.20080323 i386. The machine is running Windows Server 2008 x64. ---- I modified Network/BSD.hs to trace out the h_addrtype variable in Storable `HostEntry`'s peek, and it had the value 0x40002. The corresponding variable in the C struct should be a short, but is inferred to be CInt in the Haskell source, probably thanks to unpackFamily having type CInt -> Family. Due to that, it reads the family as an int, consuming the following length field as well. I hacked past this by giving the peek of h_addrtype an annotation of ":: IO CShort" and adding a fromIntegral at the call to unpackFamily to convert it to the CInt that the unpackFamily function expects. ---- Great stuff, thanks! It looks like it should be `CSaFamily` rather than `CInt`. Likewise `packFamily`, and I expect the whole library could do with an audit. ---- I can reproduce the exact bug on the following combinations: - GHC 6.8.2, x86, Windows XP - GHC 6.8.3, x86, Windows XP - GHC 6.8.2, x86, Windows Vista - GHC 6.8.3, x86, Windows Vista - GHC 6.8.2, x64, Windows Vista - GHC 6.8.3, x64, Windows Vista -- Ticket URL: <http://trac.haskell.org/network/ticket/1> network <http://projects.haskell.org/network/> Networking-related facilities

1 7

Binary: Put -> Builder
by Henning Thielemann 12 Feb '09

12 Feb '09

Is there a way to get the underlying Builder of a 'put' of a Binary instance? How does the Char instance of Binary serialize?

7 14

Proposal for Data.List.splitBy
by Marcus D. Gabriel 10 Feb '09

10 Feb '09

We seem to have not added any splitters such as splitBy or split to Data.List despite the discussions. Here is yet another perspective with the hope that it will make it. For the record, see the threads * http://www.haskell.org/pipermail/libraries/2004-July/thread.html#2342 * http://www.haskell.org/pipermail/haskell-cafe/2006-July/thread.html#16559 * http://www.haskell.org/pipermail/libraries/2008-January/thread.html#8922 see the article * http://www.haskell.org/pipermail/libraries/2006-October/006072.html and see the wiki page * http://haskell.org/haskellwiki/List_function_suggestions Essentially, I believe that the difficulty in choosing a splitter for Data.List comes from the fact that it does not take much of a problem to solve before a simple splitter is just not enough whereupon you should just use a FSM, Alex, or Parsec for example. A way forward would be to state a few meta-properties and properties up front and then see if this leads to a reasonable solution for the simple problems that just need a solution that is "good enough." I would suggest that 1. a set of splitter words should be small in number, 2. such a set should fit within the spirit of the List module of the Haskell 98 standard libraries, 3. it should pick up where break and span left off, and 4. the results coming from this set of splitter words should be unsplittable. I would argue that the above suggestions imply at least two words * splitBy :: (a -> Bool) -> [a] -> [([a], [a])] and * split :: [a] -> [a] -> [([a], [a])] such that splitBy takes a predicate p, e.g., (=='\n'), and a list xs and such that split takes a list of equivalent delimiters ds, e.g., " \t", and a list xs. The functions splitBy and split should at least have the follow properites. > (concatMap (\(x1, x2) -> x1 ++ x2) $ splitBy p xs) == xs > splitBy _ [] == [([],[])] > splitBy (\x -> False) xs == [(xs,[])] > splitBy (\x -> True) xs == [([],[x1]),([],[x2]),([],[x3]), ...] and > (concatMap (\(x1, x2) -> x1 ++ x2) $ split ds xs) == xs > split _ [] == [([],[])] > split [] xs == [(xs,[])] > split xs xs == [([],[x1]),([],[x2]), ([],[x3]), ...] where xs == x1:x2:x2:...:[]. Examples would be > splitBy (=='/') "/a/b" == [("","/"),("a","/"),("b","")] > splitBy (=='/') "//aa//bb" == > [("","/"),("","/"),("aa","/"),("","/"),("bb","")] > splitBy (=='\n') "\na\nb" == [("","\n"),("a","\n"),("b","")] > split xs xs == [([],[x1]),([],[x2]), ([],[x3]), ...] > split " \t" "a\tb \tc\t d " == > [("a","\t"),("b"," "),("","\t"),("c","\t"),(""," "),("d"," ")] > split "/" "/a/b" == [("","/"),("a","/"),("b","")] This leaves the one remaining "simple" case which is splitting using a list such as "\r\n" which splitBy and split cannot handle easily. This leads to * splitUsing :: (Eq a) => [a] -> [a] -> [([a], [a])] such that > (concatMap (\(x1, x2) -> x1 ++ x2) $ splitUsing xs xs') == xs' > splitUsing _ [] == [([] , [])] > splitUsing [] xs == [(xs , [])] > splitUsing xs xs == [([] , xs)] Examples would be > splitUsing "\r\n" "a" == [("a", "")] > splitUsing "\r\n" "\r\n" == [("" , "\r\n")] > splitUsing "\r\n" "a\r\n" == [("a", "\r\n")] > splitUsing "\r\n" "a\r\n\r\n" == [("a", "\r\n"), ("" , "\r\n")] > splitUsing "\r\n" "a\r\nb" == [("a", "\r\n"), ("b", "")] > splitUsing "\r\n" "a\r\nb\r\n" == [("a", "\r\n"), ("b", "\r\n")] Wrapping up, based on a sort of logical extension, you could imagine * splitWhere :: ([a] -> Bool) -> [a] -> [([a], [a])] but I believe that this fourth word is one too many, cute, but not necessary. If the above three splitter words are not enough, then I would say that you need a more powerful tool beyond the spirit of the Haskell 98 standard List module. Just to check, the Haskell 98 List.lines function would be defined as > lines98 xs = map fst $ split "\n" xs and proper lines' and unlines' functions would be > lines' :: String -> Either [String] [String] > lines' [] = Left [] > lines' xs = > let res = split "\n" xs > nul = (null.snd.last) res > in (if nul then Left else Right) $ map fst res > > unlines' :: Either [String] [String] -> String > unlines' exss = intercalate "\n" $ either (id) (++[[]]) exss such that > unlines' . lines' == id This is to say, (Right [String]) if the original xs ends in '\n' and (Left [String]) if it does not. For your review, the attached file Split.hs defines and documents splitBy, split, splitUsing, and splitWhere, and the attached file SplitProperties.hs defines tests for these same words. Finally, I would propose adding splitBy, split, and splitUsing to Data.List as three words that fit within the spirit of the Haskell 98 List module, take off where break and span leave off, are unsplittable, and are "good enough". Cheers, - Marcus -- Marcus D. Gabriel, Ph.D. Saint Louis, FRANCE http://www.marcus.gabriel.name mailto:marcus@gabriel.name Tel: +33.3.89.69.05.06 Portable: +33.6.34.56.07.75

7 21

Bug in Cabal?
by Dominic Steinitz 05 Feb '09

05 Feb '09

I couldn't seem to logon to the trac to report this. I'm working on windows (not linux as the chmod might suggest). zlib-0.5.0.0>runghc Setup.hs configure --package-db=..\..\ghc\ghc-6.10.1\fpf.package.conf --docdir=..\..\haskell_packages\doc\zlib-0.5.0.0 --libdir=..\..\haskell_packages --bindir=..\..\haskell_packages\bin Configuring zlib-0.5.0.0... zlib-0.5.0.0>runghc Setup.hs build Preprocessing library zlib-0.5.0.0... Building zlib-0.5.0.0... ghc-6.10.1\bin\ar.exe: creating dist\build\libHSzlib-0.5.0.0.a zlib-0.5.0.0>runghc Setup.hs install Setup.hs: ..\..\haskell_packages\doc\zlib-0.5.0.0\.copyFile920.tmp: copyFile: permission denied (Access is denied.) Cabal seesm to create certain things as read only. I can work around this by chmod a+w ..\ThirdParty\haskell_packages\zlib-0.5.0.0\ghc-6.10.1\include\* chmod a+w ..\ThirdParty\haskell_packages\doc\zlib-0.5.0.0\* rm ..\ThirdParty\haskell_packages\doc\zlib-0.5.0.0\* I suspect most people haven't tripped over this as once something is installed they don't tend to install it again. Dominic.

3 10