February 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

NFData
by Sittampalam, Ganesh 20 Apr '09

20 Apr '09

Hi, NFData seems to be the "standard" deepseq-style class these days, but it lives in Control.Parallel.Strategies in the parallel package whereas it obviously has uses beyond this. Is there a case for moving it into its own package and module? I'd also like to add something like strictly :: (Monad m, NFData a) => m a -> m a strictly ma = do a <- ma rnf a `seq` return a The most important use for this would be to provide a standard way to do strict IO: strictly $ readFile "..." strictly $ hGetContents ... Thoughts? Cheers, Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================

4 5

randomIO causing stack overflow ?
by timtoorop＠quicknet.nl 02 Mar '09

02 Mar '09

Hi, I was just messing with randomIO for no particular reason, and it suddenly caused a stack overflow which would only go away after restarting ghci. Here's what I see in ghci 6.8.2 http://moonpatio.com/fastcgi/hpaste.fcgi/view?id=1642 mmorrow posted the same using ghci 6.10.1 which gave the same stack overflow Anyone got any idea what causes this funny behavior? - Tim

3 2

Foldable and Traversable vs. FunctorM
by Henning Thielemann 01 Mar '09

01 Mar '09

After writing some FunctorM instance for GHC-6.4, then converting them to Traversable instances for GHC-6.8, I found that most of the time, if not always, I actually needed a FunctorM instance (i.e. fmapM method), not a Traversable instance. Defining a Traversable instance requires me to also define a Foldable instance, i.e. a foldMap function. I had trees, lists and singletons extended by additional information, e.g. data PositionList a = PositionList [(Position, a)] data AsyncException e a = AsyncException (Maybe e) a However 'foldMap' cannot utilize the additional information, namely Position and (Maybe e), respectively. In the first case this is sad, in the second case I consider this bad, since it is too easy to throw away and thus ignore the exception (Maybe e). Some kind of fold is always useful on these structures, but 'foldMap' is too limited. For Traversable there is always both sequence and mapM (and their Applicative counterparts), although you need to define only one of them. However 'sequence' works on interim data structures that are not very natural. Imagine a data structure with a 'string' parameter that is intended for instantiation by String or ByteString. Now 'sequence' requires instantiations like (IO String) or (State s ByteString) which do not share common properties of String and ByteString, e.g. having a 'length' function. Although possible, those interim types look inappropriate to me. Even more, consider a data structure like StorableVector which requires certain properties of its elements. StorableVector is intended for Int, Double and other Storable types, but you cannot store (IO Double) values. This example is not practical, because the Storable restriction disallows to define both Traversable and FunctorM instances. However you see, that one cannot even imagine 'sequence' on StorableVector, whereas 'mapM' is possible, yet very inefficient (needs copying the entire vector for each added element). My conclusion is, that FunctorM was better than its reputation, and that Traversable as it is, is not what I need most of the time. What are the experiences of other Traversable users?

2 2