+1 It is about time we finally ripped off this bandaid. I look forward to the day when I can shed half of the combinators I write in some libs. -Edward On May 16, 2013, at 10:19 AM, David Luposchainsky wrote:

On 2013-05-16 16:09, Bas van Dijk wrote:

...

Note that I already did this once as part of: http://hackage.haskell.org/trac/ghc/ticket/4834 However, that never got merged.

That's certainly going to be useful, although the patches may be hard to use due to their age now.

I don't want to make this discussion about how useful/probable the new hierarchy proposal change would be, but now that there's a new Haskell Prime team, I thought it would be a good time to get unecessary obstacles out of the way before we even try. If adding Applicatives to GHC works out, we'll have to test how much of Hackage requires similar fixes, and when that is satisfyingly patched up, we can begin to think about retrying your proposal.

David

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

I'd also like to show my support for this, so another +1. - ocharles

+1 On Thu, May 16, 2013 at 5:44 PM, John Wiegley wrote:

+1

-- John Wiegley FP Complete Haskell tools, training and consulting http://fpcomplete.com johnw on #haskell/irc.freenode.net

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

+1 On May 17, 2013, at 8:10 AM, Henning Thielemann wrote:

On Thu, 16 May 2013, David Luposchainsky wrote:

...

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.

+1

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

[Maybe] this would be better discussed on the ghc-devs@ list I thought that as well, but SPJ said this might be a better place, as it mostly concerns the base libraries. Since the discussion started here, I

Ian, think we shouldn't change lists. (Maybe if individual problems arise those could be discussed individually over there.)

...

The idea behind this is making GHC future-proof for changing Applicative to be a superclass of Monad.

I don't think that it helps with this, for 2 reasons:

1. The next time someone adds a Monad, the chances are that they will not think to add the other instances

2. You can't build GHC version X with GHC version Y, where Y > X. Therefore should Applicative become a superclass of Monad, any GHC that has that change would not be able to compile older GHCs (which perhaps are missing Applicative instances) anyway. I think this is actually an argument in favour of adding the instances. If the new hierarchy is introduced, old versions will fail to compile, yes, but only unless they have the instances in them already! Suppose 7.8 includes all instances as proposed, and we're going up to 7.14 in a couple of years, and 8.0 introduces the new hierarchy. Everything down to 7.8 will be compilable by 8.0, and most importantly 7.8 will in turn be able to compile GHC < 7.8. From how I see it, adding

That's a valid point. However, I think most people are aware of the issue, so that most fresh code is created appropriately. This is of course just idealistic speculation. One thing I could imagine would be adding a compiler warning for missing Applicative instances, but then again, this is beyond the scope of this proposal (and my Haskell abilities). The manual way of ensuring no non-Applicatives are introduced is of course manual checking, which is a very easy task ("move Applicative to Prelude, fix complaints, move Applicative back"). (Luckily, this is within my abilities) :-) the instances is the only possible way of not breaking backwards compatibility completely, and doing so earlier simplifies the process. David

On 2013-05-17 20:48, Ian Lynagh wrote: Ian,

Ah, so you're talking about the GHC code /and/ all of the libraries that come with GHC? I'd be in favour of adding the instances to the libraries. When I say "GHC" here I mean "everything that comes with GHC and is needed to compile it", more specifically what 'git clone; sync-all get' downloads.

...

Suppose 7.8 includes all instances as proposed, and we're going up to 7.14 in a couple of years, and 8.0 introduces the new hierarchy. Everything down to 7.8 will be compilable by 8.0

No, it won't. Unrelated to this proposal, you can't build GHC version X with GHC version Y, where Y > X. Oh, I thought what you said was a counter argument because of compatibility issues. In that case you probably meant the change is redundant at this point, which is certainly true for all practical purposes. However, I think it's important that we keep an track of how many changes would be necessary in case the new hierarchy is introduced, and adding those early on will save a ton of work later. This holds for GHC now, and then in the next step for Hackage. In an ideal world, changing the hierarchy (moving a couple of lines from Applicative to Prelude) breaks no code except issuing "redundant import of Applicative" warnings maybe, and the goal of my efforts here is to get as close as possible to that.

David