On 03/02/2011 15:54, Stephen Tetley wrote:

I'd contend the proposal is too disruptive to be independent of a language revision, so I'd vote no on the proposal as it stands.

What do you mean by "independent of a language revision"? The idea is that, if accepted, this will be proposed for Haskell'.

I agree in principle that these should be split out into separate proposals, but it should be done careful, as some of them only make sense once others have been resolved. (e.g. Removing (>>) from monad is only a good idea if Applicative is made a superclass because then (*>) makes it redundant). -Edward Kmett On Thu, Feb 3, 2011 at 9:42 AM, Sittampalam, Ganesh < ganesh.sittampalam@credit-suisse.com> wrote:

John Smith wrote:

...

On 03/02/2011 15:54, Stephen Tetley wrote:

...

I'd contend the proposal is too disruptive to be independent of a language revision, so I'd vote no on the proposal as it stands.

What do you mean by "independent of a language revision"? The idea is that, if accepted, this will be proposed for Haskell'.

So are you saying that acceptance should be conditional on the language change? If so I think the part that is a language change should be made independent of the rest. If accepted by Haskell' it would be implicit that the libraries would have to follow.

I also think that the proposal in general is too disruptive at this stage. But we shouldn't abandon the idea of improving things completely. Looking at the current version on the wiki page linked from the proposal (http://haskell.org/haskellwiki/Functor-Applicative-Monad_Proposal), there are several different changes in the one proposal:

(1) renaming fmap -> map (2) adding join to Monad (3) removing (>>) from Monad (4) moving fail to MonadFail (this is a language change) (5) adding Applicative as a superclass of Monad .. and maybe anything else I missed

If you would separate those out into separate items for discussion, I think it would be easier to reach consensus on each part. All the accepted pieces could still be scheduled together to minimise disruption.

Cheers,

Ganesh

=============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html

===============================================================================

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

On 03/02/2011 16:42, Sittampalam, Ganesh wrote:

John Smith wrote:

...

On 03/02/2011 15:54, Stephen Tetley wrote:

...

I'd contend the proposal is too disruptive to be independent of a language revision, so I'd vote no on the proposal as it stands.

What do you mean by "independent of a language revision"? The idea is that, if accepted, this will be proposed for Haskell'.

So are you saying that acceptance should be conditional on the language change? If so I think the part that is a language change should be made independent of the rest. If accepted by Haskell' it would be implicit that the libraries would have to follow.

I also think that the proposal in general is too disruptive at this stage. But we shouldn't abandon the idea of improving things completely. Looking at the current version on the wiki page linked from the proposal (http://haskell.org/haskellwiki/Functor-Applicative-Monad_Proposal), there are several different changes in the one proposal:

(1) renaming fmap -> map (2) adding join to Monad (3) removing (>>) from Monad (4) moving fail to MonadFail (this is a language change) (5) adding Applicative as a superclass of Monad .. and maybe anything else I missed

If you would separate those out into separate items for discussion, I think it would be easier to reach consensus on each part. All the accepted pieces could still be scheduled together to minimise disruption.

Cheers,

Ganesh

=============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================

This proposal (as in the patches attached to the ticket) is only (5). The wiki page is much broader than this.

John Smith wrote:

On 03/02/2011 16:42, Sittampalam, Ganesh wrote:

...

(1) renaming fmap -> map (2) adding join to Monad (3) removing (>>) from Monad (4) moving fail to MonadFail (this is a language change) (5) adding Applicative as a superclass of Monad .. and maybe anything else I missed

This proposal (as in the patches attached to the ticket) is only (5). The wiki page is much broader than this.

The ticket is rather confusing, in that it says "The proposal is detailed in the wiki". I see the followup comment that the attached patches "only implement the new Applicative => Monad hierarchy, but do not change any names (as proposed on the wiki page)", but that doesn't indicate the status of the other things one way or the other. Also, the relevant attached patch seems to at least add join to Monad: http://hackage.haskell.org/trac/ghc/attachment/ticket/4834/base_new_mona d_hierarchy.dpatch Cheers, Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================

John Smith wrote:

On 04/02/2011 09:50, Sittampalam, Ganesh wrote:

...

John Smith wrote:

...

On 03/02/2011 16:42, Sittampalam, Ganesh wrote:

...

...

(1) renaming fmap -> map (2) adding join to Monad (3) removing (>>) from Monad (4) moving fail to MonadFail (this is a language change) (5) adding Applicative as a superclass of Monad .. and maybe anything else I missed

This proposal (as in the patches attached to the ticket) is only (5). The wiki page is much broader than this.

The ticket is rather confusing, in that it says "The proposal is detailed in the wiki". I see the followup comment that the attached patches "only implement the new Applicative => Monad hierarchy, but do not change any names (as proposed on the wiki page)", but that doesn't indicate the status of the other things one way or the other.

Also, the relevant attached patch seems to at least add join to Monad:

http://hackage.haskell.org/trac/ghc/attachment/ticket/4834/base_new_mo

...

na d_hierarchy.dpatch

Ticket descriptions are immutable, so I couldn't update it when the patch and wiki diverged. There is a section in the Wiki page dedicated to describing the proposed patch.

OK, I see. Might be worth adding a note to that effect to the top of the wiki page. BTW I said when you first proposed this that I'm opposed until we have language support that makes it easier to add new superclasses non-disruptively, and that remains the case. Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================

On 03/02/2011 17:41, Roman Leshchinskiy wrote:

John Smith wrote:

...

On 03/02/2011 15:54, Stephen Tetley wrote:

...

I'd contend the proposal is too disruptive to be independent of a language revision, so I'd vote no on the proposal as it stands.

What do you mean by "independent of a language revision"? The idea is that, if accepted, this will be proposed for Haskell'.

As someone (Simon M?) quite correctly pointed out, if we do want to change the standard libraries then this should be done in one big revision. Lots of small changes which break vast amounts of existing code aren't a good idea, IMO.

Roman

The idea is that if this proposal is accepted for GHC 7.2, other proposals can be put forward for the same version. All the changes should land in the same release.

I agree. Maybe since everyone agrees this needs changing, but nobody can agree on how, it'd be worth electing a committee of "benevolent dictators" that we trust to actually just get the stuff done without all the bikeshedding that happens if this stuff happens on the mailing list? Dan On Fri, Feb 4, 2011 at 9:55 AM, Roman Leshchinskiy wrote:

John Smith wrote:

...

The idea is that if this proposal is accepted for GHC 7.2, other proposals can be put forward for the same version. All the changes should land in the same release.

This change requires an update of the Haskell report. Tying Prelude changes to the libraries process and GHC releases doesn't seem right to me. At the very least, I would expect such a proposal to include corresponding patches to the report.

In general, a piecemeal redesign of the Prelude is IMO a very bad idea. If it needs to be redesigned then this should be done in one big sweep to minimise the number of times we break people's code and also to have a chance to ensure that the changes are somewhat consistent.

BTW, http://hackage.haskell.org/trac/ghc/ticket/4834 contains 3 patches, one for GHC, one for Happy and one for base. IIUC, the first two don't really depend on the base patch and should perhaps be integrated into the code bases now, regardless of the outcome of this discussion.

Roman

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

On 3 February 2011 14:24, John Smith wrote:

On 03/02/2011 15:54, Stephen Tetley wrote:

...

I'd contend the proposal is too disruptive to be independent of a language revision, so I'd vote no on the proposal as it stands.

What do you mean by "independent of a language revision"? The idea is that, if accepted, this will be proposed for Haskell'.

The current proposal is a libraries change against "Base" which is roughly speaking means it is a proposal to change GHC 7.0.2. If the change were made for GHC 7.0.2, code and equally importantly books would be out-of-date. My feeling is that a change of this magnitude should be a change to the language standard i.e. Haskell 2012 (Prelude is covered by the standard). Currently Haskell' asks for changes to be implemented in a compiler before they are considered, I'd argue that whilst this is correct for language extensions it is not necessarily the best situation for library changes where the balance is different: Language extension - the weight of effort borne by the developers of the first implementation to prove the concept. Library change - the weight of effort is borne by the whole community (revising code, new editions of books, etc.)

Ian Lynagh wrote:

On Thu, Feb 03, 2011 at 03:50:38PM +0000, Stephen Tetley wrote:

...

On 3 February 2011 14:24, John Smith wrote:

...

On 03/02/2011 15:54, Stephen Tetley wrote:

...

I'd contend the proposal is too disruptive to be independent of a language revision, so I'd vote no on the proposal as it stands.

What do you mean by "independent of a language revision"? The idea is that, if accepted, this will be proposed for Haskell'.

The current proposal is a libraries change against "Base" which is roughly speaking means it is a proposal to change GHC 7.0.2.

7.2.1, not 7.0.2.

...

My feeling is that a change of this magnitude should be a change to the language standard i.e. Haskell 2012 (Prelude is covered by the standard).

I'm sure we discussed this recently, but I can't find it now. Anyway, my understanding is that the consensus is that the libraries process will be used even for changes to libraries that require changes in the (next version of the) report.

Even in the case of splitting fail out of Monad, which would require that do expressions have different types depending on whether they contain incomplete pattern matches or not? Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================

Tyson Whitehead wrote:

On February 3, 2011 11:15:39 Sittampalam, Ganesh wrote:

...

Even in the case of splitting fail out of Monad, which would require that do expressions have different types depending on whether they contain incomplete pattern matches or not?

You could also opt for making do always require MonadFail in the interest of consistency, even when it wouldn't be strictly required.

How much value would the separate class have in that case? Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================

Tyson Whitehead wrote:

On February 3, 2011 11:36:42 Sittampalam, Ganesh wrote:

...

Tyson Whitehead wrote:

...

You could also opt for making do always require MonadFail in the interest of consistency, even when it wouldn't be strictly required.

How much value would the separate class have in that case?

I guess that would be the applicative style programming. :)

Another option might be that failure from incomplete pattern matching should maybe just use "error" as is done with the rest of the language.

Does anyone have any feeling regarding whether people are actually coding code that depends on pattern matching falling through to custom fail code?

I think it's quite common in the case where the Monad is a MonadPlus. I certainly use that feature. Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================

On Thursday 03 February 2011 19:00:53, malcolm.wallace wrote:

...

I think it's quite common in the case where the Monad is a MonadPlus. I certainly use that feature   As a specific instance of MonadPlus, nearly all monadic parser-combinator libraries rely on this.

Also it's pretty common for filtering in list comprehensions.

On 04/02/2011 13:15, Simon Marlow wrote:

We should have a major libraries revision soon and redesign everything. I'm thinking we start it sometime in the next few months, aiming to get it into a GHC release in late 2012. We'll continue to support Haskell2010 (and Haskell2012 if appropriate), but to what extent those will be compatible with the new libraries depends on what changes we make.

Cheers, Simon

Are GHC central going to take the lead in this? A major overhaul isn't going to happen without someone who can drive the process through to completion.