- Libraries - Haskell.org

ANN: Haskell Platform 2013.2.0.0
by Mark Lentczner 28 May '13

28 May '13

On behalf of the Haskell Platform team, I'm happy to announce the release of Haskell Platform 2013.2.0.0 *featuring* GHC 7.6.3 52 packages 650+ public modules 4 tools *New packages this release:* attoparsec case-insensitive hashable unordered-containers *and a major upgrade to* OpenGL and GLUT Get it now: Download Haskell Platform <http://www.haskell.org/platform/index.html> — for Windows <http://www.haskell.org/platform/windows.html> — for Mac OS X <http://www.haskell.org/platform/mac.html> — for Linux <http://www.haskell.org/platform/linux.html> (distributions updating soon) *N.B.: You will likely need to explicitly re-fresh those links when visiting in your browser - those pages tend to get cached for very long periods of time.* — Mark "platform wrangler" Lentczner

1 0

Re: Pointed [Re: 2014 Applicative => Monad proposal]
by Gabriel Gonzalez 25 May '13

25 May '13

-1 on Pointed/Apply/Bind These are of very limited utility and we don't need these three instances cluttering up instance lists and distracting the user from more important instances. If you're going to make things less monomorphic then you need to be more judicious about the type classes you choose.

1 0

Re: foldable flexible bridges (putting foldable+traversable in prelude) Re: Burning bridges
by wren ng thornton 25 May '13

25 May '13

On 5/22/13 1:12 AM, Mark Lentczner wrote: > 3) Stability is very important to adoption of a language. People are very > influenced by their first impressions of a system. We seem perilously close > to "death by continuous little paper cuts" here: I saw the catch debacle > snag tons of people and projects in tiny hiccups. If you were a newcomer to > Haskell (experienced engineer or no) and you ran into this, I bet it was a > turn off. FWIW, this is exactly why I made the "Burning Bridges" post. We've had a number of rather serious papercuts of late. The Prelude.catch one was rather annoying, especially because of its interaction with various automatic tools. The Show =/=> Num one also caused a flurry of version bumps and breakages. And of course there are others. These are all base/core issues ---I'm completely ignoring things like mtl-1 vs mtl-2, or parsec-2 vs parsec-3, or the iteratee libraries. I am not opposed to change (obviously). I like that Haskell evolves. But the slow trickle of major breaking changes is not so nice. Nor is the accumulation of warts due to this slow tricking of major changes. This is why I suggest aiming for a major breakage in order to fix as much as we can in one fell swoop. Yes, breakage will happen; but breakage is already happening with every new version of GHC! We continually hide our heads in the sand and pretend that this slow trickle of major changes isn't happening, but it is. And it turns off both newcomers trying to get their footing on shifting sands, as well as folks who want to deploy Haskell with the same sort of stability as they get from deploying Perl, Python, or Ruby. -- Live well, ~wren

4 4

Adding Applicative/Functor instances to all Monads in GHC
by David Luposchainsky 24 May '13

24 May '13

Hello everyone, I recently went through GHC's source, and discovered there are quite a few instances of Monad that don't have Functor or Applicative instances. Fixing this is very easy by adding the standard instances (pure = return etc.), and will not break code. There is one exception to this: Hoopl defines its own (<*>). However, since it does not seem to have any packages depend on it otherwise, renaming this operator is also easily done (the thing is only used ten times or so). I called it (<*|*>) to complement (|*><*|), but naming should be the least important issue here. Small piece of backstory: The idea behind this is making GHC future-proof for changing Applicative to be a superclass of Monad. However, I think adding the Applicative instances is a good idea regardless of whether this will ever happen, so that's the only thing I'm proposing right now. Greetings, David

12 16

Re: 2014 Applicative => Monad proposal
by wren ng thornton 24 May '13

24 May '13

On 5/24/13 11:20 AM, Edward Kmett wrote: > For the record I'm actually -1 on including Pointed. > > My experience is that there are very few uses for the class that permit you > to reason about your code without one-off ad hoc reasoning based on the > particular instance you are given. Now, the Apply and Bind classes on the > other hand... =) Though, to be fair, I couldn't seriously propose including > either of those, either. Even I can't be bothered to instantiate them all > the time! FWIW, as things stand, I'm also -1 for Pointed. Pointed doesn't really have much meaning on its own, so I think it's more helpful to invert the hierarchy as Kmett has done and have Apply/Bind classes as the generalization of Applicative/Monad. More to the point, the Pointed proposal doesn't meet the AMP goals of gentility and compatibility. And the controversy renders it dubious for inclusion in the proposal to make a unified compatibility-breaking change to clean up the long-standing complaints. -- Live well, ~wren

2 1

Re: Burning bridges
by wren ng thornton 24 May '13

24 May '13

On 5/21/13 2:22 AM, Simon Peyton-Jones wrote: > | 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. > ... > | 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. > > I'm not sure what you are proposing, concrete, by "fork Haskell". Concretely: I propose making a major library/Prelude revision in order apply the various changes we've talked about forever but never do anything about because of compatibility concerns. In particular, the goal is to remove warts and streamline things, not to make any "language" changes, per se. Backward compatibility should be of no concern in enacting this proposal (though, of course, flagrant/unnecessary changes should be avoided). Think of it like the Python-2 to Python-3 transition, or similar. Below is a tentative list of such changes. This is offered as the beginning of a discussion rather than a final proposal per se. As part of the proposal, we should solicit feedback from the community at large (not just on this list) as well as the haskell' committee in order to ensure that we do as much as we can to clean things up. In particular, it'd be good to assemble the list of complaints/proposals prior to trying to resolve the details of any particular one, similar to the haskell' process I suppose. * Applicative => Monad. * Unify pure/return. Depends on Applicative => Monad. * Add join method to Monad, with default definitions for join/(>>=). * Remove fail from Monad (add Monad => MonadFail, if desired). * Make the (<$) method of Functor more official. When starting up ghci-7.6.1, it only gives (<$) qualified as (GHC.Base.<$) * Replace Enum by type classes which do not require partial functions. (I have a more concrete proposal for this one, which I'll put on Hackage in the next week or so.) This isn't a hot topic like the others, but it's part of the general concern about having partial functions as standard/required parts of the language. * Remove from the Prelude things which are not required for resolving circularity. This is highly controversial, but I think it would help minimize future issues. If desired, in order to reduce imports, we could have an Interlude which serves the kitchen-sink role of the current Prelude but which requires an explicit import rather than being implicit like the Prelude is. * Remove the list-monomorphic versions of Foldable/Traversable functions. And/or export them from a separate PegagogicalHaskell module for learners to use, such that they do not materially affect intermediate/advanced Haskellers. * This is a bit off-proposal, but: do not have every Control.Monad.* module re-export Control.Monad. Modules like Control.Monad.Foo should only export Foo-specific things; if people want the general tools they can import Control.Monad itself. This is related to the pain of standardizing on Foldable/Traversable. * Clean up the Monoid class, add a Semigroup superclass, etc. There was a lot of discussion about this a while back. We came up with a fair solution, but it'd be nice to revisit the discussion and tighten things up while we're at it. I'm sure there are others I'm forgetting, which is why this is only a suggested list. One thing I thing we should _not_ do is try to tackle the numeric hierarchy (except perhaps for cleaning up non-numeric superclasses like Eq, Show, etc). As much as I'd like to see the numeric hierarchy improved, the design space is very large and the solution is far from clear. Attempting to address that issue now would derail the conversation from the above changes and the general goal of streamlining and removing warts. > I assume you guys have talked this to death, but is there no way to move on, while leaving a backward-compatible API? The big problems with backward compatibility are (a) the standard type classes ---especially their superclass constraints---, and (b) the Prelude. Unfortunately, both of these are baked into the language in such a way that it's extremely difficult to change them without breaking things. One of the reasons the above changes haven't been made already is due to holding out hope for finding some way to make the changes without losing backward compatibility. However, we haven't found any good way to do that over the years, and there are no promising new leads at the moment. -- Live well, ~wren

4 3

Re: foldable flexible bridges (putting foldable+traversable in prelude) Re: Burning bridges
by wren ng thornton 23 May '13

23 May '13

On 5/23/13 8:27 PM, John Lato wrote: > I agree with Mark and wren; it would be better to fix several of these > issues at once. I think it would be helpful to know how frequently > community members would tolerate breaking changes like this. For myself, I > think 2-4 years seems right, with 2 on the fast side. My impression is > there's a lot of support for rolling breakages, but maybe that's not the > case? I think 2--4 years is a good rate for this sort of thing. -- Live well, ~wren

1 0

Re: Burning bridges
by wren ng thornton 23 May '13

23 May '13

On 5/22/13 8:39 PM, Ivan Lazar Miljenovic wrote: > I don't know if I'd go quite _that_ for as Malcolm for the weightings > for the different proposals... > > But I was speaking with a few other tutors of an introductory > CS/programming course that uses Haskell (note: it's teaching > programming with Haskell, not teaching Haskell per se: for example, > all pattern matchings must be done with case statements as the > lecturer considers top-level pattern matching a Haskell-specific > quirk) about these proposals... This is why I propose the general scheme of: * minimize what's in the Prelude, thereby reducing clashes and the need for import...hiding * add an Interlude for those who really want the kitchen sink. The Interlude would pull from Data.Foldable, Data.Traversable, etc. * add PedagogicalHaskell for those who want the monomorphic versions. It should be easy to explain that this is for pedagogical purposes only and that the Interlude (or the underlying modules) provide generalized versions. -- Live well, ~wren

1 0

Re: Burning bridges
by wren ng thornton 23 May '13

23 May '13

+1 Generalise Prelude.mapM etc +1 Remove Prelude.mapM etc -1 Add more monomorphic variants to Prelude (e.g. whenJust) -1 Nothing -- Live well, ~wren

1 0

Re: 2014 Applicative => Monad proposal
by Stephen Tetley 23 May '13

23 May '13

(+1) I would like to see this proposal go forward. Though I've previously expressed a preference for Monad/Applicative changes being ratified as part of a language revision - I've changed my mind in the last few days. Thanks to both David in this thread and Simon Peyton-Jones in the "Making Decisions" thread for constructive proposals, that hopefully will both see fruition.

4 3