July 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

Trac/1417 - add pseudoterminal support to the unix library
by Bryan O'Sullivan 18 Sep '07

18 Sep '07

This is a very simple enhancement. openPseudoTerminal :: IO (Fd, Fd) getSlaveTerminalName :: Fd -> IO FilePath Here's the ticket: http://hackage.haskell.org/trac/ghc/ticket/1417 The code ought to work on Linux, Solaris, BSD, HP/UX, and Cygwin, too. I've compile-tested it on Linux, using both openpty and explicit open of /dev/ptmx. I propose a discussion period of one week. Thanks, <b

1 1

Adding IdentityT to mtl
by dons＠cse.unsw.edu.au 03 Sep '07

03 Sep '07

I wanted an IdentityT today, for extending xmonad. (The idea is to allower user-defined monad transformers, so users can plug in their own semantics easily). By default it would use IdentityT, which I note is not in mtl! Here's roughly what it would be: ----------------------------------------------------------------------------- -- | -- Module : Identity.hs -- License : BSD3-style (see LICENSE) -- module IdentityT where import Control.Monad.Trans -- -- IdentityT , a parameterisable identity monad, with an inner monad -- The user's default monad transformer -- newtype IdentityT m a = IdentityT { runIdentityT :: m a } instance (Functor m, Monad m) => Functor (IdentityT m) where fmap f = IdentityT . fmap f . runIdentityT instance (Monad m) => Monad (IdentityT m) where return = IdentityT . return m >>= k = IdentityT $ runIdentityT . k =<< runIdentityT m fail msg = IdentityT $ fail msg instance (MonadIO m) => MonadIO (IdentityT m) where liftIO = IdentityT . liftIO Any reasons why this shouldn't be in mtl? -- Don

3 5

RE: [Haskell-cafe] Definition of the Haskell standard library
by Simon Peyton-Jones 01 Aug '07

01 Aug '07

| On the other hand, it's not entirely true that there's no standard | library, it's just that it's borders are slightly fuzzy. For example, we | do have the library change submission process for modifying the standard | libraries. Up until now that has been taken to mean changes to the base | package. That package is now being split up, so we'll have to think | about what it'll apply to in the future. | | My opinion is that in the past it has been too difficult to get changes | into the base library, that there's been too much stability at the | expense of improving scope and quality. Making it easy to install new | packages and upgrade existing standard libraries should make it easier | to trial more major changes outside of the standard libs before | proposing getting those changes integrated. All true, but not so helpful for Joe User. For Joe, I think it might be helpful to have some easily-discoverable notion of which package quality and stability. - Package X is "blessed"; lots of people have argued over its design, it's stable, widely used, and actively maintained. Changes to this package goes through a quality-control process. - Package Y is a bit specialised, but it's the result of work by a small group, and it's actively maintained. - Package Z is designed, written, and maintained by one person. That person has kindly put it on Hackage so that others may share it, but you probably don't want to rely on it unless you are happy to help maintain it. Then, in effect, the "standard library" is all the X packages. I wonder if it'd help to have some descriptions such as those above (better worded), and use them? Cabal already has a "stability" indication, and that might serve, but we'd want to articulate much more clearly what it meant. Simon

5 5

Conditional compilation of Setup.hs
by Bayley, Alistair 31 Jul '07

31 Jul '07

I'd like to add a #ifdef to Takusen's Setup.hs, so that we can have a single source file that will compile with ghc-6.6 and ghc-6.6.1. With ghc-6.6 and Cabal-1.1.6.1 we use splitFileName and joinPaths from Distribution.Compat.FilePath. With ghc-6.6.1 (which includes Cabal-1.1.6.2) these have been moved to System.FilePath. I'd like to do something like the following: #ifdef __CABAL_VERSION__ > 117 import System.FilePath (splitFileName, combine) joinPaths = combine #else import Distribution.Compat.FilePath (splitFileName, joinPaths) #endif Is something like this possible with Cabal? It's either that, or make Takusen's install depend on filepath. I'm not sure which is the least desirable, but I'm open to suggestions. To be fair, we already require our ghc-6.6 users to upgrade Cabal from 1.1.6 to 1.1.6.1, so making them install filepath instead perhaps isn't so bad, and is no more effort. Alistair ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************

3 3

Proposal: Move System.Posix.Signals to the unix package
by Ian Lynagh 29 Jul '07

29 Jul '07

Hi all, Proposal: http://hackage.haskell.org/trac/ghc/ticket/1568 As suggested in http://hackage.haskell.org/trac/ghc/ticket/1190 I propose that the System.Posix.Signals module is moved to the UNIX package. Currently, on Windows, it is an empty module. Suggested deadline: 12 August 2007. Thanks Ian

1 0

Proposal: Move the throwErrnoPath* functions from unix:System.Posix.Error to base:Foreign.C.Error
by Ian Lynagh 29 Jul '07

29 Jul '07

Proposal: http://hackage.haskell.org/trac/ghc/ticket/1566 Currently, unix:System.Posix.Error has a number of throwErrnoPath* functions which are entirely portable, but they are not available on Windows due to being in the unix package. In the thread beginning http://www.haskell.org/pipermail/libraries/2007-July/007793.html Simon Marlow writes: When I needed to add some error-related functionality for the POSIX library, I didn't want to add extra stuff to Foreign.C.Error beyond what was specified in the FFI spec, so I added System.Posix.Error instead. This was just conservative; we could probably add throwErrnoPath and friends to Foreign.C.Error (with the usual proposal process). I propose that these functions are moved to base:Foreign.C.Error. They would still be re-exported by unix:System.Posix.Error to minimise breakage. Suggested deadline: Sun 12 August 2007. Thanks Ian

2 1

documentation in GHC.Conc, Control.Parallel.Strategies; querying number of CPUs
by Frederik Eaton 29 Jul '07

29 Jul '07

Hello, I am interested in implementing some multi-threaded algorithms in Haskell. I have run into some documentation dead-ends. The documentation in GHC.Conc is what I get when I search for "ghc pseq" on google, but it doesn't document pseq and some other functions: pseq par forkOnIO childHandler ensureIOManagerIsRunning In particular, I wonder: How is pseq different from seq? Under what circumstances is it used? I have looked at the source code so I see that it is implemented in terms of 'seq' and 'lazy': > -- "pseq" is defined a bit weirdly (see below) > -- > -- The reason for the strange "lazy" call is that > -- it fools the compiler into thinking that pseq and par are non-strict in > -- their second argument (even if it inlines pseq at the call site). > -- If it thinks pseq is strict in "y", then it often evaluates > -- "y" before "x", which is totally wrong. > > pseq :: a -> b -> b > pseq x y = x `seq` lazy y - does this mean pseq should be used instead of 'seq' when I want the first argument to be evaluated first? And I am also curious about the others, although par seems to be documented in Control.Parallel. Also, the following functions in Control.Parallel.Strategies are not documented, at least in Haddock: (>|) :: Done -> Done -> Done (>||) :: Done -> Done -> Done using :: a -> Strategy a -> a demanding :: a -> Done -> a sparking :: a -> Done -> a sPar :: a -> Strategy b sSeq :: a -> Strategy b r0 :: Strategy a rwhnf :: Strategy a rnf :: Strategy a ($|) :: (a -> b) -> Strategy a -> a -> b ($||) :: (a -> b) -> Strategy a -> a -> b (.|) :: (b -> c) -> Strategy b -> (a -> b) -> a -> c (.||) :: (b -> c) -> Strategy b -> (a -> b) -> a -> c (-|) :: (a -> b) -> Strategy b -> (b -> c) -> a -> c (-||) :: (a -> b) -> Strategy b -> (b -> c) -> a -> c seqPair :: Strategy a -> Strategy b -> Strategy (a, b) parPair :: Strategy a -> Strategy b -> Strategy (a, b) seqTriple :: Strategy a -> Strategy b -> Strategy c -> Strategy (a, b, c) parTriple :: Strategy a -> Strategy b -> Strategy c -> Strategy (a, b, c) fstPairFstList :: NFData a => Strategy [(a, b)] force :: NFData a => a -> a sforce :: NFData a => a -> b -> b The types Done and Strategy or the class NFData and related classes in this module are also not documented in Haddock. If there is a paper which defines all of these then it would be nice to have a link to the paper in the module's documentation, for people to use until the module's documentation itself can be updated. As an aside, if you've read this far then you may know the answer to a related question: is there a way to query how many processors the current machine has? I am implementing a parallel sort, and in cases such as sorting where one can decompose an algorithm into an arbitrarily large number of threads, I am wondering how to tell what the maximum useful number of threads is (usually this will be some increasing function of the number of CPUs) to avoid the overhead of spawning a thread when it is not needed. (I'm about to read "Lightweight concurrency primitives for GHC" by Li et al, if that's the right place to look) Thanks, Frederik -- http://ofb.net/~frederik/

7 9

ANNOUNCE: Gtk2Hs version 0.9.12 released
by Duncan Coutts 27 Jul '07

27 Jul '07

Gtk2Hs - A GUI Library for Haskell based on Gtk+ Version 0.9.12 is now available from: http://haskell.org/gtk2hs/download/ The source tarball and an installer for Windows are available. Packages for various platforms should become available soon, hopefully including Debian, Fedora, Gentoo, FreeBSD and Darwin. Changes since 0.9.11: * ps, pdf and svg cairo backends are now supported * drag & drop support added * can run mainGUI in GHCi after :reload * Graphics.SOE.Gtk now works with threaded rts and GHCi * Windows build now includes OpenGL and SourceView packages * c2hs no longer chokes on some system headers (eg glibc-2.4) * various bug fixes and minor code cleanups * major overhaul of the code generator (will help binding Gtk+ 2.10) Gtk2Hs feature highlights: * automatic memory management * Unicode support * nearly full coverage of Gtk+ 2.8 API * support for several additional Gtk+/Gnome modules: * Glade visual GUI builder * cairo vector graphics library * SVG rendering for cairo * OpenGL extension (works with HOpenGL) * GConf, Gnome's system for storing app preferences * SourceView, code editor widget with syntax highlighting * the Mozilla browser rendering engine in a widget * an implementation of the Graphics.SOE API * extensive haddock API reference documentation * multi-platform support with native look * LGPL licence Platforms and requirements: * builds from source on Linux, Windows, MacOS X, FreeBSD and Solaris * builds with GHC 6.2 - 6.6.1 * works with Gtk+ version 2.0 through to 2.10 * SVG support requires librsvg version 2.16 or later Please report all problems to gtk2hs-devel(a)sourceforge.net Contributions and feedback are also most welcome. Windows release notes: The installer expects GHC 6.6.1. As always if you need a build for a different version of GHC then that's possible by building from source. The windows build now includes the gtkglext and sourceview packages, but not svgcairo as that has pretty heavy dependencies. This makes the download a bit bigger, but on the other hand currently it includes support for only one GHC version, so overall the installer is rather smaller than in the last release. Duncan (on behalf of the Gtk2Hs team)

1 0

Why is System.Posix.Error in unix?
by Ian Lynagh 24 Jul '07

24 Jul '07

Hi all, I get the feeling I must be missing something, but why is System.Posix.Error in the unix package? It looks to me like it just calls things in the base package, and it works on Windows as far as I can see: $ ghci System/Posix/Error.hs [...] Loading package base ... linking ... done. [1 of 1] Compiling System.Posix.Error ( System/Posix/Error.hs, interpreted ) Ok, modules loaded: System.Posix.Error. *System.Posix.Error> throwErrnoPath "foo" "bar" *** Exception: bar: foo: failed (No error) *System.Posix.Error> Is there a reason not to move this, perhaps renaming it in the process, to the base package (or possibly elsewhere in the future, but in the short term I might want to use it in base)? Thanks Ian

4 5