May 2008 - Libraries - Haskell.org

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

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

haddock: record types with partially exported fields
by Misha Aizatulin 11 Jun '08

11 Jun '08

hello, attached (M1) is an example of a situation, where haddock hides all fields of a record, just because one field is hidden. The result is that the other field is not shown in the documentation as well, even though it is exported. As an example for why hiding certain fields of a record might make sense, consider M2. There we export two functions for decomposing T: f and g, whereas f is a class function that can be used for other datatypes as well, and g is a function specific to T. The ugly fT function is hidden from the user. I'd wish myself a haddock output in which T would be shown in record style, but there would be a blank instead of fT or maybe something like "<hidden>". Cheers, Misha P.S. What's the right place to talk about haddock by the way?

5 9

Fwd: [Haskell-cafe] Data.Tree.Zipper in the standard libraries
by Krasimir Angelov 08 Jun '08

08 Jun '08

Ups! According to the library submission procedure this message should have been sent to libraries(a)haskell.org. I appologise for the multiple copies. ---------- Forwarded message ---------- From: Krasimir Angelov <kr.angelov(a)gmail.com> Date: Sat, May 31, 2008 at 10:42 AM Subject: Re: [Haskell-cafe] Data.Tree.Zipper in the standard libraries To: Haskell-cafe <haskell-cafe(a)haskell.org> Hi again, I was silent for some time but in this time I created QuickCheck tests for Data.Tree.Zipper which achieve 100% coverage with HPC. I also created a ticket for it: Ticket #2324 http://hackage.haskell.org/trac/ghc/ticket/2324 The attached file is the current implementation and it contains the version updated from Iavor Diatchki. It has the advantage that it also works with forests, not just with trees. Initially I thought that complete testsuite for such a simple module might be overkill but actually I found a bug :-) in the splitChildren function which is now fixed. The dead line for further considerations is one week. Regards, Krasimir On Sun, May 25, 2008 at 1:09 AM, Iavor Diatchki <iavor.diatchki(a)gmail.com> wrote: > Hello, > I think that the modified API (no state monad, and using Maybe) is > quite nice! I implemented a version of the the suggested API using a > slightly different data structure, which makes the code a bit simpler, > I think. I put the code in the Haskell wiki: > http://www.haskell.org/sitewiki/images/2/2d/RoseZipper.hs > I also added a couple of extra functions that seemed useful, and > renamed a few of the functions to be more consistent. > > As for how to distribute the code, it seems that Zipper should live in > the same place as Data.Tree. I think that Data.Tree is part of the > "containers" package, so it would make sense to add the Zipper there > as well. > > -Iavor > > > > On Sat, May 24, 2008 at 1:24 AM, Neil Mitchell <ndmitchell(a)gmail.com> wrote: >> Hi, >> >>> It doesn't use State monad anymore and it returns Maybe. This seems to >>> be the common preference, is it? Feel free to vote against. Should we >>> change Data.Map also? There is another proposal for changes in >>> findMin/findMax so it is better to make this two breaking changes >>> together rather than in a later release. >> >> The standard libraries proposal thingy is to go via the libraries >> list, create tickets etc. What reason is there to make this part of >> the base libraries, rather than a separate package on hackage? I can't >> see much reason to make Data.Tree part of the base libraries, other >> than the fact it already is, and it could easily get moved out at a >> future date. >> >> We've seen there is some advantage in leaving the implementation >> outside the base library, as its already changed several times in the >> past few days. >> >> Thnanks >> >> Neil >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >

16 44

hackage, package list, trac, some suggestions/questions
by Claus Reinke 06 Jun '08

06 Jun '08

hope this is the right list for hackage issues?-) 1. hackage trac does not seem to have a "register" option (compare hackage trac with ghc trac). individual logins are nice because: - gives individual rather than anonymous reporters - one place less to support spam email harvesters (account name instead of full email address) - "register" is always there, hence easy to find, unlike the hint hidden on the trac home page that hackage is still abusing the haskell' trac.. (i had started this email before i found that hint;-) 2. the hackage package list ought to have a link to an alphabetical index (i often know the package name, but not the likely categories, so i tend to 'search' on that page..). 3. the hackage package list ought to list successful and failed builds (simply a list of compiler versions, each one green or red, depending on success, with direct link to build/ failure log; this would fit into the one-line-per-package format) for each entry, and report them to package authors. build failures currently seem to be created automatically where package authors may not notice them? at least, that would explain things like (just examples of things i happened to have looked at, no offence intended;-) - hint: advertised to work with ghc 6.8.x on the same package page that lists a build failure for ghc-6.8 - haskell-src-exts: lists a build failure for ghc-6.8 the first is probably a too optimistic cabal version spec, the second is a haddock issue. but that makes two out of two for package i looked up recently.. 4. is there an cross-package index of builds/failures, so that one might see trends (cabal issues, base package issues, bytestring issues, next big thing issues,..) and statistics (how many hackage packages fail/build, which compiler/ cabal/haddock versions are successful for the largest number of packages, etc.)? 5. generally, i've always thought that hackage works the wrong way round; instead of yet another push-based place for people to put and forget copies of things, it should work as a pull-based cache: - author registers package, with author/maintainer email and package url - hackage retrieves package, tries to build, and either accepts or not, reporting all to author - occasionally, hackage scans for new versions to be retrieved, again notifying authors of uploads and problem reports - the maintainer email on each hackage package page ought to be (a) protected, not plain text (b) annotated with last successful contact date if i understand #243, authors are not even notified when someone uploads their packages? claus

6 10

type-level integers using type families
by Peter Gavin 03 Jun '08

03 Jun '08

Has anyone else tried implementing type-level integers using type families? I tried using a couple of other type level arithmetic libraries (including type-level on Hackage) and they felt a bit clumsy to use. I started looking at type families and realized I could pretty much build an entire Scheme-like language based on them. In short, I've got addition, subtraction, & multiplication working after just a days worth of hacking. I'm going to post the darcs archive sometime, sooner if anyone's interested. I really like the type-families based approach to this, it's a lot easier to understand, and you can think about things functionally instead of relationally. (Switching back and forth between Prolog-ish thinking and Haskell gets old quick.) Plus you can do type arithmetic directly in place, instead of using type classes everywhere. One thing that I'd like to be able to do is lazy unification on type instances, so that things like data True data False type family Cond x y z type instance Cond True y z = y type instance Cond False y z = z will work if the non-taken branch can't be unified with anything. Is this planned? Is it even feasible? I'm pretty sure it would be possible to implement a Lambda like this, but I'm not seeing it yet. Any ideas? Pete

4 4

Re: type-level integers using type families
by Peter Gavin 31 May '08

31 May '08

Benedikt Huber wrote: >> data True >> data False >> >> type family Cond x y z >> type instance Cond True y z = y >> type instance Cond False y z = z > > I'm not sure if this is what you had in mind, but I also found that e.g. > > > type instance Mod x y = Cond (y :>: x) x (Mod (Sub x y) y) > > won't terminate, as > > > Mod D0 D1 ==> Cond True D0 (Mod (Sub D0 D1) D0) ==> <loop> Right, because it always tries to infer the (Mod (Sub x y) y) part no matter what the result of (y :>: x) is. > > rather than > > > Mod D0 D1 ==> Cond True D0 ? ==> D0 > > For Mod, I used the following (usual) encoding: > > > type family Mod' x y x_gt_y > > type instance Mod' x y False = x > > type instance Mod' x y True = Mod' (Sub x y) y ((Sub x y) :>=: y) > > type family Mod x y > > type instance Mod x y = Mod' x y (x :>=: y) > Yes, it's possible to terminate a loop by matching the type argument directly. > 1) One cannot define type equality (unless total type families become > available), i.e. use the overlapping instances trick: >> instance Eq e e True >> instance Eq e e' False I didn't want to mix type classes and families in my implementation. All the predicates are implemented like so: > type family Eq x y > type instance Eq D0 D0 = True > type instance Eq D1 D1 = True ... > type instance Eq (xh :* xl) (yh :* yl) = And (Eq xl yl) (Eq xh yh) then I've added a single type-class > class Require b > instance Require True so you can do stuff like > f :: (Require (Eq (x :+: y) z)) => x -> y -> z or whatever. I haven't yet tested it (but I think it should work) :) Pete > > Consequently, all type-level functions which depend on type equality > (see HList) need to be encoded using type classes. > > 2) One cannot use superclass contexts to derive instances e.g. to define >> instance Succ (s,s') => Pred (s',s) > > In constrast, when using MPTC + FD, one can establish more than one TL > function in one definition > > > class Succ x x' | x -> x', x' -> x > > 3) Not sure if this is a problem in general, but I think you cannot > restrict the set of type family instances easily. > > E.g., if you have an instance > > > type instance Mod10 (x :* D0) = D0 > > then you also have > > > Mod10 (FooBar :* D0) ~ D0 > > What would be nice is something like > > > type instance (IsPos x) => Mod10 (x :* D0) = D0 > > though > > > type family AssertThen b x > > type instance AssertThen True x = x > > type instance Mod10 (x :* D0) = AssertThen (IsPos x) D0 > > seems to work as well. > > 4) Not really a limitation, but if you want to use instance methods of > Nat or Bool (e.g. toBool) on the callee site, you have to provide > context that the type level functions are closed w.r.t. to the type class: > >> test_1a :: forall a b b1 b2 b3. >> (b1 ~ And a b, >> b2 ~ Not (Or a b), >> b3 ~ Or b1 b2, >> Bool b3) => a -> b -> Prelude.Bool >> test_1a a b = toBool (undefined :: b3) > > Actually, I think the 'a ~ b' syntax is very nice. > > I'm really looking forward to type families. > > best regards, > > benedikt

1 0

System.Posix.Temp
by Peter Gammie 30 May '08

30 May '08

The docs for mkstemp are somewhat short. (One must add XXXXXX to the end of the template for things to go, and probably prepend a path as well.) Apparently it is better to use tmpfile(3) now. How difficult would it be to provide that function as well? (Note the return type is FILE *.) cheers pete -- http://peteg.org/

1 0