May 2013 - Libraries - Haskell.org

suggestion: A common type class for mutable variables
by Petr Pudlák 10 Jun '13

10 Jun '13

Dear Haskellers, I noticed that there is no common typeclass that would unify STRefs and IORefs. We already have MArray for ST(U)Arrays and IO(U)Arrays, so why not for references as well? This would allow writing generic code that can use both ST- and IO-based variables. I've found that there is a package that provides such a type class: http://hackage.haskell.org/package/reference I'd suggest to add similar functionality to base, perhaps with some different wording - I'd rather use Data.MRef (as "mutable reference"). If there is some interest in it, I'd prepare a concrete code for consideration. Best regards, Petr Pudlak

6 17

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 31 May '13

31 May '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 30 May '13

30 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

Re: 2014 Applicative => Monad proposal
by David Luposchainsky 30 May '13

30 May '13

Hey everyone, here's a short summary of what's happened during the AMP's first week: - Adding `join` to the Monad typeclass introduces a cyclic dependency, leading to an infinite loop if the function definitions are forgotten. Until this is solved, the `join` part of the proposal may not be a good idea. Ticket #7633 solves this problem by introducing compiler warnings if the minimal complete definition is not met. Looking at the Trac page, it's probably going to be in HEAD quite soon. - Apart from the `join` issue, everyone seems to be in favor of the AMP as proposed. (+19/-0 according to Ben's writeup) - A `Pointed` typeclass discussion emerged from the AMP thread with mixed opinions. If necessary, this should be made a separate proposal. - I was asked about MonadFail by multiple people via email. Again, the reason this is not considered in the AMP is that it is orthogonal to the proposed changes; the only similarity is that it changes things in the same typeclass we're already editing. So long, David

1 0

ANN stm-chans 2.1 / 3.0
by wren ng thornton 30 May '13

30 May '13

-------------------------------------------- -- stm-chans 2.1 / 3.0 -------------------------------------------- The stm-chans package offers a collection of channel types, similar to Control.Concurrent.STM.{TChan,TQueue} but with additional features. -------------------------------------------- -- Changes (since 2.0.0) -------------------------------------------- By popular demand, the functions newBroadcastTMChan{,IO} have been added. However, these rely on newBroadcastTChan{,IO} which are only available in stm >= 2.4 and do not appear to be replicable using the public API of stm < 2.4. Thus, the minimum version of stm is now 2.4, which obviates all the compatibility modules. Version 2.1.0 adds the new functions and issues deprecation warnings about using the compatibility modules. This version is just to help people transition. If you can use this version without warnings (i.e., you don't use the Compat modules directly) then you should be able to use version 3.0 as well. Version 3.0 removes the compatibility modules. -------------------------------------------- -- Long description -------------------------------------------- In particular stm-chans offers the following data types: * Control.Concurrent.STM.TBChan: Bounded FIFO channels. When the channel is full, writers will block/retry. This ensures that the writers do not get too far ahead of the readers, which helps to make sure that memory and cpu resources are used responsibly. * Control.Concurrent.STM.TMChan: Closeable FIFO channels. * Control.Concurrent.STM.TMQueue: Closeable FIFO queues. Like TChan (Maybe a) but with a monotonicity guarantee that once Nothing is returned all future reads will be Nothing as well. * Control.Concurrent.STM.TBMChan: Bounded Closeable FIFO channels. * Control.Concurrent.STM.TBMQueue: Bounded Closeable FIFO queues. Combines the capabilities of TBChan and TMChan. -------------------------------------------- -- Links -------------------------------------------- Homepage: http://code.haskell.org/~wren/ Hackage: http://hackage.haskell.org/package/stm-chans Darcs: http://community.haskell.org/~wren/stm-chans Haddock (Darcs version): http://community.haskell.org/~wren/stm-chans/dist/doc/html/stm-chans -- Live well, ~wren

1 0