March 2007 - 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: ByteString based datagram communication (Ticket #1238 )
by Robert Marlow 17 May '07

17 May '07

I've made a proposal to add ByteString based datagram communication to Network.Socket and Network. Details are at: http://hackage.haskell.org/trac/ghc/ticket/1238#preview I rushed to get this done before I go on a trip tomorrow so I haven't completed testing and won't be available to discuss it for the next 9 days. As such, if discussion is needed, an extended deadline would be appreciated. Testing windows is a bit awkward for me since I don't have a windows machine, so if anyone can test that platform I'd be very appreciative. I'll try to work through the problems I was having with hugs and test when I get back unless someone else wants to test it first. Thanks. -- Robert Marlow MITS Co-operative Limited http://www.mits.coop/

7 23

Is there already a list class?
by Marc Weber 13 May '07

13 May '07

Hello. Is here the right place to request a list class? eg class List l e where (:) :: e -> l e -> l e head :: .. This might be used in Data.Set, Data.Map class StorableAsList l e t where fromList :: l e -> t toList :: t -> l e I'd like to help implementing/ writing it. Do you consider this beeing a useful enhancement? Cheers Marc Weber

12 20

Automated tests for the libraries?
by Jeffrey Yasskin 19 Apr '07

19 Apr '07

Looking through the libraries, I see a lot of commented out imports of QuickCheck and prop_foo definitions, but no way to run them all without a lot of manual editing of files. There are also a few tests in testsuite/tests/libraries/Data/, but they don't even build with ghc-6.6 because of an import of the hidden module Distribution.Compat.FilePath. It seems like this would make it hard to ensure that things work on more than a few platforms. Is there some automated test suite for the libraries that I'm just missing? Is there a plan for developing one? If not, I'll start a wiki page for ideas and try to get a rudimentary one put together. Jeffrey

6 13

openTempFile only defined on GHC
by Neil Mitchell 10 Apr '07

10 Apr '07

Hi, >From the System.IO export list: #ifdef __GLASGOW_HASKELL__ openTempFile, openBinaryTempFile, #endif So we have a standardised module with a standardised interface which is totally broken on all but one compiler. Can this please be either: 1) Implemented for all compilers 2) Removed, and then potentially re-added by the proper libraries submission process I hope the new libraries submission process will stop things like this being added in future, without appropriate thought. Thanks Neil

5 10

Proposal [Trac #1212]: add IPv6 support to network library
by Bryan O'Sullivan 07 Apr '07

07 Apr '07

Here's the Trac ticket: http://hackage.haskell.org/trac/ghc/ticket/1212 This proposal adds two standard protocol-independent functions to Network.BSD to allow the networking code to work with both IPv6 and IPv4 addresses and protocols. getAddrInfo is the equivalent of getaddrinfo from RFC 2553. getNameInfo is the equivalent of getnameinfo from RFC 2553. These functions rely on a few new types: AddrInfo AddrInfoFlags NameInfoFlags Several global values provide mnemonics for query hints and flags. Both of these functions are available on all modern operating systems. They unify name and service lookup for IPv4 and IPv6. The code has been autoconfiscated so that it will not be compiled if IPv6 support is not available. I have not touched existing code in any way, save to add and extend the smallest possible number of types and functions so that IPv6 addresses can be accommodated. I would suggest a consideration period of one week, since my changes are non-intrusive in nature. Regards, <b

5 22

proposal: add 'unsafeCoerce'
by Malcolm Wallace 02 Apr '07

02 Apr '07

Currently, all implementations provide either the 'unsafeCoerce' or 'unsafeCoerce#' functions, but they live in implementation-specific locations. This proposal is to adopt the Haskell'98-compatible name 'unsafeCoerce', and to add it to the standard base library package. Suggested location: Data.Function.Unsafe? http://hackage.haskell.org/trac/ghc/ticket/994 Regards, Malcolm

17 45

System.Process bugs on Unix
by John Goerzen 02 Apr '07

02 Apr '07

I have another concern about System.Process. I have this code: (recordfn, recordh) <- openTempFile macdir "new-" ... (c1, macroh, c2, xmacroph) <- runInteractiveProcess "xmacrorec2" ["-k", "0xffff"] Nothing Nothing ... grepph <- runProcess "egrep" ["-v", "^(ButtonRelease|ButtonPress|MotionNotify)"] Nothing Nothing (Just macroh) (Just recordh) Nothing Now, egrep is dying with: grep: (standard input): Resource temporarily unavailable And strace shows that, sure enough, read(0,...) in grep is getting EAGAIN. Sounds like somebody forgot to take the fd out of non-blocking mode. This renders runProcess pretty well useless, IMHO. -- John

3 7

Dubious behavior in TH pretty printer
by Stefan O'Rear 02 Apr '07

02 Apr '07

The Template Haskell pretty-printer handles infix/prefix distinction improperly, causing text generated using it to be unparsable. Example: stefan@stefans:~/daanpp$ ghci -fth ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.7.20070323, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. Loading package base ... linking ... done. Prelude> :m + Language.Haskell.TH Prelude Language.Haskell.TH> runQ [| (+) 2 2 |] >>= print . ppr Loading package template-haskell ... linking ... done. GHC.Num.+ 2 2 I am trying to use the Template Haskell AST system for internal representation of terms in a derivation library that can output Haskell or feed directly into a splice. This "bug", unfixed, would force me to fork the TH pretty printer. What would people think of a patch changing the behavor to "Always produce parsable output"? (Yes, I'm offering to implement it.) Stefan

3 4

Adding System.FilePath
by Neil Mitchell 01 Apr '07

01 Apr '07

Hi, When it comes to adding System.FilePath, we seem to have reached a concensus of indecision, so I am going to attempt to set out the various options, and see if we can pick one. 1) Do not let programmers type "import System.FilePath", i.e. do not include the module No one seems to be advocating this. 2) Let programmers type "import System.FilePath" and have it work in Cabal Setup.hs files, and in all Cabal built programs without requiring the user specify that they are using the filepath package. This is what everyone wants. Within this there are two approaches being advocated: a) Add to base. b) Add as a library which we demand all Haskell compilers ship, and tweak Cabal to automatically use this library at all times. Option a involves absolutely no additional work for me - the patch has been posted to this mailing list. Option b involves Cabal hacking, establishing new procedures, coming up with a definition of libraries which are always available etc. It is likely that option b will be required once (if ever) base is split up. I certainly don't have time to do option b. So can I propose we add filepath, with this agreement that once (someone else) gets around to doing option b, we can split it out afterwards? The particular argument for upgrading the filepath library I think is not important - I never intend to do more filepath hacking. Someone might add one or two functions, but thats about the most I can invision. It's not a particularly pleasant job, its ugly - the only reason I started this was because the alternative is having everything broken on Windows - something I do care about. Thanks Neil

15 73