June 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

#2309: containers: specialize functions that fail in a Monad to Maybe
by Ross Paterson 28 Jul '08

28 Jul '08

Several functions on containers used to have types like lookup :: (Ord k) => k -> Map k a -> Maybe a but these were generalized to lookup :: (Monad m, Ord k) => k -> Map k a -> m a The only methods of Monad used are return and fail. The problem is that, depending on the monad, fail can be an ordinary value or a runtime error: this device makes it harder to check whether a program is safe, because it hides possible runtime errors among testable conditions. The proposal is to change these signatures back, specializing them to Maybe. The functions involved are: lookup :: Ord k => k -> Map k a -> Maybe a lookupIndex :: Ord k => k -> Map k a -> Maybe Int minViewWithKey :: Map k a -> Maybe ((k,a), Map k a) maxViewWithKey :: Map k a -> Maybe ((k,a), Map k a) minView :: Map k a -> Maybe (a, Map k a) maxView :: Map k a -> Maybe (a, Map k a) lookup :: Key -> IntMap a -> Maybe a maxViewWithKey :: IntMap a -> Maybe ((Key, a), IntMap a) minViewWithKey :: IntMap a -> Maybe ((Key, a), IntMap a) maxView :: IntMap a -> Maybe (a, IntMap a) minView :: IntMap a -> Maybe (a, IntMap a) minView :: Set a -> Maybe (a, Set a) maxView :: Set a -> Maybe (a, Set a) maxView :: IntSet -> Maybe (Int, IntSet) minView :: IntSet -> Maybe (Int, IntSet) No information is lost, because in each case there is a single failure mode.

21 37

agreeing a policy for maintainers and hackageDB
by Ross Paterson 25 Jul '08

25 Jul '08

As a few people have noted, we need to agree a policy in this area. As I see it, the drivers are: * users need to know whether what they're downloading is supported, and if so by whom. * maintainers are entitled to control what goes out in their name. * allocating version numbers for a particular package name should be the prerogative of the maintainer. When something is agreed, I propose to put it on the hackageDB upload page and expect people to follow it. Here's my first attempt: If the Maintainer field names a person or group, the release as a whole (including packaging) is the named maintainer's approved release, which they are supporting (at least for some time after the release). Ideally a maintainer would make that clear by uploading the release themselves. A Maintainer value of "none" indicates that the package is not supported. If a package is being maintained, any release not approved and supported by the maintainer should use a different package name. Then use the Maintainer field as above either to commit to supporting the fork yourself or to mark it as unsupported.

18 44

The NetBSD Foundation Moves to a Two Clause BSD License
by Don Stewart 21 Jul '08

21 Jul '08

NetBSD has moved from BSD-3 to BSD-2 style licenses. A similar default for the Haskell community probably also makes sense (removing the 'endorsement' clause, which doesn't make much sense in the modern software industry). The new BSD2 license is below: ------------------------------------------------------------------------ /*- * Copyright (c) 2008 The NetBSD Foundation, Inc. * All rights reserved. * * This code is derived from software contributed to The NetBSD Foundation * by * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * * THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS * ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE * POSSIBILITY OF SUCH DAMAGE. */

3 3

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

[Ticket #2393] Text.PrettyPrint.HughesPJ: Bug fixes, performance improvement
by Benedikt Huber 04 Jul '08

04 Jul '08

Hello, I'd like to propose bugfixes, documentation fixes and a performance improvement for Text.PrettyPrint.HughesPJ. The changes shouldn't effect the expected behaviour of the PP library. I've written a QuickCheck test suite for the pretty printer (to test the improvement), and found two bugs and some misconceptions/ ambiguities in the documentation. Additionally, there is a microbenchmark for the suggested improvement. Both are available at http://code.haskell.org/~bhuber/Text/ PrettyPrint/. Note that the QuickCheck tests need access to all top- level names in HughesPJ (i.e. ignore the export list). In summary, I propose to * fix a bug in fillNB and one in fillNB/sepNB * correct documentation on laws and invariants. * add more efficient implementations of vcat,hsep,hcat More specifically: (1) Bugfix fillNB: Additional case for fillNB Empty (Empty : ys) (2) Bugfix [f](cat|sep): do not allow overlapping ($$) in vertical composition (3) Lazy implementations of vcat,hcat and hsep (4) Law <t2> isn't always true (5) Invariant 5 should be made stronger (6) Change the comment about negative indentation The details follow below (maybe a little long). best regards, benedikt = = = = = = = = ======================================================================== == Details (Long) == Bug Fixes -------------------------------------- (1) Bugfix fillNB Law <l1> states that > sep (ps++[empty]++qs) = sep (ps ++ qs) > ...ditto hsep, hcat, vcat, fill... In the current implementation, this fails for the paragraph fill variants. > render' $ fill True [ text "c", text "c",empty, text "c", text "b"] > where render' = renderStyle (Style PageMode 7 1.4) >> c c c >> b The reason is a missing test for Empty in fillNB 2) Bugfix: overlap and f?(cat|sep) The specification for cat/sep: * oneLiner (hcat/hsep ps) `union` vcat ps [*] But currently cat, sep, fcat and fsep attempt to overlap the second line with the first one, i.e. they use `foldr ($$) empty ps' instead of `foldr ($+$) empty ps' [*]. I assume this is a mistake. This bug can lead to situations, where the line in the right argument of Union is actually longer: > prettyDoc$ cat [ text "a", nest 2 ( text "b") ] >> text "a"; union >> (text "b"; empty) >> (nilabove; nest 1; text "b"; empty) > renderStyle (Style PageMode 1 1) $ cat [ text "a", nest 2 ( text "b") ] >> "a b" In the implementation, we call `nilAbove False' instead of `nilAbove True' (see patch). Performance Improvements -------------------------------------- 3) Improving the space/time performance of vcat, hsep, hcat vcat (hsep,cat) is implemented in an unneccessarily strict way. We only get some output after all of vcat's arguments are evaluated and checked against being Empty. This can be improved by only checking the right argument of foldr against being Empty, and then applying an Empty-filter on the resulting Doc. Space improvement is obvious. The microbenchmark (code.haskell.org/~bhuber/Text/PrettyPrint/ HughesPJPerfCheck.hs) suggests that the improvements in time are remarkable too. Documentation fixes -------------------------------------- The QuickCheck tests revealed that 4) Law <t2> isn't always true <t2> text "" <> x = x, if x non-empty only holds if x does not start with nest (obviously, because of law <n6>). 5) The invariant 5 should be extended: A @NoDoc@ may only appear on the first line of the left argument of an union. Therefore, the right argument of an union can never be equivalent to the empty set. because this assumption is used when rendering. 6) Change the comment about negative indentation In the source code we have: -- (spaces n) generates a list of n spaces -- It should never be called with 'n' < 0, but that can happen for reasons I don't understand If we compose a <> b, and the first line of b is deeply nested, but other lines of b are not, then, because <> eats the nest, the pretty printer will try to layout some of b's lines with negative indentation: doc |0123345 ------------------ d1 |a d2 | b |c d1<>d2 |ab c| Here is the reason why this is rather unavoidable: In John Hughes paper, there is a line stating that "composing layouts does not change the layouts being composed". Another one states that "<> should eat up nests" But this leads to negative indentation - imho a user error. == End ==

7 11

GetOpt formatting improvements
by Duncan Coutts 02 Jul '08

02 Jul '08

GetOpt users, I'd like to have Cabal use the standard System.Console.GetOpt but I'd also like the output to look ok. Currently Cabal uses a private modified version of GetOpt with improved formatting and I'd like to get those improvements into the standard one and eliminate the code duplication. Here's what cabal configure looks like with the standard System.Console.GetOpt. This is what it looks like on a standard 80 column console. In particular note that the descriptions wrap around onto the following lines and look ugly. http://hpaste.org/8626 Here's a little snippet: --enable-library-for-ghci Enable compile library for use with GHCi --disable-library-for-ghci Disable compile library for use wit h GHCi --enable-split-objs Enable split library into smaller ob jects to reduce binary sizes (GHC 6.6+) --disable-split-objs Disable split library into smaller o bjects to reduce binary sizes (GHC 6.6+) --enable-executable-stripping Enable strip executables upon instal lation to reduce binary sizes --disable-executable-stripping Disable strip executables upon insta llation to reduce binary sizes --configure-option=OPT Extra option for configure --user Enable doing a per-user installation --global Disable doing a per-user installatio n --package-db=PATH Use a specific package database (to satisfy dependencies and register in) Here's the same but using the internal modified copy of GetOpt: http://hpaste.org/8626#a1 and the same snippet: --enable-library-for-ghci Enable compile library for use with GHCi --disable-library-for-ghci Disable compile library for use with GHCi --enable-split-objs Enable split library into smaller objects to reduce binary sizes (GHC 6.6+) --disable-split-objs Disable split library into smaller objects to reduce binary sizes (GHC 6.6+) --enable-executable-stripping Enable strip executables upon installation to reduce binary sizes --disable-executable-stripping Disable strip executables upon installation to reduce binary sizes --configure-option=OPT Extra option for configure --user Enable doing a per-user installation --global Disable doing a per-user installation --package-db=PATH Use a specific package database (to satisfy dependencies and register in) So there's two things to notice. One is that we wrap the description so it fits in 80 columns. The other is that we use one space rather than two of padding between the short options, the long options and the description. This gives more space for the description. Actually we go one step further and leave off the args on the short options since they're shown on the long options anyway. I'm not sure everyone wants that so I'm not really proposing it. This is what it looks like: -f FLAGS --flags=FLAGS Force values for the given... vs -f --flags=FLAGS Force values for the given flags in... Similarly: -v[n] --verbose[=n] Control verbosity (n is 0--3,... vs -v --verbose[=n] Control verbosity (n is 0--3, default... So if people think this is sensible I'll send three patches: 1. word-wrap the description to fit in 80 columns 2. use less padding between columns 3. omit the args on short options when there is also a corresponding long option though as I say, perhaps not everyone will think the 3rd change is the right thing to do. Duncan

14 24

Takusen build error
by Benjamin Franksen 02 Jul '08

02 Jul '08

I get a strange error building Takusen (more precisely: the module Foreign/C/UTF8.hs) with ghc-6.8.3. It says aragon: .../ghc-6.8.3/Takusen-0.8.1 > ./Setup build -v Reading parameters from /srv/projects/ctl/franksen/haskell/ghc-6.8.3/Takusen-0.8.1/takusen.buildinfo Creating dist/build (and its parents) Creating dist/build/autogen (and its parents) Preprocessing library Takusen-0.8.1... Building Takusen-0.8.1... Building library... Creating dist/build (and its parents) Creating dist/build (and its parents) /projects/ctl/franksen/usr/bin/ghc -package-name Takusen-0.8.1 --make -hide-all-packages -i -idist/build/autogen -idist/build -i. -Idist/build -I/opt/oracle/product/client/rdbms/demo -odir dist/build -hidir dist/build -stubdir dist/build -package base-3.0.2.0 -package mtl-1.1.0.1 -package time-1.1.2.1 -package old-time-1.0.0.0 -O -XCPP Database.Enumerator Database.Util Database.Oracle.Enumerator Database.Oracle.OCIConstants Database.Oracle.OCIFunctions Database.Stub.Enumerator Control.Exception.MonadIO Foreign.C.UTF8 Database.InternalEnumerator [1 of 9] Compiling Foreign.C.UTF8 ( Foreign/C/UTF8.hs, dist/build/Foreign/C/UTF8.o ) /tmp/ghc18936_0/ghc18936_0.s: Assembler messages: /tmp/ghc18936_0/ghc18936_0.s:1257:0: Error: symbol `base_GHCziBase_Z0T_closure' is already defined I compiled ghc-6.8.3 from source, using ghc-6.8.2 to bootstrap. Any ideas? Cheers Ben

3 3

ANN: Hasim, discrete event simulation in Haskell
by Jochem Berndsen 30 Jun '08

30 Jun '08

Hi all, I've started a small project to create a library to do discrete event simulation in Haskell. Its website is located at http://huygens.functor.nl/hasim . It uses monads to define a domain-specific language for "actions" of a process. The interested reader is referred to the website. Regards, -- Jochem Berndsen | jochem(a)functor.nl GPG: 0xE6FABFAB

1 0