June 2013 - Libraries

Re: exceptions API (Was: deprecating Error class, which Was: Proposal: add handleError to mtl))
by Edward Kmett 06 Jun '13

06 Jun '13

On a somewhat related note, I've started but not yet released an 'exceptions' package based on some work from Mark Lentczner, after he encouraged me to explore the design space with an eye towards inclusion in the platform because some packages like CGI need something like MonadCatchIO-transformers, but GHC HEAD removed block and unblock, so the MonadCatchIO-transformers API is broken. It doesn't fall into the scope of the mtl as it relies on the extensible exceptions mechanism and so needs ExistentialQuantification, but it provides a generalization of the Control.Exception API that lifts it over monad transformers along with a pure untagged exception-handling monad. https://github.com/ekmett/exceptions I was going to sound folks out about what improvements they wanted to see in the API over this weekend at Hac Phi, but I suppose I can throw that out to the larger libraries list as well, given the current discussion. The haddocks for the development version are available here: file://localhost/Users/ekmett/haskell/exceptions/docs/Control-Monad-Catch.html -Edward On Thu, Jun 6, 2013 at 7:00 AM, Henning Thielemann < lemming(a)henning-thielemann.de> wrote: > > On Thu, 6 Jun 2013, Roman Cheplyaka wrote: > > * Henning Thielemann <lemming(a)henning-thielemann.de**> [2013-06-06 >> 12:14:10+0200] >> >>> >>> On Wed, 5 Jun 2013, Ross Paterson wrote: >>> >>> On the subject of ErrorT, I wonder if it's time to deprecate the Error >>>> class. >>>> >>> >>> Since I think ErrorT gives the wrong association with the 'error' >>> function, I would prefer to give up the Control.Monad.Trans.Error >>> module entirely and start a new module Control.Monad.Trans.Exception. >>> >> >> ... which would give the wrong association with exceptions (in the >> Control.Exception sense). I don't see how this is an improvement. >> > > It's the better association and it is already mentioned in the module > description of Control.Monad.Trans.Error: > > "This monad transformer adds the ability to fail or throw exceptions to a > monad." > > Nonetheless, you may suggest another module name. Independent from the > name of a new module, I would suggest to deprecate the Error name instead > of removing something from the Error module. > > > ______________________________**_________________ > Libraries mailing list > Libraries(a)haskell.org > http://www.haskell.org/**mailman/listinfo/libraries<http://www.haskell.org/mailman/listinfo/libraries> >

4 4

Proposal: add handleError to mtl
by Erik de Castro Lopo 06 Jun '13

06 Jun '13

Hi all, I would like to propose the following convenience function (with implementation) for the mtl library: handleError :: MonadError e m => (e -> m a) -> m a -> m a handleError = flip catchError which follows the handle function from Control.Exception.Base: handle :: Exception e => (e -> IO a) -> IO a -> IO a Like the handle function, handleError allows the handling of exceptions to be expressed in a more natural way, turning: catchError ( do mumble something mumble ) handler into: handlerError handler $ do mumble something mumble -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

5 5

doesFileExist and doesDirectoryExist overly verbose?
by harry 05 Jun '13

05 Jun '13

doesFileExist and doesDirectoryExist seem overly verbose - wouldn't fileExists and directoryExists be better? Not a major issue, but easily fixed. -- View this message in context: http://haskell.1045720.n5.nabble.com/doesFileExist-and-doesDirectoryExist-o… Sent from the Haskell - Libraries mailing list archive at Nabble.com.

4 5

Re: Burning bridges and Foldable nonsense
by Gabriel Gonzalez 03 Jun '13

03 Jun '13

> > With all that has changed in the last 15 years, I think it's high time > to fork Haskell, tear off all the bandaids, and begin afresh. This won't > solve all the problems, of course. We will still despair of the numeric > hierarchy; we will still despair of the partial functions demanded by > the Haskell spec; we will still worry about how to resolve things like > MPTCs, type families, and all that. But at least we can finally put > these particular ghosts to rest. Alas, to fork the language is to split > the community. And while I advocate such drastic measures, they are > measures which cannot be resolved either on this list or by the > (intentionally conservative) haskell' committee. > I disagree. Many of these changes have perfectly fine incremental solutions. Moreover, none of these issues are actually impediments to building real-world Haskell code. I'm not going to sabotage the future of the Haskell language just so that I can play golf with my import list. Everybody here is making way too big of a deal over things that are very minor issues to working Haskell programmers. The reason nobody has fixed these things is because they aren't really an impediment to Haskell programming. This discussion has nothing to do with broadening our language's appeal to the larger programming community. There are much more important issues that this community struggles with like deployment, mindshare, and tooling. If we spent as much time recruiting new programmers as we did arguing over all this Foldable/Traversable stuff we wouldn't have these problems in the first place. -1

3 2

foldable flexible bridges (putting foldable+traversable in prelude) Re: Burning bridges
by Carter Schonwald 03 Jun '13

03 Jun '13

lets see what concerns there are 1) will any code break? Nope! In fact, it's trivial to provide a shim that only exposes the list monomorphic versions. 2) does the change make learning the language more challenging? No. In fact, i've encountered *many* more smart people getting confused as to why the map / fold etc in prelude are all list specific than i've seen people struggle with type classes. The various list specific versions of the foldable codes actually **confuses** smart software folks who are starting to learn haskell for fun. I can't explain to a smart engineer *any* reason why minimum :: Ord<http://www.haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#t:O…> a => [a] -> a exists in prelude. I *can* explain why something like minimum :: (Foldable<http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Foldable.ht…> t, Ord<http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Ord.html#t:…> a) => t a -> a would be useful and deserving of being in the standard prelue. I've actually had to explain to a smart python engineering friend who's learning haskell this very problem. (that the list only versions are there for no deep reason aside from some pedagogical approach from over a decade ago that is no longer used) tl;dr no code will break, there will be less inessential nonuniformity that doesn't aid in engineering or learning with haskell, so a win in every direction. lets make things happen. -Carter On Mon, May 20, 2013 at 11:04 PM, <amindfv(a)gmail.com> wrote: > Whoa! I don't think that replacing list-monomorphic functions in the > prelude with more-general ones is going to cause the community to split > down the middle! > > Most of the changes we're talking about won't even break any legacy code! > Of course, some typeclass-rearranging will break things, but not the > prelude replacements that we've been discussing. The biggest impact is that > existing teaching texts may have old information about the type signatures > of standard functions. > > As much as I *love* imagining the Haskell community in a bridge-burning, > rival GHC HQ deathmatch (Simon vs. Simon! Edward vs. Edward!), I really > think this change won't attract the interest of any tabloids. > > That said, I definitely agree that it should take more than a few +1s to > move this forward. I'd suggest a relative-consensus on the libraries list, > then a "Here's our plan; are we crazy?" email on haskell-cafe. > > Tom > > > El May 20, 2013, a las 6:59 PM, Felipe Almeida Lessa < > felipe.lessa(a)gmail.com> escribió: > > > IMHO, the problem is that the community isn't large enough to be able > > to suffer a split. Case in point: how are we going to have two GHC > > HQs? > > > > If we're going to burn bridges, perhaps we should follow a > > Python-3-esque path of releasing a major upgrade together with: > > > > - A refactoring tool to aid with the transition. > > > > - A deadline of, say, 2-3 years during which the latest GHC for > > current Haskell would receive bugfixes while GHC 8 moves along as > > usual. > > > > Cheers, > > > > On Mon, May 20, 2013 at 7:49 PM, wren ng thornton <wren(a)freegeek.org> > wrote: > >> On 5/19/13 7:25 PM, Anthony Cowley wrote: > >>> > >>> I think this issue may be too big to rely on mailing list +1s. Is there > >>> any precedent for having a web-based poll of some sort? We often get > more > >>> engagement in debates on IRC and /r/haskell than the mailing list, so > let's > >>> not let the choice of forum drive the result. > >> > >> > >> Indeed. > >> > >> Personally, I'm all for blessing Foldable/Traversable as "built-in" and > >> getting rid of the monomorphic legacy. But then, I'm also all for making > >> Applicative a superclass of Monad, not having all the mtl modules > re-export > >> everything from Control.Monad, etc. However, all of these issues have a > long > >> history of discord, and that discord cannot be resolved on this list > IMO. > >> > >> I'm generally a staunch advocate of backward compatibility. However, > these > >> issues are ones where we've known the right answer for a long time > (unlike > >> refactoring the numeric type class hierarchy), and we've simply been > >> unwilling to burn bridges in order to do the right thing. I love > Haskell, > >> and I respect the haskell' committee, but I think it's time to just > burn it > >> all down. > >> > >> Let us not forget the original reasons for many of these warts. Some of > them > >> stem from ignorance or oversight (superclasses of Monad); others stem > from > >> the desire to help newcomers (monomorphism); and others stem from > >> circularities in the language definition (the existence of the > Prelude). As > >> Haskell has developed, we have learned more ---therefore we should not > >> embrace prior ignorance---, our standard idioms have evolved > ---therefore > >> clinging to list-monomorphism *causes* confusion rather than alleviating > >> it---, and we've tried to remove much of the circularity involved in > >> desugaring the various built-in notations for lists, arithmetic > sequences, > >> do-notation, etc. > >> > >> With all that has changed in the last 15 years, I think it's high time > to > >> fork Haskell, tear off all the bandaids, and begin afresh. This won't > solve > >> all the problems, of course. We will still despair of the numeric > hierarchy; > >> we will still despair of the partial functions demanded by the Haskell > spec; > >> we will still worry about how to resolve things like MPTCs, type > families, > >> and all that. But at least we can finally put these particular ghosts to > >> rest. Alas, to fork the language is to split the community. And while I > >> advocate such drastic measures, they are measures which cannot be > resolved > >> either on this list or by the (intentionally conservative) haskell' > >> committee. > >> > >> -- > >> Live well, > >> ~wren > >> > >> _______________________________________________ > >> Libraries mailing list > >> Libraries(a)haskell.org > >> http://www.haskell.org/mailman/listinfo/libraries > > > > > > > > -- > > Felipe. > > > > _______________________________________________ > > Libraries mailing list > > Libraries(a)haskell.org > > http://www.haskell.org/mailman/listinfo/libraries > > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://www.haskell.org/mailman/listinfo/libraries >

16 30

Proposal: When possible, give more useful exceptions from rawSystem and friends
by Ian Lynagh 02 Jun '13

02 Jun '13

Hi all, Currently, if you try to use rawSystem to run a program that doesn't exist, you will just get a bad error code as a result, e.g. this program: import System.IO.Error import System.Process main :: IO () main = do (rawSystem "/bin/true" [] >>= print) `catchIOError` \e -> putStrLn ("Exc: " ++ show e) (rawSystem "/bin/false" [] >>= print) `catchIOError` \e -> putStrLn ("Exc: " ++ show e) (rawSystem "/non/existent" [] >>= print) `catchIOError` \e -> putStrLn ("Exc: " ++ show e) putStrLn "Done" prints: ExitSuccess ExitFailure 1 ExitFailure 127 Done However, if we are on a platform that supports vfork, then we can pass information from the child process back to the parent process as they share address space. With the attached patch we instead get: ExitSuccess ExitFailure 1 Exc: resolveProcessHandle: does not exist (No such file or directory) (and it should be easy to also get "/non/existent" in the exception). If there are platforms that don't support vfork, then they will still give the old output. I haven't yet looked at whether we can also get good exceptions on Windows (the patch won't build on Windows yet; I still need to update the Windows-specific code). I think that despite the possibility that some platforms may not be able to support it, we should provide the better behaviour on platforms that do. What do you think? And do you have any other comments on the patch? (this proposal was inspired by http://hackage.haskell.org/trac/ghc/ticket/7859) Suggested discussion deadline: Mon 13 May 2013. Thanks Ian

4 6

instance Arbitrary Data.Map
by Henning Thielemann 01 Jun '13

01 Jun '13

It seems like the 'containers' package uses QuickCheck for testing, but does not export an Arbitrary Data.Map instance. Is this intended?

3 2