April 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

Bug in old-locale?
by Deniz Dogan 11 Jul '09

11 Jul '09

Hi Is there a bug in the old-locale package? I tried the following simple program: import Data.Time import System.Locale main = do time <- getCurrentTime putStrLn $ formatTime defaultTimeLocale rfc822DateFormat time The above program prints: Mon, d Apr 2009 15:23:56 UTC Notice "Mon, d", where "d" should be the day of the month. Looking at the source code in the package, I see: rfc822DateFormat = "%a, %_d %b %Y %H:%M:%S %Z" So what's up with %_d? -- Deniz Dogan

4 6

cabal: confusing dependencies conflict between ghc-6.10.1 and process
by Sebastian Fischer 29 May '09

29 May '09

Hello, I get a confusing message when trying to install 'vacuum' from Hackage: $ cabal install vacuum Resolving dependencies... cabal: dependencies conflict: ghc-6.10.1 requires process ==1.0.1.1 however process-1.0.1.1 was excluded because ghc-6.10.1 requires process ==1.0.1.0 There is something wrong: according to this message, the package ghc-6.10.1 requires both process==1.0.1.1 and process==1.0.1.0. According to ghc-pkg, the package ghc-6.10.1 requires process==1.0.1.0: $ ghc-pkg describe ghc name: ghc version: 6.10.1 [...] depends: Cabal-1.6.0.1 array-0.2.0.0 base-4.0.0.0 bytestring-0.9.1.4 containers-0.2.0.0 directory-1.0.0.2 editline-0.2.1.0 filepath-1.1.0.1 haskell98-1.0.1.0 hpc-0.5.0.2 old-time-1.0.0.1 process-1.0.1.0 template-haskell-2.3.0.0 unix-2.3.1.0 [...] Why does cabal think that ghc-6.10.1 requires process==1.0.1.1? I use $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.10.1 $ cabal --version cabal-install version 0.6.2 using version 1.6.0.2 of the Cabal library Is it a problem that cabal uses version 1.6.0.2 of the Cabala library but the package ghc-6.10.1 requires version 1.6.0.1? Cheers, Sebastian

3 4

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

Eliminate/move class Alternative
by Ben Franksen 04 May '09

04 May '09

Hi, I propose to remove class Alternative and functions depending on it (optional, some, and many) from Control.Applicative. They can be moved into a separate module Control.Alternative if people desire such a class, but I doubt that it has many useful applications, at least in its present form. Rationale: Although the idea behind Alternative, i.e. generalize some of the functions commonly found in parser combinator libs, is a nice one, it doesn't work too well in practice, /even/ for the case that has inspired it (namely parsers). This is mostly due to the class method 'empty'. First of all, this is a bad name, /especially/ in the context of parsers, where 'empty' intuitively means 'recognize the empty sequence of tokens' which is definitely /not/ what Alternative's 'empty' means. (Indeed, this is normally be the meaning of 'pure' from class Applicative.) The 'empty' from Alternative rather means 'fail'. Yeah, I know that this name is already taken by class Monad. Many names would be better than 'empty', for instance 'none', or just 'failed'. (I'll stick with 'none' in what follows.) Second, and more important, is that some parser libs would like to, but cannot offer a sensible implementation for it. For instance, any error-correcting library of parser combinators (like those invented by Swierstra & Duponcheel) need to construct a valid result even in case of a failed parse. Thus, the user must be able to pass an argument to 'none' which would be possible only if it had a function type, like in class Alternative f where ... none :: a -> f a However, even this wouldn't be enough in practice because typically you will want to pass additional data, like an error message. How this can be properly generalized is something that needs more thought. Some of you might be tempted to say "if you don't like Alternative, just don't use it". However, not using it means additional effort, as I /would/ like to use class Applicative /and/ the <|> operator with its intended meaning, i.e. choice/alternative, and also the dependent functions (optional, many, etc). So currently I have to explicitly hide all the Alternative stuff, like this import Control.Applicative hiding (Alternative(..),optional,some,many) which is not nice at all. As a final point, class Alternative comes with no stated laws. While there are a number of standard classes where laws don't make much sense (like, e.g. Show, or Typeable), this is clearly not one of those cases: The docs say Alternative is "a monoid on applicative functors". This suggests associativity and left/right unit laws. However, this is most probably not the whole story, i.e. how are <|> and the ill-named 'empty' supposed to interact with the operations and laws for Applicative? Are we going to have the same dilemma here, as with MonadPlus vs. MonadZero/MonadOr, whatever? Conclusion: In its current form, class Alternative looks like it has been hastily cobbled together. Thus it has no place in Control.Applicative. Moving it into its own separate module is the least we can do. Cheers Ben

5 6