April 2008 - 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

Arrow without `>>>'
by Valery V. Vorotyntsev 03 Sep '08

03 Sep '08

Hi, friends, I've built GHC from darcs, and... Could anybody tell me, what's the purpose of Arrow[1] not having `>>>' method? 1. http://darcs.haskell.org/packages/base/Control/Arrow.hs $ ghci GHCi, version 6.9.20080104: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude> :m + Control.Arrow Prelude Control.Arrow> :i Arrow class (Control.Category.Category a) => Arrow a where arr :: (b -> c) -> a b c pure :: (b -> c) -> a b c first :: a b c -> a (b, d) (c, d) second :: a b c -> a (d, b) (d, c) (***) :: a b c -> a b' c' -> a (b, b') (c, c') (&&&) :: a b c -> a b c' -> a b (c, c') -- Defined in Control.Arrow instance Arrow (->) -- Defined in Control.Arrow instance (Monad m) => Arrow (Kleisli m) -- Defined in Control.Arrow Prelude Control.Arrow> Leaving GHCi. I can't build[2] arrows-0.3 package without `>>>' in Arrow. 2. vvv@fun:~/src/arrows$ darcs w { hunk ./Control/Arrow/Operations.hs 36 +import Control.Category ((>>>)) hunk ./Control/Arrow/Transformer/CoState.hs 23 +import Control.Category ((>>>)) } vvv@fun:~/src/arrows$ runhaskell Setup build Preprocessing library arrows-0.3... Building arrows-0.3... [ 3 of 12] Compiling Control.Arrow.Transformer.CoState ( Control/Arrow/Transformer/CoState.hs, dist/build/Control/Arrow/Transformer/CoState.o ) Control/Arrow/Transformer/CoState.hs:29:7: `>>>' is not a (visible) method of class `Arrow' The question arises "should I?", but this is one of lambdabot's[3] depencies. 3. http://code.haskell.org/lambdabot/ Thanks a lot! -- vvv

4 5

Proposal: overhaul System.Process
by Simon Marlow 18 Jul '08

18 Jul '08

I've made some improvements to System.Process that I'd like to get feedback on. Everything so far is backwards compatible in the sense that I've only added to the API - everything that was there before is still available, with the same semantics (except where bugs have been fixed). Haddock for the proposed new System.Process: http://darcs.haskell.org/~simonmar/process/System-Process.html Ticket: http://hackage.haskell.org/trac/ghc/ticket/2233 Discussion period: 4 weeks (20 May) Summary of changes: Tue Apr 22 15:02:16 PDT 2008 Simon Marlow <simonmarhaskell(a)gmail.com> * Overhall System.Process - fix #1780: pipes created by runInteractiveProcess are set close-on-exec by default - add a new, more general, form of process creation: createProcess Each of stdin, stdout and stderr may individually be taken from existing Handles or attached to new pipes. Also it has a nicer API. - add readProcess from Don Stewart's newpopen package. This function behaves like C's popen(). - Move System.Cmd.{system,rawSystem} into System.Process. Later we can depecate System.Cmd. - Don't use O_NONBLOCK for pipes, as it can confuse the process attached to the pipe (requires a fix to GHC.Handle in the base package). - move the tests from the GHC testsuite into the package itself, and add a couple more - bump the version to 2.0

13 75

building a helper binary with cabal
by Evan Martin 17 May '08

17 May '08

[resent after subscribing to the list] I'm working on a package that requires building a helper binary as part of its install process. This binary is written in C (with good reason), and on a Debian system would be installed into a path like /usr/lib/myproject/mybinary, because it's only used internally by the main program binary. My setup is up to this point: > gccProgram :: Program > gccProgram = simpleProgram "gcc" > type BuildHook = PackageDescription -> LocalBuildInfo > -> UserHooks -> BuildFlags -> IO () > creplChildBuild :: BuildHook -> BuildHook > creplChildBuild oldhook desc buildinfo hooks flags = do > oldhook desc buildinfo hooks flags > rawSystemProgramConf (buildVerbose flags) gccProgram (buildPrograms flags) > ["child.c", "-o", buildDir buildinfo </> "child", "-ldl"] > buildHooks = simpleUserHooks { > hookedPrograms = [gccProgram], > buildHook = creplChildBuild (buildHook simpleUserHooks) > } > main = defaultMainWithHooks buildHooks However, it's unclear to me how to set up the install rule that would copy that binary into the appropriate place. Any tips? It seems I want to grab the "install" hook, but from there how do I specify where to install the file? There seem to be no helper functions to facilitate installing. (I appreciate that all of this is pretty new. So if it's not possible for me to do what I want, take it as an example of the sort of thing I'd like for Cabal to support...)

2 8

Specifying dependencies on Haskell code
by Duncan Coutts 12 May '08

12 May '08

All, In the initial discussions on a common architecture for building applications and libraries one of the goals was to reduce or eliminate untracked dependencies. The aim being that you could reliably deploy a package from one machine to another. We settled on a fairly traditional model, where one specifies the names and versions of packages of Haskell code. An obvious alternative model is embodied in ghc --make and in autoconf style systems where you look in the environment not for packages but rather for specific modules or functions. Both models have passionate advocates. There are of course advantages and disadvantages to each. Both models seem to get implemented as reactions having the other model inflicted on the author. For example the current Cabal model of package names and versions was a reaction to the perceived problem of untracked dependencies with the ghc --make system. One could see implementations such as searchpath and franchise as reactions in the opposite direction. The advantages and disadvantages of specifying dependencies on module names vs package names and versions are mostly inverses. Module name clashes between packages are problematic with one system and not a problem with the other. Moving modules between packages is not a problem for one system and a massive pain for the other. The fact is that both module name and package name + version are being used as proxies to represent some vague combination of required Haskell interface and implementation thereof. Sometimes people intend only to specify an interface and sometimes people really want to specify (partial) semantics (eg to require a version of something including some bug fix / semantic change). In this situation the package version is being used to specify an implementation as a proxy for semantics. Neither are very good ways of identifying an interface or implementation/semantics. Modules do move from one package to another without fundamentally changing. Modules do change interface and semantics without changing name. There is no guarantee about the relationship between a package's version and its interface or semantics though there are some conventions. Another view would be to try and identify the requirements about dependent code more accurately. For example to view modules as functors and look at what interface they require of the modules they import. Then we can say that they depend on any module that provides a superset of that interface. It doesn't help with semantics of course. Dependencies like these are not so compact and easy to write down. I don't have any point here exactly, except that there is no obvious solution. I guess I'd like to provoke a bit of a discussion on this, though hopefully not just rehashing known issues. In particular if people have any ideas about how we could improve either model to address their weak points then that'd be well worth discussing. For example the package versioning policy attempts to tighten the relationship between a package version and changes in its interface and semantics. It still does not help at all with modules moving between packages. Duncan

7 17

proposal #2254: have Control.Arrow re-export (>>>) and (<<<)
by Ross Paterson 06 May '08

06 May '08

A previous proposal: http://hackage.haskell.org/trac/ghc/ticket/1773 split the Arrow class, making (>>>) and (<<<) functions in Control.Category. This breaks programs that use Control.Arrow. To avoid some of the breakage, the proposal is that Control.Arrow should re-export (>>>) and (<<<), imported from Control.Category.

6 12

QuickCheck properties for IntSet
by David Benbennick 01 May '08

01 May '08

Here's a patch to IntSet.hs that adds many QuickCheck properties. It adds properties testing almost all of the public interface of IntSet, and also properties testing that the data type invariants are never broken. (The patch doesn't test the Data, Eq, Monoid, Read, or Typeable instances.) Also, this patch removes a helper function, foldlStrict, and replaces it with calls to Data.List.foldl'. I have two questions: 1) Is this the right way to submit patches? 2) Is there a good reason that IntSet doesn't use "deriving Eq", and instead manually implements the Eq instance?

5 21

Re: Proposal: overhaul System.Process
by Simon Marlow 29 Apr '08

29 Apr '08

Brian Brunswick wrote: > On Tue, Apr 29, 2008 at 6:14 PM, Simon Marlow <marlowsd(a)gmail.com> wrote: >> readProcessWithExitCode >> :: FilePath -- ^ command to run >> -> [String] -- ^ any arguments >> -> String -- ^ standard input >> -> IO (ExitCode,String) -- ^ exitcode, and stdout + stderr > > Surely in this case one wants stdout in a separate String to stderr? > > If something fails in the middle of a long operation, I want just the > error, doc! Well yes, but maybe you also want to tally the stderr with the stdout, to see what was going on at the time the errors were generated (modulo buffering, of course). How about two separate versions? In which case, what should they be called? Cheers, Simon

3 2

proper cabal use?
by Daniel Gorín 28 Apr '08

28 Apr '08

Hi In the hint [1] package I need to run ghc --print-libdir at configure time and save its result. The catch is that I need to run exactly the same ghc binary that will build the package (i.e. not necessarily the one in the path). Because of this requirement I can't use a "configure" script as advised in the docs [2], can I? What I did, instead, is to write a posthook that takes the information in the LocalBuildInfo and runs the ghc configured there. The downside is that this it is not portable across Cabal versions (incidentally, if I add the requirement cabal-version: >= 1.2 && < 1.3, hackage refuses to upload the package...) So my question is, what would be the proper way to handle this? Thanks Daniel [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hint-0.2 [2] http://www.haskell.org/cabal/release/latest/doc/users-guide/ x30.html#system-dependent

2 2

Issue with package "pretty"
by David MacIver 27 Apr '08

27 Apr '08

#haskell have just helped me figure out an entertaining issue with the pretty library on hackage. I couldn't figure out the right place to file a bug report and the maintainer is listed as libraries(a)haskell.org so I'm emailing the list in the hopes that someone will know what to do about it. :-) The problem is that if you install pretty, Cabal will suddenly cease working until you recompile it. It depends on a version of pretty which gets bundled with GHC is purportedly of the same version as the one on hackage, but the two aren't binary compatible. So when it tries to use it, everything goes boom.

4 9