- Libraries - Haskell.org

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

Re: Why is there no Foldable instance for Either?
by Gabriel Gonzalez 31 May '13

31 May '13

> I've taken the liberty of pushing the previously discussed Foldable and > Traversable instances for Either a and (,) a. Thank you very much!

1 0

Making decisions
by Simon Peyton-Jones 31 May '13

31 May '13

This "burning bridges" thread has really got us going! I'm a bit concerned, though, that we don't have an effective mechanism for resolving such debates. If everyone feels that they have a vote, perhaps, but only one among many, then one feels either mandated or indeed willing to invest the extra cycles to summarise pros and cons based on feedback, crisply articulate alternatives, and so on. And, worse still, no one feels mandated to actually decide anything. That's fine when there's a clear consensus; not so fine when there isn't, as here. Several people on the "Burning bridges" thread have commented on the interminable nature of the debate. Our general procedures for library changes are described here: http://www.haskell.org/haskellwiki/Library_submissions. For specialised libraries (eg MD5 checksum, or even containers) the situation is clear: the author or current maintainer decides. But for the basic core libraries, whose influence is pervasive, matters are murkier. Looking at http://www.haskell.org/haskellwiki/Library_submissions#The_Core_Libraries we see that many are maintained by "GHC HQ". But the plain fact is that GHC HQ is not up to the task, especially now that Simon M has moved on to Facebook. To be absolutely explicit, I'm worried that decision making may get stuck because I don't have the capacity to participate, lead, drive, propose, and ultimately make a decision. So there's a decision-making vacuum for the "GHC HQ" libraries. If that's the case, then the best thing is for GHC HQ to get out of the way! Is that what others feel, or are you all happy? My proposal would be to form a Library Tsars committee, that * Takes ownership of the "GHC HQ" libraries * Also owns any global library issues; ones that can't be resolved by a single maintainer Like any maintainer the Library Tsars would be expected to follow the guidance on the wiki http://www.haskell.org/haskellwiki/Library_submissions#Guidance_for_maintai… (responsiveness, consultation, etc). But they could actually decide things. One other thing. I'd certainly consider well-argued proposals for changing GHC to better support backward compatibility in the face of library change. One such proposal was the "class alias" story, but that was a big, complex general mechanism (and arguably big benefits). Because of its complexity it is currently stalled. But there may be other much more modest things we could do to help; the question about ad-hoc deprecation of Monad without Functor is a small, highly-specific, ad-hoc idea. Simon

17 24

ANN: prelude-safeenum
by wren ng thornton 31 May '13

31 May '13

-------------------------------------------- -- prelude-safeenum 0.1.0 -------------------------------------------- The prelude-safeenum package offers a safe alternative to the Prelude's Enum class in order to render it safe. While we're at it, we also generalize the notion of enumeration to support types which can only be enumerated in one direction. -------------------------------------------- -- Description -------------------------------------------- The prelude-safeenum package offers an alternative to the notion of enumeration provided by the Prelude. For now it is just a package, but the eventual goal is to be incorporated into haskell prime. Some salient characteristics of the new type-class hierarchy are: * Removes partial functions: The Haskell Language Report defines pred, succ, fromEnum, and toEnum to be partial functions when the type is Bounded[1], but this is unacceptable. The new classes remove this problem by correcting the type signatures for these functions. * Generalizes the notion of enumeration: Rather than requiring that the type is linearly enumerable, we distinguish between forward enumeration (which allows for multiple predecessors) and backward enumeration (which allows for multiple successors). * Adds new functions: enumDownFrom, enumDownFromTo One of the big problems with the partiality of pred is that there is no safe way to enumerate downwards since in the border case (enumFromThen x (pred x)) will throw an error rather than evaluating to [x] as desired. These new functions remove this problem. * Removes the requirement that the enumeration order coincides with the Ord ordering (if one exists). Though, of course, it's advisable to keep them in sync if possible, for your sanity. * Ensures that the notion of enumeration is well-defined: This much-needed rigor clarifies the meaning of enumeration. In addition, it rules out instances for Float and Double which are highly problematic and often confuse newcomers to Haskell. Unfortunately, this rigor does render the instance for Ratio problematic. However, Ratio instances /can/ be provided so long as the base type is enumerable (and Integral, naturally); but they must be done in an obscure order that does not coincide with Ord. * The obscure order required for well-defined enumeration of Ratio is provided. [1] <http://www.haskell.org/onlinereport/haskell2010/haskellch6.html#x13-1310006…> -------------------------------------------- -- Links -------------------------------------------- Homepage: http://code.haskell.org/~wren/ Hackage: http://hackage.haskell.org/package/prelude-safeenum Darcs: http://community.haskell.org/~wren/prelude-safeenum Haddock (Darcs version): http://community.haskell.org/~wren/prelude-safeenum/dist/doc/html/prelude-s… -- Live well, ~wren

4 4