November 2009 - Libraries

Proposal #3339: Add (+>) as a synonym for mappend
by Bryan O'Sullivan 08 Nov '11

08 Nov '11

Ticket: http://hackage.haskell.org/trac/ghc/ticket/3339 >From the ticket: This proposal was, I think, originally suggested by Jules Bean. The idea is to add two functions to the Data.Monoid module, (+>) and (<+), corresponding to different uses of mappend. These should not be methods of the Monoidtypeclass, but top-level functions. I hope (but slightly doubt) that the visual nature of the two operators might help to counter the thought that monoids are just for gluing things together. (+>) :: (Monoid a) => a -> a -> a a +> b = a `mappend` b (<+) :: (Monoid a) => a -> a -> a a <+ b = b `mappend` a infixl 4 +> infixl 4 <+ Proposed deadline: two weeks. If this looks reasonable, I'll attach darcs patches.

30 75

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

Bug in Parsec.Token
by Greg Fitzgerald 04 Mar '10

04 Mar '10

In Text.Parsec.Token, the list of reserved names is not necessarily sorted for case-insensitive languages. When the list of reserved names contains a string with capital letters, the 'identifier' combinator can accept identifiers that conflict with reserved names. Attached are patches for Parsec 2.1 and 3.0. Please let me know if there's anything else I can do to ensure this patch makes it to the next release of the Haskell Platform. Thanks, Greg

6 11

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

Adding an ignore function to Control.Monad
by Gwern Branwen 12 Jan '10

12 Jan '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 So while writing my wp-archivebot, I ran into the issue that forkIO requires IO () but returns IO ThreadId, and that many useful IO functions will return IO a instead of IO (). This forces some awkward contortions. Suppose I want to ping the WebCite website at a particular address, and this request makes WebCite archive a URL embedded in that address. Presumably I could venture into the depths of Network.HTTP to figure out how to ping an URL without also pulling down the server's HTML, but why do that when I already have obviously 'openURL :: String -> IO String'? Much easier to do something like 'openURL "webcite.org" ++ foo ++ "other stuff" '. But my bot needs to handle quite a few URLs; one at a time, what with all the waits and timeouts, isn't going to hack it. So for a given link, I forkIO the openURL request. But of course, forkIO demands IO (), so I toss in a '>> return ()'. Fair enough. So I examine the performance, and it's still too slow. Recent Changes has hundreds of different pages a minute. I'd better fork each page (and then fork for each link). But wait, all those forkIOs are returning IO ThreadIds, and my top-level forkIO call demands IO ()... So another >> return (). At this point, the code is starting to look pretty silly - something like '...stuff >> return ()) >> return ())'. So I see the repeated pattern, and by the rule of 3, factor it out to: - -- | Convenience function. 'forkIO' and 'forM_' demand return types of 'IO ()', but most interesting - -- IO functions don't return void. So one adds a call to 'return ()'; this just factors it out. ignore ∷ (Monad m) ⇒ m a → m () ignore x = x >> return () Not the most complex convenience function I've ever written, but not any simpler than, say Control.Monad.forever or for that matter, most of the stuff in Control.Monad. I'd think it'd be useful for more than just me. Agda is lousy with calls to '>> return ()'; and then there's ZMachine, arrayref, whim, the barracuda packages, binary, bnfc, buddha, bytestring, c2hs, cabal, chesslibrary, comas, conjure, curl, darcs, darcs-benchmark, dbus-haskell, ddc, dephd, derive, dhs, drift, easyvision, ehc, filestore, folkung, geni, geordi, gtk2hs, gnuplot, ginsu, halfs, happstack, haskeline, hback, hbeat... You get the picture. I realize the specific name of 'ignore' can be bikeshedded to death, but it's clear, it's short, Hoogle turns up one other function with ignore in its name (Distribution.ParseUtils ignoreUnrec), and it's been independently named 'ignore' by another Haskeller (lilac). Existing uses of the string 'ignore are rare - it's in a few places as a variable, cabal and cabal-install and ehc and tar have where definitions of an ignore, a test for directory defines an ignore and imports Control.Monad unqualified, fit defines an 'ignore' but doesn't seem to use it in any module that also imports Control.Monad unqualified, halipeto defines an ignore but doesn't import Control.Monad, shim/yi has a let definition of an ignore, yhc has a where definition of an ignore. And that's about it. One of directory's tests would break, and the rest might have an additional -Wall warning. - -- gwern -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREKAAYFAkov5Q0ACgkQvpDo5Pfl1oIsRQCghUqynThzcT+OYV1KaYJhGFhv 6yYAnjf7CVOm0+Fg1FBa9IpdVIrRpCZm =Cd8V -----END PGP SIGNATURE-----

18 32

Fwd: Network on GHC 6.12 with Windows
by Neil Mitchell 04 Jan '10

04 Jan '10

Hi Johan, I just tried compiling network-2.2.1.5 with GHC 6.12.1rc2 on Windows, under Cygwin. The failures I got were: $ runhaskell Setup build Setup.hs:3:0: Warning: In the use of `defaultUserHooks' (imported from Distribution.Simple): Deprecated: "Use simpleUserHooks or autoconfUserHooks, unless you need Cabal-1.2 compatibility in which case you must stick with defaultUserHooks" Preprocessing library network-2.2.1.5... Network\Socket.hsc: In function `main': Network\Socket.hsc:994: error: invalid application of `sizeof' to incomplete type `ucred' Network\Socket.hsc:994: error: invalid application of `sizeof' to incomplete type `ucred' Network\Socket.hsc:994: error: invalid application of `sizeof' to incomplete type `ucred' Network\Socket.hsc:999: error: `SO_PEERCRED' undeclared (first use in this function) Network\Socket.hsc:999: error: (Each undeclared identifier is reported only once Network\Socket.hsc:999: error: for each function it appears in.) Network\Socket.hsc:1000: error: dereferencing pointer to incomplete type Network\Socket.hsc:1001: error: dereferencing pointer to incomplete type Network\Socket.hsc:1002: error: dereferencing pointer to incomplete type compiling dist\build\Network\Socket_hsc_make.c failed command was: C:\ghc\ghc-6.12.1-rc2\mingw\bin\gcc.exe -c -D__GLASGOW_HASKELL__=612 -Iinclude -DCALLCONV=ccall -DBASE4 -IC:\ghc\ghc-6.12.1-rc2\base-4.2.0.0\include -IC:\ghc\ghc-6.12.1-rc2/include -IC:\ghc\ghc-6.12.1-rc2/include -IC:/ghc/ghc-6.12.1-rc2/lib/include/ dist\build\Network\Socket_hsc_make.c -o dist\build\Network\Socket_hsc_make.o I then tried the darcs version and got: $ runhaskell Setup configure Setup.hs:3:0: Warning: In the use of `defaultUserHooks' (imported from Distribution.Simple): Deprecated: "Use simpleUserHooks or autoconfUserHooks, unless you need Cabal-1.2 compatibility in which case you must stick with defaultUserHooks" Warning: defaultUserHooks in Setup script is deprecated. Configuring network-2.2.1.5... configure: WARNING: unrecognized options: --with-hc checking build system type... i686-pc-cygwin checking host system type... i686-pc-cygwin checking for gcc... gcc checking for C compiler default output file name... a.exe checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... .exe checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for an ANSI C-conforming const... yes checking how to run the C preprocessor... gcc -E checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking limits.h usability... yes checking limits.h presence... yes checking for limits.h... yes checking for stdlib.h... (cached) yes checking for sys/types.h... (cached) yes checking for unistd.h... (cached) yes checking winsock2.h usability... no checking winsock2.h presence... yes configure: WARNING: winsock2.h: present but cannot be compiled configure: WARNING: winsock2.h: check for missing prerequisite headers? configure: WARNING: winsock2.h: see the Autoconf documentation configure: WARNING: winsock2.h: section "Present But Cannot Be Compiled" configure: WARNING: winsock2.h: proceeding with the compiler's result configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to libraries(a)haskell.org ## configure: WARNING: ## ------------------------------------ ## checking for winsock2.h... no checking ws2tcpip.h usability... no checking ws2tcpip.h presence... yes configure: WARNING: ws2tcpip.h: present but cannot be compiled configure: WARNING: ws2tcpip.h: check for missing prerequisite headers? configure: WARNING: ws2tcpip.h: see the Autoconf documentation configure: WARNING: ws2tcpip.h: section "Present But Cannot Be Compiled" configure: WARNING: ws2tcpip.h: proceeding with the compiler's result configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to libraries(a)haskell.org ## configure: WARNING: ## ------------------------------------ ## checking for ws2tcpip.h... no checking wspiapi.h usability... no checking wspiapi.h presence... no checking for wspiapi.h... no checking arpa/inet.h usability... yes checking arpa/inet.h presence... yes checking for arpa/inet.h... yes checking netdb.h usability... yes checking netdb.h presence... yes checking for netdb.h... yes checking netinet/in.h usability... yes checking netinet/in.h presence... yes checking for netinet/in.h... yes checking netinet/tcp.h usability... yes checking netinet/tcp.h presence... yes checking for netinet/tcp.h... yes checking sys/socket.h usability... yes checking sys/socket.h presence... yes checking for sys/socket.h... yes checking sys/uio.h usability... yes checking sys/uio.h presence... yes checking for sys/uio.h... yes checking sys/un.h usability... yes checking sys/un.h presence... yes checking for sys/un.h... yes checking for readlink... yes checking for symlink... yes checking for struct msghdr.msg_control... yes checking for struct msghdr.msg_accrights... no checking for struct sockaddr.sa_len... no checking for in_addr_t in netinet/in.h... yes checking for SO_PEERCRED and struct ucred in sys/socket.h... yes checking for _head_libws2_32_a in -lws2_32... yes checking for getaddrinfo... no checking for getaddrinfo if WINVER is 0x0501... no checking for gai_strerror... no checking whether AI_ADDRCONFIG is declared... no checking whether AI_ALL is declared... no checking whether AI_NUMERICSERV is declared... no checking whether AI_V4MAPPED is declared... no checking for sendfile in sys/sendfile.h... no checking for sendfile in sys/socket.h... no checking for gethostent... no configure: creating ./config.status config.status: creating network.buildinfo config.status: creating include/HsNetworkConfig.h configure: WARNING: unrecognized options: --with-hc Setup: Missing dependency on a foreign library: * Missing header file: HsNet.h This problem can usually be solved by installing the system package that provides this library (you may need the "-dev" version). If the library is already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where it is. I was really hoping for a Network package on GHC 6.12, as lots of my stuff depends (indirectly) on it. Is there anything I can do to help? Thanks, Neil

2 4

[network] `setSocketOption' fails with `Linger' option
by Valery V. Vorotyntsev 14 Dec '09

14 Dec '09

See http://is.gd/57Ptu (Network.Socket.setSocketOption). `setSocketOption' uses FFI binding to setsockopt(2), named `c_setsockopt'. > foreign import CALLCONV unsafe "setsockopt" > c_setsockopt :: CInt -> CInt -> CInt -> Ptr CInt -> CInt -> IO CInt The binding treats OPTVAL (4th argument) as a pointer to `int'. This is mostly fine but not when `SO_LINGER' option is being set. In the latter case OPTVAL must be a pointer to `struct linger'. [1] [1] http://www.gnu.org/s/libc/manual/html_node/Socket_002dLevel-Options.html Haskell programs trying to set SO_LINGER socket option will successfully compile but fail in runtime. $ runhaskell socket-linger.hs || echo X $ runhaskell -DLINGER socket-linger.hs || echo X socket-linger.hs: setSocketOption: invalid argument (Invalid argument) X $ gcc -g -Wall -W -o /tmp/1 socket-linger.c && /tmp/1 || echo X $ gcc -g -DLINGER_AS_INT -Wall -W -o /tmp/1 socket-linger.c && /tmp/1 || echo X setsockopt: Invalid argument X (See attached files `socket-linger.c', `socket-linger.hs'.) The necessity of `SO_LINGER' option is controversial (see [2]). I think it is better to comment the `Linger' constructor out of Network/Socket.hsc. [2] http://www.developerweb.net/forum/archive/index.php/t-2982.html Cheers. -- vvv

2 3

Advance warning to package authors of breakage with Cabal-1.8
by Duncan Coutts 11 Dec '09

11 Dec '09

package authors, I'm preparing to release a new version of Cabal. This is the one that will come with ghc-6.12. A few packages with custom Setup.hs scripts will require some changes to compile with Cabal version 1.8. In most cases it is possible to have them continue to work with version 1.6 too. When you test your changes, please test against the darcs version of Cabal-1.8 rather than the one included in 6.12 RC2. The reason is that I've added in a couple API backwards compat fixes, so there's actually less to fix than you would find with the RC2 (and for at least one of those if you fix it to work with the Cabal pre-release version included in 6.12 RC2 it'll be impossible to make it work with Cabal-1.6 too). darcs get --partial http://darcs.haskell.org/cabal-branches/cabal-1.8 These minor changes will of course be rolled into the final version that comes with ghc 6.12.1. * HDBC-postgresql, MissingPy, Omega, HDBC-mysql These use the function requireProgram in their Setup.hs. This function drops one parameter in Cabal-1.8. To make the Setup.hs continue to work with Cabal-1.6 too, I suggest changing code like this: (pgconfigProg, _) <- requireProgram verbosity pgconfigProgram AnyVersion (withPrograms lbi) let pgconfig = rawSystemProgramStdout verbosity pgconfigProg into just: let pgconfig = rawSystemProgramStdoutConf verbosity pgconfigProgram (withPrograms lbi) * haskeline This uses GHC.build in its Setup.hs which no longer exists. It got split into GHC.buildLib and buildExe. Duncan

1 1

MTL vs Transformers. Any status update?
by Erik de Castro Lopo 01 Dec '09

01 Dec '09

HI all, Has any progress been made on this? There are a couple of things I would like to package for Debian (also use myself of cource) and they can't progress until the current mess of mtl vs transformers has been sorted out. Is there anything I can do to progress this? Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

11 23

Guarantees regarding finalizers
by Mietek Bąk 01 Dec '09

01 Dec '09

Hello, I'm writing a binding to a C library, which requires an explicit cleanup call before program termination. While looking for a way to automatize this, I noticed a discrepancy in the standard library documentation. The Foreign.Concurrent documentation states: "The only guarantee is that the finalizer runs before the program terminates." (http://www.haskell.org/ghc/docs/latest/html/libraries/base/Foreign-Concurre…) On the other hand, the Foreign.ForeignPtr documentation states: "Indeed, there is no guarantee that the finalizer is executed at all; a program may exit with finalizers outstanding." (http://www.haskell.org/ghc/docs/latest/html/libraries/base/Foreign-ForeignP…) Note that Foreign.Concurrent.newForeignPtr is implemented in GHC as GHC.ForeignPtr.newConcForeignPtr. The newConcForeignPtr comments also state: "There is no guarantee of promptness, and in fact there is no guarantee that the finalizer will eventually run at all." (http://www.haskell.org/ghc/docs/latest/html/libraries/base/src/GHC-ForeignP…) As much as I would like the Foreign.Concurrent guarantee to be true, this seems to me like a documentation bug. Best regards, -- Mietek Bąk

2 3