From elliot.robinson at argiopetech.com  Thu Oct  1 02:26:12 2015
From: elliot.robinson at argiopetech.com (Elliot Robinson)
Date: Wed, 30 Sep 2015 22:26:12 -0400
Subject: [unix] POSIX Message Queue support
Message-ID: <20151001022612.GA21522@suwako.argiopetech.com>

We've had a request for info regarding message queue support in `unix` [0]. The related headers are currently listed in `System/Posix.hs` under the "Unsupported interfaces" category. Is the community aware of a reason that we have chosen not to support this interface going forward, or is this an artifact from when the library was originally ported (late 2002 by Simon Marlow) which we can now ignore?

--
Elliot Robinson
GPG Key: 9FEDE59A

 [0] https://github.com/haskell/unix/issues/47

From lemming at henning-thielemann.de  Thu Oct  1 16:22:15 2015
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Thu, 1 Oct 2015 18:22:15 +0200 (CEST)
Subject: REMOVED pragma (Was: Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`)
In-Reply-To: <CAMgWh9tUGCZ34J+Hf7eRJAVNWdxJRZwYnsQX_V5KsZV05oc9SA@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <CAMgWh9uZqCh4aerMTZ6aFh8mCvcVuHTqAWQchxZSqdmR2AchWw@mail.gmail.com>
 <56086C23.2060101@gmail.com>
 <8F1DB6DE-DFC3-4EAD-AD2C-00A95A50A028@cis.upenn.edu>
 <CAMgWh9tUGCZ34J+Hf7eRJAVNWdxJRZwYnsQX_V5KsZV05oc9SA@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1510011819380.7958@sputnik>


On Sun, 27 Sep 2015, David Feuer wrote:

> On Sep 27, 2015 9:56 PM, "Richard Eisenberg" <eir at cis.upenn.edu> wrote:
> >
> > I like this idea -- I, for one, often forget to consider the effect legacy written material has. But if we're doing
> this for Monad, why not just come up with a pragma so that the magic doesn't have to be baked in? As in, witness the new
> definition for Monad:
> >
> > > class Applicative m => Monad m where
> > >? ?...
> > >? ?{-# REMOVED return "The `return` method has been removed from Monad. Use `pure` in Applicative instead" #-}
> >
> > (Please fix my warning text.)
> >
> > We people with direct access to GHC might not be the only ones who want to refactor a method out from a class.
> 
> That's an excellent idea, and I think it makes sense to offer it at the module level as well as the class level. Just
> change DEPRECATED to REMOVED when it's actually removed. Speaking of such, has the deprecated export proposal made any
> headway?

I like the idea of a REMOVED pragma very much. After a deprecated function 
is actually removed it is hard to find out how to fix the code. I often 
ignore DEPRECATED warnings because respecting them would break my code for 
older GHC versions.

From lemming at henning-thielemann.de  Thu Oct  1 17:03:09 2015
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Thu, 1 Oct 2015 19:03:09 +0200 (CEST)
Subject: Monad of no `return` Proposal (MRP): Moving `return` out of
 `Monad`
In-Reply-To: <87io6zmr2x.fsf@gnu.org>
References: <87io6zmr2x.fsf@gnu.org>
Message-ID: <alpine.DEB.2.02.1510011830520.7958@sputnik>


On Thu, 24 Sep 2015, Herbert Valerio Riedel wrote:

> Consequently, the `Monad` class is left with a now redundant `return`
> method as a historic artifact, as there's no compelling reason to
> have `pure` and `return` implemented differently.
>
> Traditionally, `return` is often used where `pure` would suffice
> today, forcing a `Monad` constraint even if a weaker `Applicative`
> would have sufficed.

I do not see why this proposal is necessary and urgent. Over the past 
years several redundant methods where added to type classes in order to 
allow for optimized implementations. Without much investigation I remember 
Foldable.sum, Foldable.product, ..., Applicative.*>, Applicative.<*, 
Functor.<$, Bits.zeroBits and discussions about Monad.join. Although I 
think that it is never possible to implement 'return' more efficiently 
than 'pure', we could pretend for now that it is possible. :-) At least, 
leaving 'return' does not hurt much.

My practical concern is that the change will break every current Monad 
instance for no benefit and I would not be able to write code that works 
for current and past GHC versions.


> As a result, language extensions like `ApplicativeDo`[3] have to
> rewrite `return` to weaken its `Monad m =>` constraint to
> `Applicative m =>` in order to benefit existing code at the cost
> of introducing magic behavior at the type level.

Like Henrik Nilsson, I wonder why people cannot replace 'return' by 'pure' 
if they want to make use of ApplicativeDo. I think the people who want a 
new feature should adapt their code. Why should I break my Monad instances 
instead?


> Consequently, it is possible to write forward-compatible instances
> that are valid under this proposal starting with GHC 7.10/`base-4.8`.

Because the completely unrelated bug [1] affects several of my packages, I 
can use forward-compatible instances only starting with GHC-8.0.

Bugs like this one also underline why it is so important to write code 
that works across multiple versions of GHC. Otherwise it's easily possible 
that a program depends on a set of packages that cannot be compiled by any 
GHC version.

If you are very keen to remove 'return' I would ask you to wait some more 
release cycles of GHC.


[1] https://ghc.haskell.org/trac/ghc/ticket/10009

From dluposchainsky at googlemail.com  Thu Oct  1 19:46:44 2015
From: dluposchainsky at googlemail.com (David Luposchainsky)
Date: Thu, 1 Oct 2015 21:46:44 +0200
Subject: Monad of no `return` Proposal (MRP): Moving `return` out of
 `Monad`
In-Reply-To: <alpine.DEB.2.02.1510011830520.7958@sputnik>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
Message-ID: <560D8DA4.2080706@gmail.com>

On 01.10.2015 19:03, Henning Thielemann wrote:
> Over the past years
> several redundant methods where added to type classes in order to allow for
> optimized implementations.

There's an important difference: *> is redundant, but not superflous. return on
the other hand offers zero new functionality.

> At least, leaving 'return' does not hurt much.

I guess that's a matter of what we want the standard to be. I think it should be
the guideline to "a good Haskell" that compilers should aim to implement. If it
takes GHC a couple of releases to become Report compliant then that's something
I'm OK with.

> My practical concern is that the change will break every current Monad instance
> for no benefit and I would not be able to write code that works for current and
> past GHC versions.

Monad instances written before 7.8. As of 7.10, return is not part of the minimal
definition of Monad anymore, so starting with the current release, you're already
able to write future-proof instances. That said, the issue with GHC < 7.10
remains of course.

> If you are very keen to remove 'return' I would ask you to wait some more release
> cycles of GHC.

Of course! The next release will do nothing but issue (a disable-able) warning
when an instance implements return. Beyond that, who knows, but it surely won't
be breaking half of `cabal build` because of impatience.

Greetings,
David/quchen


From Henrik.Nilsson at nottingham.ac.uk  Fri Oct  2 10:09:21 2015
From: Henrik.Nilsson at nottingham.ac.uk (Henrik Nilsson)
Date: Fri, 02 Oct 2015 11:09:21 +0100
Subject: Monad of no `return` Proposal (MRP): Moving `return` out of
 `Monad`
In-Reply-To: <560D8DA4.2080706@gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
Message-ID: <560E57D1.9060302@nottingham.ac.uk>

Hi all,

I have discussed the monad of no return proposal with
my colleague Graham Hutton: a long-standing member of
the Haskell community, well-known researcher, some 20
years of experience of teaching Haskell to
undergraduate students, and author of one of the most
successful introductory Haskell textbooks there are.

The upshot of this e-mail is a strong collective -2
from us both on particular proposal, and a general call
for much more caution when it comes to breaking changes
that are not critically important.

First, on a general note, there has recently been a
flurry of breaking changes to the (de facto) Haskell
standards. In many cases for very good reasons, but
sometimes it seems more in a quest for perfection
without due consideration for the consequences. It used
to be the case that breaking changes were very rare
indeed. And for good reason.

Right now, the main "measure of breakage" in the
on-line discussions seems to be how many packages that
break in Hackage. Which of course makes sense: the
Hackage repository is very important and such a measure
is objective, as far as it goes.

But we should not forget that breakage can go far
beyond Hackage. For starters, there is *lots* of code
that is not in Hackage, yet critically important to its
users, however many or few they are. There are more
than hundreds of thousands of copies of books out there
where that may break in that examples may no longer
work. And they cannot be changed. There are countless
research papers that may break in the same way. Every
single institution that use Haskell in their teaching
may have to update their teaching materials (slides,
code, lab instructions) for every module that teaches
or uses Haskell. And last but not the least, what
countless of programmers and students have learned
about Haskell over decades, most of whom are *not*
power users who can take these changes in their stride,
may also break.

Now, of course a language has to evolve, and sometimes
breaking backwards compatibility is more or less
essential for the long-term benefit of the language.
But we should not let perfection be the enemy of the
good.

As to this particular proposal, the monad of no return,
it does not seem essential to us, but mostly motivated
by a quest for "perfection" as defined by a very
knowledgeable but in relative terms small group of
people.

One argument put forward was that applicative code that
uses "return" instead of "pure" should get a less
constrained type. But such code is relatively new. The
methods of the Monad class have been return and bind
for some 25 years. So indeed, as Henning Thielemann
wrote: why should not the newer code be adapted and use
"pure" instead? In fact, the use of "pure" in such code
could serve as a quite useful cue that the code is
applicative rather than monadic, especially where
applicative do is employed.

Another reason put forward is support for the
applicative do syntax. But that is, in standard terms,
only a future possibility at this point. Further, the
syntax is arguably rather dubious anyway as it, in
particular to someone with an imperative background,
suggests a sequential reading which is exactly what
applicative is not and why it is useful. So from that
perspective, using the applicative operators directly,
without any syntactic sugar, actually amounts to a much
more transparent and honest syntax, even if a bit more
verbose in some cases.

The bottom line is that it is premature to put forward
support for the applicative do syntax as a rationale
for a non-essential breaking change.

Best regards,

Henrik Nilsson and Graham Hutton

-- 
Henrik Nilsson
School of Computer Science
The University of Nottingham
nhn at cs.nott.ac.uk




This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it. 

Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.


From oleg.grenrus at iki.fi  Fri Oct  2 15:51:44 2015
From: oleg.grenrus at iki.fi (Oleg Grenrus)
Date: Fri, 2 Oct 2015 18:51:44 +0300
Subject: Since notice in instance declarations.
Message-ID: <9E1012B5-20F9-4D0F-AAF6-50C203A9B055@iki.fi>

Dear all,

What you think, if instead of /Since: 4.8.0.0/, we start to use /Since: base-4.8.0.0/.
Adding the package name seems redundant, but on the other hand some haddock
instance lists look weird. For example in Cabal Distribution.Version docs [1] has:

NFData Version -- /Since: 1.3.0.0/

Luckily Cabal is in 1.2x, otherwise /Since: 1.3.0.0/ next to the NFData Version could be
very confusing.

What you think about this new practice?

Greetings,
Oleg Grenrus

[1] http://hackage.haskell.org/package/Cabal-1.22.4.0/docs/Distribution-Version.html#control.i:Version <http://hackage.haskell.org/package/Cabal-1.22.4.0/docs/Distribution-Version.html#control.i:Version>

P.S. also the [1] doesn?t show orphan `Binary Version` instance provided. I hope it was
a temporary glitch in haddock.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151002/fce8b411/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151002/fce8b411/attachment.sig>

From rf at rufflewind.com  Fri Oct  2 16:32:47 2015
From: rf at rufflewind.com (Phil Ruffwind)
Date: Fri, 2 Oct 2015 12:32:47 -0400
Subject: Since notice in instance declarations.
In-Reply-To: <9E1012B5-20F9-4D0F-AAF6-50C203A9B055@iki.fi>
References: <9E1012B5-20F9-4D0F-AAF6-50C203A9B055@iki.fi>
Message-ID: <CADb8sTNRnsYnGbUWRXYYZB9_CBt+YQH+hE0dhowx=MPfd_D_ZA@mail.gmail.com>

Since Haddock now supports the '@since' annotation, it might be better
to implement it in Haddock rather than have everyone do it manually.

https://github.com/haskell/haddock/issues/26

From simonpj at microsoft.com  Fri Oct  2 19:42:07 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 2 Oct 2015 19:42:07 +0000
Subject: Can we simplify Dynamic?
In-Reply-To: <CAJumaK-HAV6Wz04GZx0mzYGPwFzdh9VxjaYLOuopd9Xgw6Wtig@mail.gmail.com>
References: <CAMgWh9tpwoq8yMgOCogoMSXn-4o8DE3X+BD8D3hoUZsy7PEUqQ@mail.gmail.com>
 <CAMgWh9vRtA22WA4LtpsWFhQiCPVtqRH0P7-+fs5EyKP2KiWZZw@mail.gmail.com>
 <CAMgWh9t7Uz6Y4zr129+aQOJSknrfGX5szAuwJZAHAWi4-Cqqdw@mail.gmail.com>
 <CAMgWh9sWuMPfHZVTk0=vwvQhAtxiAuXDzwZy5Z=sQ-yv7VgY=g@mail.gmail.com>
 <CAMgWh9thPGVTizH9MatSB8K9WPkZZfMcU2kWBnejjtoDP0c=Wg@mail.gmail.com>
 <CAMgWh9sYgW2HLEz4SAJ3oz3va+AUN3sfNT1x18b6=gajdcCXPg@mail.gmail.com>
 <CAMgWh9tD450m-GYqbbf7ty9g5K4p72zNmKGNiazjmaZmPG+t5g@mail.gmail.com>
 <CAMgWh9tFNSV5by5b6TnU89zk7xeX=4t0SN1d0agaiUzhD+Z+PA@mail.gmail.com>
 <CAMgWh9s8T1VmJDDNVNSd3BvsvEsegwAm5HS269dxmhhL9nGcYw@mail.gmail.com>
 <CAMgWh9t_h0UnTChnwD+dRJQhkG0gDi_dptodkC1_jOQiG8MuUw@mail.gmail.com>
 <5609B942.5040006@ro-che.info>
 <CAJumaK-HAV6Wz04GZx0mzYGPwFzdh9VxjaYLOuopd9Xgw6Wtig@mail.gmail.com>
Message-ID: <9010cdb10be147ce9e5bbef40aa5c851@DB4PR30MB030.064d.mgd.msft.net>

It seems to be a fairly popular proposal. =)
Indeed.  Ben Price (now at Strathclyde) did a short internship at MSR working on this; see
                https://ghc.haskell.org/trac/ghc/wiki/TypeableT
Dimitrios, Stephanie, Richard, and I are working on a paper about it, which should be out in a couple of weeks.

At that point we?ll be in a position to have a proper core-libraries-committee discussion about the right API etc; I hope we can make the result part of GHC 8.0.

But I want to get the paper out first since it gives a reasonably articulate exposition of the ideas and rationale, so that we all start on the same page.

Simon

From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of Edward Kmett
Sent: 29 September 2015 16:53
To: Roman Cheplyaka
Cc: Haskell Libraries
Subject: Re: Can we simplify Dynamic?

It seems to be a fairly popular proposal. =)

https://mail.haskell.org/pipermail/libraries/2014-August/023633.html<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fmail.haskell.org%2fpipermail%2flibraries%2f2014-August%2f023633.html&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c4a20632c14424882676b08d2c8e5fe0e%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Q8v9rdZ4Q%2bnw7oER7kBQb42HIXiujZOEmkO%2fQPOqe0g%3d>

-Edward

On Mon, Sep 28, 2015 at 6:03 PM, Roman Cheplyaka <roma at ro-che.info<mailto:roma at ro-che.info>> wrote:
I suggested this last year, see this thread
https://mail.haskell.org/pipermail/libraries/2014-March/022287.html<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fmail.haskell.org%2fpipermail%2flibraries%2f2014-March%2f022287.html&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c4a20632c14424882676b08d2c8e5fe0e%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=NllZIb67%2fxgH1fNXfMJ5nsgWm%2bwRpfXEBWt4kPlS9AM%3d>

On 09/29/2015 12:51 AM, David Feuer wrote:
> Currently,
>
> data Dynamic = Dynamic TypeRep Obj
>                deriving Typeable
> where
> type Obj = Any
>
> As a result, all of the operations must be implemented "by hand" using
> unsafeCoerce. The more obvious representation these days would seem to be
>
> data Dynamic where
>   Dynamic :: Typeable a => a -> Dynamic
>
> Most of the operations then become trivial applications of Typeable
> functions.    The only exceptions seem to be  dynApply and dynApp. That
> there are exceptions strikes me as quite unfortunate. The easiest fix is
> inspired by the fact that Data.Dynamic uses
>
> funResultTy :: TypeRep -> TypeRep -> Maybe TypeRep
>
> from Data.Typeable to decide whether to coerce. It seems reasonable to
> add a more informative version, something like
>
> applyTypeable :: (Typeable f, Typeable a) =>
>    proxy f ->
>    proxy a ->
>    (forall b . (Typeable b, f ~ (a -> b)) => r) ->
>    Maybe r
>
> On the other hand, it would be really cool if there were some more
> general way to get type-level information out of Typeable instances,
> pattern matching on the type constructors.


_______________________________________________
Libraries mailing list
Libraries at haskell.org<mailto:Libraries at haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.org%2fcgi-bin%2fmailman%2flistinfo%2flibraries&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c4a20632c14424882676b08d2c8e5fe0e%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Yb6xCqACYgr8gw%2ffKgyGvWooH2vs1S6kriYtUAV8LQg%3d>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151002/40d297ce/attachment-0001.html>

From spam at scientician.net  Fri Oct  2 20:50:35 2015
From: spam at scientician.net (Bardur Arantsson)
Date: Fri, 2 Oct 2015 22:50:35 +0200
Subject: Monad of no `return` Proposal (MRP): Moving `return` out of
 `Monad`
In-Reply-To: <560E57D1.9060302@nottingham.ac.uk>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
Message-ID: <mumqmr$r00$1@ger.gmane.org>

On 10/02/2015 12:09 PM, Henrik Nilsson wrote:
> Hi all,
> 
[--snip--]
> Another reason put forward is support for the
> applicative do syntax. But that is, in standard terms,
> only a future possibility at this point. Further, the
> syntax is arguably rather dubious anyway as it, in
> particular to someone with an imperative background,
> suggests a sequential reading which is exactly what
> applicative is not and why it is useful. So from that
> perspective, using the applicative operators directly,
> without any syntactic sugar, actually amounts to a much
> more transparent and honest syntax, even if a bit more
> verbose in some cases.

"Verbose" is the understatement of the year. There's a lot of code where
ApplicativeDo makes the difference between "readable" and "unreadable".
Like it or not, but programmers are used to *naming things* (even
locally) and using those local names to refer to things.
"Random" combinations of <$> and/or <*> and/or... (whatever) with no
concrete meaningful names don't really work if you're working with
concrete CRUD-like data. (Fine, if you're working with very abstract
things then you might not even have meaningful names and so they lose
their value. This is *not* the universal experience.)

I should also say: I certainly *understand* the textbook argument, but
if we're going that way, then we're going to end up like C++... before
C++11/C++14. The C++ community/committee have realised their mistake
(stagnatiation) and resolved to instead produce more/better/newer
textbooks. For the better, IMO. We can certainly argue over individual
changes, but this is not a good *general* argument against change. Have
you surveyed the actual number of books out there which show how to
implement Monad instances and how many of them would be affected?

Regards,


From imantc at gmail.com  Fri Oct  2 21:38:07 2015
From: imantc at gmail.com (Imants Cekusins)
Date: Fri, 2 Oct 2015 23:38:07 +0200
Subject: Monad of no `return` Proposal (MRP): Moving `return` out of
 `Monad`
In-Reply-To: <mumqmr$r00$1@ger.gmane.org>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <mumqmr$r00$1@ger.gmane.org>
Message-ID: <CAP1qinY3Va0SOjYZp=rJyFKbvUceqBpVtAOWeFK99pXXJm+btw@mail.gmail.com>

speaking not about this particular "return" issue but change as such:

change can be
a) avoided or
b) accommodated.

let's think of abstract languages L and N. Any resemblance is
coincidental and irrelevant.


Suppose that:

a significant codebase written in L is available

N is a new language with few libraries

a beginner programmer A.B. considers to dedicate their time and effort
to either L or N
A.B. prefers (for various reasons) N syntax.

an experienced programmer C.D. dedicated their time to L language.
C.D. is comfortable with L, wrote and use L code. C.D. can see some
advantages language N gives over L.

the number of programmers similar to C.D. (the L crowd) is fairly
stable but who knows: C.D. may join the N crowd.

number of A.B. and other undecided programmers varies. The more are
A.B.'s, the larger is future camp of any language: L, N, ...

let's think. This is not to argue pro/con but to put things in
perspective. If you were in A.B.'s shoes, what would you do?

From mblazevic at stilo.com  Fri Oct  2 21:55:53 2015
From: mblazevic at stilo.com (=?UTF-8?Q?Mario_Bla=c5=beevi=c4=87?=)
Date: Fri, 2 Oct 2015 17:55:53 -0400
Subject: Monad of no `return` Proposal (MRP): Moving `return` out of
 `Monad`
In-Reply-To: <mumqmr$r00$1@ger.gmane.org>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk> <mumqmr$r00$1@ger.gmane.org>
Message-ID: <560EFD69.20006@stilo.com>

On 15-10-02 04:50 PM, Bardur Arantsson wrote:
> On 10/02/2015 12:09 PM, Henrik Nilsson wrote:
>> Hi all,
>>
> [--snip--]
>> So from that
>> perspective, using the applicative operators directly,
>> without any syntactic sugar, actually amounts to a much
>> more transparent and honest syntax, even if a bit more
>> verbose in some cases.
>
> "Verbose" is the understatement of the year. There's a lot of code where
> ApplicativeDo makes the difference between "readable" and "unreadable".
> Like it or not, but programmers are used to *naming things* (even
> locally) and using those local names to refer to things.

	Naming of applicative sub-expressions is perfectly doable without 
reaching for any syntactic sugar. An applicative do like

	do a <- f long expression
            b <- g long expression
            return (h a b)

would be equivalent to

         let a = f long expression
             b = g long expression
          in f <$> a <*> b

	The benefits of applicative do, if I understand the motivation 
correctly, are not so much to help in writing new code intended to be 
applicative. Instead it lets the programmer write in monadic style and 
at the same time enables the compiler to convert the code to applicative 
style if possible. This has the potential to automatically improve 
performance of legacy Haskell codebase, as well as any new 
beginner-friendly code that relies on syntactic sugar.

	As for the issue of textbooks, I assume they describe Haskell 98. Until 
Haskell compilers start defaulting to Haskell 2020 there shouldn't be 
any issue.



From spam at scientician.net  Fri Oct  2 22:08:47 2015
From: spam at scientician.net (Bardur Arantsson)
Date: Sat, 3 Oct 2015 00:08:47 +0200
Subject: Monad of no `return` Proposal (MRP): Moving `return` out of
 `Monad`
In-Reply-To: <560EFD69.20006@stilo.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk> <mumqmr$r00$1@ger.gmane.org>
 <560EFD69.20006@stilo.com>
Message-ID: <mumv9f$tvq$1@ger.gmane.org>

On 10/02/2015 11:55 PM, Mario Bla?evi? wrote:
> On 15-10-02 04:50 PM, Bardur Arantsson wrote:
>> On 10/02/2015 12:09 PM, Henrik Nilsson wrote:
>>> Hi all,
>>>
>> [--snip--]
>>> So from that
>>> perspective, using the applicative operators directly,
>>> without any syntactic sugar, actually amounts to a much
>>> more transparent and honest syntax, even if a bit more
>>> verbose in some cases.
>>
>> "Verbose" is the understatement of the year. There's a lot of code where
>> ApplicativeDo makes the difference between "readable" and "unreadable".
>> Like it or not, but programmers are used to *naming things* (even
>> locally) and using those local names to refer to things.
> 
>     Naming of applicative sub-expressions is perfectly doable without
> reaching for any syntactic sugar. An applicative do like
> 
>     do a <- f long expression
>            b <- g long expression
>            return (h a b)
> 
> would be equivalent to
> 
>         let a = f long expression
>             b = g long expression
>          in f <$> a <*> b
> 
>     The benefits of applicative do, if I understand the motivation
> correctly, are not so much to help in writing new code intended to be
> applicative. Instead it lets the programmer write in monadic style and
> at the same time enables the compiler to convert the code to applicative
> style if possible. This has the potential to automatically improve
> performance of legacy Haskell codebase, as well as any new
> beginner-friendly code that relies on syntactic sugar.
> 

... if you already know how to do that. That's the point.

Regards,


From spam at scientician.net  Fri Oct  2 22:21:46 2015
From: spam at scientician.net (Bardur Arantsson)
Date: Sat, 3 Oct 2015 00:21:46 +0200
Subject: Monad of no `return` Proposal (MRP): Moving `return` out of
 `Monad`
In-Reply-To: <CAP1qinY3Va0SOjYZp=rJyFKbvUceqBpVtAOWeFK99pXXJm+btw@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk> <mumqmr$r00$1@ger.gmane.org>
 <CAP1qinY3Va0SOjYZp=rJyFKbvUceqBpVtAOWeFK99pXXJm+btw@mail.gmail.com>
Message-ID: <mun01q$bib$1@ger.gmane.org>

On 10/02/2015 11:38 PM, Imants Cekusins wrote:
> speaking not about this particular "return" issue but change as such:
> 
> change can be
> a) avoided or
> b) accommodated.
> 
> let's think of abstract languages L and N. Any resemblance is
> coincidental and irrelevant.
> 
>
(snip)

I'm sorry, but you're going to have to put that in "working
programmer" terms, at least if I'm ever going to understand it.

Like most working programmers, I personally don't thrive on formal
semantics/methods (though I do often benefit from them, even unknowingly!).

Can you explain the problem in layman's terms?

Regards,


From imantc at gmail.com  Fri Oct  2 22:49:30 2015
From: imantc at gmail.com (Imants Cekusins)
Date: Sat, 3 Oct 2015 00:49:30 +0200
Subject: Monad of no `return` Proposal (MRP): Moving `return` out of
 `Monad`
In-Reply-To: <mun01q$bib$1@ger.gmane.org>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <mumqmr$r00$1@ger.gmane.org>
 <CAP1qinY3Va0SOjYZp=rJyFKbvUceqBpVtAOWeFK99pXXJm+btw@mail.gmail.com>
 <mun01q$bib$1@ger.gmane.org>
Message-ID: <CAP1qinagorC1jVVDjuGok71ivteNq5DMRjysPuQH+-34s4x9iQ@mail.gmail.com>

> Can you explain

that paragraph was not a problem but analogy. Here is a pared down version :

if given choice,  what would you and beginners prefer :  libraries (no
change, libraries work) or better syntax (change, libraries break)?

please do not apply this to this particular issue ("return"). Which
syntax is better, whether libraries break, is a different question.

From qdunkan at gmail.com  Sat Oct  3 00:18:29 2015
From: qdunkan at gmail.com (Evan Laforge)
Date: Fri, 2 Oct 2015 17:18:29 -0700
Subject: Monad of no `return` Proposal (MRP): Moving `return` out of
 `Monad`
In-Reply-To: <560EFD69.20006@stilo.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <mumqmr$r00$1@ger.gmane.org> <560EFD69.20006@stilo.com>
Message-ID: <CACbaDy7ZL5gUm0k7qBhJ3BkrMu4_8u69eBhmWhNKeh1wDj2hzw@mail.gmail.com>

On Fri, Oct 2, 2015 at 2:55 PM, Mario Bla?evi? <mblazevic at stilo.com> wrote:
>> "Verbose" is the understatement of the year. There's a lot of code where
>> ApplicativeDo makes the difference between "readable" and "unreadable".
>> Like it or not, but programmers are used to *naming things* (even
>> locally) and using those local names to refer to things.
>
>         Naming of applicative sub-expressions is perfectly doable without
> reaching for any syntactic sugar. An applicative do like

Isn't the debate about 'return', not about ApplicativeDo?
ApplicativeDo is already in the next version, so I think it's been
decided.

From Henrik.Nilsson at nottingham.ac.uk  Sat Oct  3 01:01:12 2015
From: Henrik.Nilsson at nottingham.ac.uk (Henrik Nilsson)
Date: Sat, 03 Oct 2015 02:01:12 +0100
Subject: Monad of no `return` Proposal (MRP): Moving `return` out of
 `Monad`
In-Reply-To: <mumqmr$r00$1@ger.gmane.org>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk> <mumqmr$r00$1@ger.gmane.org>
Message-ID: <560F28D8.1070406@nottingham.ac.uk>

Hi all,

Bardur Arantsson wrote:

 > I should also say: I certainly *understand* the
 > textbook argument, [...] but this is not a good
 > *general* argument against change.

Just to be clear, Graham and I were not at all arguing
against change in general. But we are, in general,
urging extreme caution when it comes to non-essential
breaking changes.

Measuring breakage by referring to Hackage is just the
tip of the iceberg. Much breakage, including
proprietary code, books, research papers, what people
have learned, is very difficult or impossible to
measure. Somehow this point seems to have been
forgotten in the present discussion. The reason there
has to be really compelling reasons for adopting
breaking changes is exactly because the full impact of
those breaking changes is very hard to gauge properly. As
to this specific proposal, in our opinion, the reasons
put forward so far for the "monad of no return" are not
very compelling. And therefore it should not be adopted
at this point.

 > Have you surveyed the actual number of books out
 > there which show how to implement Monad instances and
 > how many of them would be affected?

No. we have not. But ought not the burden of proof rest
with those who are proposing a non-essential breaking
change? If not, why not?

 > but if we're going that way, then we're going to end
 > up like C++... before C++11/C++14. [...] (stagnatiation)

We are hardly going to end up like C++ in that sense by
being very careful before adopting non-essential
breaking changes. Or even rule them out. Nor, returning
to this specific proposal, is leaving "return" as a
method of "Monad" going to mean that Haskell ends
up being stagnant.

Further, it is also worth noting that by almost any
measure C++ is an extremely successful language despite
its warts.

 > "Verbose" is the understatement of the year. There's
 > a lot of code where ApplicativeDo makes the
 > difference between "readable" and "unreadable". Like
 > it or not, but programmers are used to *naming
 > things* (even locally) and using those local names to
 > refer to things.

If so, suggesting that programmers necessarily want to
name things is the sweeping generalisation of the year.

For example, I have written quite a bit of applicative
code, way before it was even called applicative, and I
did not find the lack of syntactic support particularly
bothersome. On the other hand, I have also written a
lot of arrowized code, and there, while I do use the
syntactic sugar to allow me to name certain things, the
fact that I then have to name everything is rather
annoying to say the least, and I have often found
myself wishing that I could write arrowized code that
looked a lot more like applicative code (without the
sugar).

For a very different example, function composition,
maps, and folds are all examples of constructs
in common use where programmers opt to not name
intermediate things.

Anyway, a discussion about the pros and cons of
applicative do entitrely tangential to the point being
made. The point is that applicative do is not yet part
of any Haskell standard, and at this point it is not
clear what any future syntactic support for applicative
code will look like exactly. Therefore is premature to
use this as an argument for this particular proposal,
making any such an argument a weak one. Removal of
"return" as a method of Monad can clearly wait until
such time that syntactic support for applicative code
makes it into the language, if it then is found that
that support, whatever it looks like, would be
unworkable without this change.

Further, I reiterate that if people writing applicative
code were to use "pure" instead of "return", which does
not at all seem unreasonable, the stated problem goes
away. And such a change would clearly have far less
impact on legacy code, text books, teaching material,
what many programmers have learned simply by virtue of
the fact that Applicative in its current form is a very
recent addition.

Bottom line: Breaking changes should only be adopted
for very compelling reasons. The reasons put forward
for far for "monad of no return" fails to meet that
standard. Therefore it should not be adopted, at least
not at this time.

/Henrik

-- 
Henrik Nilsson
School of Computer Science
The University of Nottingham
nhn at cs.nott.ac.uk




This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it. 

Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.


From targen at gmail.com  Sat Oct  3 01:37:32 2015
From: targen at gmail.com (=?UTF-8?Q?Manuel_G=C3=B3mez?=)
Date: Fri, 2 Oct 2015 21:07:32 -0430
Subject: Monad of no `return` Proposal (MRP): Moving `return` out of
 `Monad`
In-Reply-To: <560F28D8.1070406@nottingham.ac.uk>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <mumqmr$r00$1@ger.gmane.org> <560F28D8.1070406@nottingham.ac.uk>
Message-ID: <CAJWnFaNy2GySZQjABwS4Z8AKqq3VLh4dOK1gAqHAgZ0EfE+f_w@mail.gmail.com>

On Fri, Oct 2, 2015 at 8:31 PM, Henrik Nilsson
<Henrik.Nilsson at nottingham.ac.uk> wrote:
> Further, it is also worth noting that by almost any
> measure C++ is an extremely successful language despite
> its warts.

Ah, success at the cost of warts.  I see our priorities as a community
have changed.

> Anyway, a discussion about the pros and cons of
> applicative do entitrely tangential to the point being
> made. The point is that applicative do is not yet part
> of any Haskell standard, and at this point it is not
> clear what any future syntactic support for applicative
> code will look like exactly. Therefore is premature to
> use this as an argument for this particular proposal,
> making any such an argument a weak one. Removal of
> "return" as a method of Monad can clearly wait until
> such time that syntactic support for applicative code
> makes it into the language, if it then is found that
> that support, whatever it looks like, would be
> unworkable without this change.
>
> ?
>
> Bottom line: Breaking changes should only be adopted
> for very compelling reasons. The reasons put forward
> for far for "monad of no return" fails to meet that
> standard. Therefore it should not be adopted, at least
> not at this time.

`return` should have never been a part of the `Monad` type class.  It
does not belong there any more than `fail` does.  We could discuss (in
a separate thread) whether `pure` should be named `return`.  We could
likewise discuss whether it should be in some separate class like the
often-suggested `Point` with whatever name.  We could likewise discuss
where that class should lie in the hierarchy.

In a post-AMP Haskell, however, retaining `return` in `Monad` does not
serve any purpose: any `Monad` instance requires an `Applicative`
instance, wherein `pure` must be defined, and it is a law required by
all instances that they behave identically.  The only expressive
purpose of `return` being in the `Monad` type class is providing an
opportunity to break the laws the community expects for all instances
of `Monad`.

This community rightly values statically eliminating opportunities for
errors, and the removal of `return` as a method of `Monad` serves this
purpose.  This is reason alone to implement this proposal, even in the
absence of `ApplicativeDo`.

From david.feuer at gmail.com  Sat Oct  3 03:42:18 2015
From: david.feuer at gmail.com (David Feuer)
Date: Fri, 2 Oct 2015 23:42:18 -0400
Subject: Monad of no `return` Proposal (MRP): Moving `return` out of
 `Monad`
In-Reply-To: <560F28D8.1070406@nottingham.ac.uk>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <mumqmr$r00$1@ger.gmane.org> <560F28D8.1070406@nottingham.ac.uk>
Message-ID: <CAMgWh9twArus2RppuKRuv-_fsPCz-6+c4_WcngBu9iWL7yHs_Q@mail.gmail.com>

I take your concerns about unnecessary breaking changes seriously. And it
is certainly true that a large amount of existing code will break. However,
I am not at all convinced that the "mental weight" of this change is nearly
as great as that of the now-accomplished AMP, in the presence of good error
messages. Someone reading a classic article on Haskell who writes out their
Monad instance will already be informed that they need to first cough up an
instance of a class that article has no information about. An additional
error message telling them to please delete a single binding hardly seems
onerous in comparison.

I think removing error-prone redundancy is a good thing. While I expect
there are few return/pure mismatches, they are certainly possible. The most
likely scenario, I imagine, involves a difference in strictness when
someone erroneously thinks they can get away with

Applicative f => Applicative (t f)

when in fact they need

Monad f => Applicative (t f)

to obey pure = return in that particular case.
On Oct 2, 2015 9:01 PM, "Henrik Nilsson" <Henrik.Nilsson at nottingham.ac.uk>
wrote:

> Hi all,
>
> Bardur Arantsson wrote:
>
> > I should also say: I certainly *understand* the
> > textbook argument, [...] but this is not a good
> > *general* argument against change.
>
> Just to be clear, Graham and I were not at all arguing
> against change in general. But we are, in general,
> urging extreme caution when it comes to non-essential
> breaking changes.
>
> Measuring breakage by referring to Hackage is just the
> tip of the iceberg. Much breakage, including
> proprietary code, books, research papers, what people
> have learned, is very difficult or impossible to
> measure. Somehow this point seems to have been
> forgotten in the present discussion. The reason there
> has to be really compelling reasons for adopting
> breaking changes is exactly because the full impact of
> those breaking changes is very hard to gauge properly. As
> to this specific proposal, in our opinion, the reasons
> put forward so far for the "monad of no return" are not
> very compelling. And therefore it should not be adopted
> at this point.
>
> > Have you surveyed the actual number of books out
> > there which show how to implement Monad instances and
> > how many of them would be affected?
>
> No. we have not. But ought not the burden of proof rest
> with those who are proposing a non-essential breaking
> change? If not, why not?
>
> > but if we're going that way, then we're going to end
> > up like C++... before C++11/C++14. [...] (stagnatiation)
>
> We are hardly going to end up like C++ in that sense by
> being very careful before adopting non-essential
> breaking changes. Or even rule them out. Nor, returning
> to this specific proposal, is leaving "return" as a
> method of "Monad" going to mean that Haskell ends
> up being stagnant.
>
> Further, it is also worth noting that by almost any
> measure C++ is an extremely successful language despite
> its warts.
>
> > "Verbose" is the understatement of the year. There's
> > a lot of code where ApplicativeDo makes the
> > difference between "readable" and "unreadable". Like
> > it or not, but programmers are used to *naming
> > things* (even locally) and using those local names to
> > refer to things.
>
> If so, suggesting that programmers necessarily want to
> name things is the sweeping generalisation of the year.
>
> For example, I have written quite a bit of applicative
> code, way before it was even called applicative, and I
> did not find the lack of syntactic support particularly
> bothersome. On the other hand, I have also written a
> lot of arrowized code, and there, while I do use the
> syntactic sugar to allow me to name certain things, the
> fact that I then have to name everything is rather
> annoying to say the least, and I have often found
> myself wishing that I could write arrowized code that
> looked a lot more like applicative code (without the
> sugar).
>
> For a very different example, function composition,
> maps, and folds are all examples of constructs
> in common use where programmers opt to not name
> intermediate things.
>
> Anyway, a discussion about the pros and cons of
> applicative do entitrely tangential to the point being
> made. The point is that applicative do is not yet part
> of any Haskell standard, and at this point it is not
> clear what any future syntactic support for applicative
> code will look like exactly. Therefore is premature to
> use this as an argument for this particular proposal,
> making any such an argument a weak one. Removal of
> "return" as a method of Monad can clearly wait until
> such time that syntactic support for applicative code
> makes it into the language, if it then is found that
> that support, whatever it looks like, would be
> unworkable without this change.
>
> Further, I reiterate that if people writing applicative
> code were to use "pure" instead of "return", which does
> not at all seem unreasonable, the stated problem goes
> away. And such a change would clearly have far less
> impact on legacy code, text books, teaching material,
> what many programmers have learned simply by virtue of
> the fact that Applicative in its current form is a very
> recent addition.
>
> Bottom line: Breaking changes should only be adopted
> for very compelling reasons. The reasons put forward
> for far for "monad of no return" fails to meet that
> standard. Therefore it should not be adopted, at least
> not at this time.
>
> /Henrik
>
> --
> Henrik Nilsson
> School of Computer Science
> The University of Nottingham
> nhn at cs.nott.ac.uk
>
>
>
>
> This message and any attachment are intended solely for the addressee
> and may contain confidential information. If you have received this
> message in error, please send it back to me, and immediately delete it.
> Please do not use, copy or disclose the information contained in this
> message or in any attachment.  Any views or opinions expressed by the
> author of this email do not necessarily reflect the views of the
> University of Nottingham.
>
> This message has been checked for viruses but the contents of an
> attachment may still contain software viruses which could damage your
> computer system, you are advised to perform your own checks. Email
> communications with the University of Nottingham may be monitored as
> permitted by UK legislation.
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151002/8be53461/attachment.html>

From dominic at steinitz.org  Sat Oct  3 07:40:22 2015
From: dominic at steinitz.org (Dominic Steinitz)
Date: Sat, 3 Oct 2015 08:40:22 +0100
Subject: Monad of no `return` Proposal (MRP): Moving `return` out of
 `Monad`
In-Reply-To: <mailman.12750.1443833743.13545.libraries@haskell.org>
References: <mailman.12750.1443833743.13545.libraries@haskell.org>
Message-ID: <7CDB196F-2A8D-43B6-9AE7-7C02BE217F1F@steinitz.org>

> The upshot of this e-mail is a strong collective -2
> from us both on particular proposal, and a general call
> for much more caution when it comes to breaking changes
> that are not critically important.
Thank you for articulating what are also my misgivings. -1 from me also.

On a historical note `return` used to be called `unit`.

Dominic Steinitz
dominic at steinitz.org
http://idontgetoutmuch.wordpress.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151003/9b2f660e/attachment.html>

From johan.tibell at gmail.com  Sat Oct  3 08:00:48 2015
From: johan.tibell at gmail.com (Johan Tibell)
Date: Sat, 3 Oct 2015 10:00:48 +0200
Subject: Monad of no `return` Proposal (MRP): Moving `return` out of
 `Monad`
In-Reply-To: <7CDB196F-2A8D-43B6-9AE7-7C02BE217F1F@steinitz.org>
References: <mailman.12750.1443833743.13545.libraries@haskell.org>
 <7CDB196F-2A8D-43B6-9AE7-7C02BE217F1F@steinitz.org>
Message-ID: <CAK-tuPZqVEe2N4H1T4NmkLi5Hn93RyRkrzbgXCNVKzbB=Smagw@mail.gmail.com>

-1 from me as well.

I don't find the proposal convincing.

Cons:
 * Major breakages to existing code (which needs to be updated), docs (many
of which can't be updated), and future code (coding with ifdefs is error
prone).

Pros:
 * A feeling of cleanliness.

I think there's an implicit argument being made here, that if we let time
go towards infinity every breaking change is eventually paid off, no matter
how small the gain. Time doesn't go to infinity for us. Haskell currently
has a window of opportunity for being adopted and bringing more functional
programmers to the world. This window isn't very big, perhaps a couple of
years to a decade. If we make programming in Haskell annoying by
continuously breaking anything, people will lose interest in Haskell and
move on to other languages.

-- Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151003/17441ca9/attachment-0001.html>

From Henrik.Nilsson at nottingham.ac.uk  Sat Oct  3 08:09:52 2015
From: Henrik.Nilsson at nottingham.ac.uk (Henrik Nilsson)
Date: Sat, 03 Oct 2015 09:09:52 +0100
Subject: Monad of no `return` Proposal (MRP): Moving `return` out of
 `Monad`
In-Reply-To: <CAJWnFaNy2GySZQjABwS4Z8AKqq3VLh4dOK1gAqHAgZ0EfE+f_w@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk> <mumqmr$r00$1@ger.gmane.org>
 <560F28D8.1070406@nottingham.ac.uk>
 <CAJWnFaNy2GySZQjABwS4Z8AKqq3VLh4dOK1gAqHAgZ0EfE+f_w@mail.gmail.com>
Message-ID: <560F8D50.6080405@nottingham.ac.uk>

Hi all,

Manuel G?mez wrote:

 > > Further, it is also worth noting that by almost any
 > > measure C++ is an extremely successful language despite
 > > its warts.
 >
 > Ah, success at the cost of warts.  I see our priorities as a community
 > have changed.

That's nonsensical and unnecessarily polemic.

I am merely pointing out that removal of every single "wart" is
not a prerequisite for success. But striving for "perfection" can
have significant and even unjustifiable costs.

 > `return` should have never been a part of the `Monad` type class.

That's an odd statement. The mathematical concept of a monad
clearly does not necessitate structuring things as a hierarchy of
classes.

In any case, the point is that "return" has been part of "Monad"
for some 25 years. That's a serious historical legacy that should
not be dismissed lightly for reasons already discussed.

 > In a post-AMP Haskell, however, retaining `return` in `Monad` does not
 > serve any purpose:

That is not true. It does provide for an opportunity to write code
that works with versions of GHC prior to 7.10 as well as later versions
with a few fairly small fixes and (without resorting to conditional 
compilation). That's important to some people.

 > This community rightly values statically eliminating opportunities for
 > errors, and the removal of `return` as a method of `Monad` serves this
 > purpose.  This is reason alone to implement this proposal, even in the
 > absence of `ApplicativeDo`.

While I do accept your point about a mostly redundant "return"
providing one opportunity to accidentally breaking a law that should
hold, *any* Monad instance provide an opportunity for breaking
multiple laws. Further, there are a range of classes where there
are methods with default instances that are there to provide
for an opportunity for more efficient implementation. They also
need to satisfy laws and again there is an opportunity for
accidentally breaking those.

I am thus hard pressed to believe that keeping "return" as a method
makes of Monad makes any perceptible practical difference either
way in that respect.

So, at least in my opinion, this is argument is no stronger
than those already put forward.

All the best,

/Henrik

-- 
Henrik Nilsson
School of Computer Science
The University of Nottingham
nhn at cs.nott.ac.uk




This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it. 

Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.


From Henrik.Nilsson at nottingham.ac.uk  Sat Oct  3 08:24:47 2015
From: Henrik.Nilsson at nottingham.ac.uk (Henrik Nilsson)
Date: Sat, 03 Oct 2015 09:24:47 +0100
Subject: Monad of no `return` Proposal (MRP): Moving `return` out of
 `Monad`
In-Reply-To: <CAMgWh9twArus2RppuKRuv-_fsPCz-6+c4_WcngBu9iWL7yHs_Q@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>	<alpine.DEB.2.02.1510011830520.7958@sputnik>	<560D8DA4.2080706@gmail.com>	<560E57D1.9060302@nottingham.ac.uk>	<mumqmr$r00$1@ger.gmane.org>	<560F28D8.1070406@nottingham.ac.uk>
 <CAMgWh9twArus2RppuKRuv-_fsPCz-6+c4_WcngBu9iWL7yHs_Q@mail.gmail.com>
Message-ID: <560F90CF.70609@nottingham.ac.uk>

Hi all,

David Feuer wrote:

 > I take your concerns about unnecessary breaking changes seriously.
 > And it is certainly true that a large amount of existing code will
 > break. However, I am not at all convinced that the "mental weight" of
 > this change is nearly as great as that of the now-accomplished AMP,
 > in the presence of good error messages.

That may be true (and if pressed, I'd likely agree with you), but
it is beside the Graham and I were making: AMP does not necessitate
"monad of no return", and the cost of the additional breakage of
the latter should thus be justified in terms of how essential it is
for other reasons. At least there should be a very compelling
argument that the advantages clearly outweighs the costs. And again,
in any case like this, I think the burden of proof necessarily
rests with those who are arguing for the change.

 > I think removing error-prone redundancy is a good thing.

Undeniably. But does eliminating this particular
redundancy make enough of a practical difference to
justify the costs? There are plenty of opportunities
to break laws and introducing strictness bugs anyway.
See previous e-mail.

All the best,

/Henrik

-- 
Henrik Nilsson
School of Computer Science
The University of Nottingham
nhn at cs.nott.ac.uk




This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it. 

Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.


From Henrik.Nilsson at nottingham.ac.uk  Sat Oct  3 08:40:46 2015
From: Henrik.Nilsson at nottingham.ac.uk (Henrik Nilsson)
Date: Sat, 03 Oct 2015 09:40:46 +0100
Subject: Monad of no `return` Proposal (MRP): Moving `return` out of
 `Monad`
In-Reply-To: <CAK-tuPZqVEe2N4H1T4NmkLi5Hn93RyRkrzbgXCNVKzbB=Smagw@mail.gmail.com>
References: <mailman.12750.1443833743.13545.libraries@haskell.org>
 <7CDB196F-2A8D-43B6-9AE7-7C02BE217F1F@steinitz.org>
 <CAK-tuPZqVEe2N4H1T4NmkLi5Hn93RyRkrzbgXCNVKzbB=Smagw@mail.gmail.com>
Message-ID: <560F948E.1040300@nottingham.ac.uk>

Hi all,

Johan Tibell wrote:

On 10/03/2015 09:00 AM, Johan Tibell wrote:
> Time doesn't go to infinity for us. Haskell currently has a window of
> opportunity for being adopted and bringing more functional programmers
> to the world. This window isn't very big, perhaps a couple of years to a
> decade. If we make programming in Haskell annoying by continuously
> breaking anything, people will lose interest in Haskell and move on to
> other languages.

Well said. That is also a major concern of Graham and myself.
And it is not just people considering adopting Haskell
who are being annoyed, but also long-standing members of
the community.

Just to give one data point, Graham tells me that the
latest revision of Richard Bird's Haskell book was
broken with respect to the latest changes before it
had had a chance to hit the shops. The changes that
broke the book may well have been essential. But such
breakage is clearly annoying to many people, including
those who have bought a recently updated book only
to find that it does not quite work.

We really need to be careful to not break things
unless absolutely necessary.

Best,

/Henrik

-- 
Henrik Nilsson
School of Computer Science
The University of Nottingham
nhn at cs.nott.ac.uk




This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it. 

Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.


From spam at scientician.net  Sat Oct  3 09:06:55 2015
From: spam at scientician.net (Bardur Arantsson)
Date: Sat, 3 Oct 2015 11:06:55 +0200
Subject: Monad of no `return` Proposal (MRP): Moving `return` out of
 `Monad`
In-Reply-To: <560F28D8.1070406@nottingham.ac.uk>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk> <mumqmr$r00$1@ger.gmane.org>
 <560F28D8.1070406@nottingham.ac.uk>
Message-ID: <muo5rf$jok$1@ger.gmane.org>

On 10/03/2015 03:01 AM, Henrik Nilsson wrote:
> Hi all,
> 
> Bardur Arantsson wrote:
> 
>> I should also say: I certainly *understand* the
>> textbook argument, [...] but this is not a good
>> *general* argument against change.
> 
> Just to be clear, Graham and I were not at all arguing
> against change in general. But we are, in general,
> urging extreme caution when it comes to non-essential
> breaking changes.
> 
> Measuring breakage by referring to Hackage is just the
> tip of the iceberg. Much breakage, including
> proprietary code, books, research papers, what people
> have learned, is very difficult or impossible to
> measure. Somehow this point seems to have been
> forgotten in the present discussion. The reason there
> has to be really compelling reasons for adopting
> breaking changes is exactly because the full impact of
> those breaking changes is very hard to gauge properly. As
> to this specific proposal, in our opinion, the reasons
> put forward so far for the "monad of no return" are not
> very compelling. And therefore it should not be adopted
> at this point.
> 
>> Have you surveyed the actual number of books out
>> there which show how to implement Monad instances and
>> how many of them would be affected?
> 
> No. we have not. But ought not the burden of proof rest
> with those who are proposing a non-essential breaking
> change? If not, why not?
> 
>> but if we're going that way, then we're going to end
>> up like C++... before C++11/C++14. [...] (stagnatiation)
> 
> We are hardly going to end up like C++ in that sense by
> being very careful before adopting non-essential
> breaking changes. Or even rule them out. Nor, returning
> to this specific proposal, is leaving "return" as a
> method of "Monad" going to mean that Haskell ends
> up being stagnant.
> 
> Further, it is also worth noting that by almost any
> measure C++ is an extremely successful language despite
> its warts.
> 

C++ is what "success at all cost" looks like. (I won't bother responding
to the rest, others have done that adequately.)

Look, I truly[1] do appreciate the arguments in favor of "don't break
things", but I don't think it's borne out by any reasonable reading of
history.

Regards,

[1] At least I think I do. :)


From jon.fairbairn at cl.cam.ac.uk  Sat Oct  3 09:33:16 2015
From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn)
Date: Sat, 03 Oct 2015 10:33:16 +0100
Subject: Monad of no `return` Proposal (MRP): Moving `return` out of
 `Monad`
References: <mailman.12750.1443833743.13545.libraries@haskell.org>
 <7CDB196F-2A8D-43B6-9AE7-7C02BE217F1F@steinitz.org>
 <CAK-tuPZqVEe2N4H1T4NmkLi5Hn93RyRkrzbgXCNVKzbB=Smagw@mail.gmail.com>
 <560F948E.1040300@nottingham.ac.uk>
Message-ID: <wfzj00z483.fsf@calligramme.charmers>

Henrik Nilsson <Henrik.Nilsson at nottingham.ac.uk> writes:

> Hi all,
>
> Johan Tibell wrote:
>
> On 10/03/2015 09:00 AM, Johan Tibell wrote:
>> Time doesn't go to infinity for us. Haskell currently has a window of
>> opportunity for being adopted and bringing more functional programmers
>> to the world. This window isn't very big, perhaps a couple of years to a
>> decade. If we make programming in Haskell annoying by continuously
>> breaking anything, people will lose interest in Haskell and move on to
>> other languages.
>
> Well said. That is also a major concern of Graham and myself.
> And it is not just people considering adopting Haskell
> who are being annoyed, but also long-standing members of
> the community.

That includes me. I have various pieces of software that I have
written in Haskell over the years, and having fiddle with them
pretty much every time there is a new release of ghc is very
irritating. Obviously I don?t bother to recompile most of them
every time, because one of the advantages of programming in
Haskell is that I make fewer mistakes: so the code works and has
done for years, but when I want to add a new feature or
compensate for some change in the environment, what should be a
10 minute job ends up taking ages.

-1 on the proposal.

-- 
J?n Fairbairn                                 Jon.Fairbairn at cl.cam.ac.uk



From Henrik.Nilsson at nottingham.ac.uk  Sat Oct  3 10:02:17 2015
From: Henrik.Nilsson at nottingham.ac.uk (Henrik Nilsson)
Date: Sat, 03 Oct 2015 11:02:17 +0100
Subject: Monad of no `return` Proposal (MRP): Moving `return` out of
 `Monad`
In-Reply-To: <muo5rf$jok$1@ger.gmane.org>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk> <mumqmr$r00$1@ger.gmane.org>
 <560F28D8.1070406@nottingham.ac.uk> <muo5rf$jok$1@ger.gmane.org>
Message-ID: <560FA7A9.1050806@nottingham.ac.uk>

Hi all,

Bardur Arantsson wrote:

On 10/03/2015 10:06 AM, Bardur Arantsson wrote:
> C++ is what "success at all cost" looks like. (I won't bother responding
> to the rest, others have done that adequately.)

Haskell is at no risk of becoming like C++ in that respect either.

The point being made was just that the odd wart is not a big problem.
But breaking things without really compelling reasons is.

> Look, I truly[1] do appreciate the arguments in favor of "don't break
> things", but I don't think it's borne out by any reasonable reading of
> history.

Again, Graham and I were not saying "don't break things". We were saying
"if things are to be broken, then there had better be very compelling
reasons".

That's a big difference.

Best,

/Henrik

-- 
Henrik Nilsson
School of Computer Science
The University of Nottingham
nhn at cs.nott.ac.uk




This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it. 

Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.


From taruti at taruti.net  Sat Oct  3 10:27:16 2015
From: taruti at taruti.net (Taru Karttunen)
Date: Sat, 3 Oct 2015 13:27:16 +0300
Subject: Monad of no `return` Proposal (MRP): Moving `return` out of
 `Monad`
In-Reply-To: <87io6zmr2x.fsf@gnu.org>
References: <87io6zmr2x.fsf@gnu.org>
Message-ID: <95CA0F05D125DC1904391481B4381F@mail.local>

On 24.09 23:43, Herbert Valerio Riedel wrote:
> Concluding AMP and MFP, We (David and I) proudly present you the final
> installment of the Monad trilogy:

-1

Would providing automated tooling for changes be possible?

I think there would be much less resistance if there was working
automatic tooling for the various changes and e.g. >95% of Hackage 
would build with each new GHC version.

Currently code seems to be breaking with every major GHC release.
In essence this drives up costs of maintaining software.

One of the reasons I use Haskell less than I used to use for
work stuff is the lack of stability and constant breakage
that adds up.

- Taru Karttunen

From imantc at gmail.com  Sat Oct  3 11:53:36 2015
From: imantc at gmail.com (Imants Cekusins)
Date: Sat, 3 Oct 2015 13:53:36 +0200
Subject: Monad of no `return` Proposal (MRP): Moving `return` out of
 `Monad`
In-Reply-To: <95CA0F05D125DC1904391481B4381F@mail.local>
References: <87io6zmr2x.fsf@gnu.org>
 <95CA0F05D125DC1904391481B4381F@mail.local>
Message-ID: <CAP1qinZLd5JbUHp1wa5SEKpYO2iW2kfK7iMRzqWwNhORRgXuWg@mail.gmail.com>

> lack of stability and constant breakage

isn't this the case with most languages and frameworks, including the
most popular?

which is the real problem: changes themselves or libraries not being
maintained / upgraded?

From asr at eafit.edu.co  Sat Oct  3 14:43:53 2015
From: asr at eafit.edu.co (=?UTF-8?B?QW5kcsOpcyBTaWNhcmQtUmFtw61yZXo=?=)
Date: Sat, 3 Oct 2015 09:43:53 -0500
Subject: Monad of no `return` Proposal (MRP): Moving `return` out of
 `Monad`
Message-ID: <CAOUWSGBEXXaapvUupETmjUbkEjGmOTnKR_RQuVdC+jX4GsaLFQ@mail.gmail.com>

Hi,

In Agda, we added support for GHC 7.10.* following the migration guide
available at

  https://ghc.haskell.org/trac/ghc/wiki/Migration/7.10

In particular, we added instances of Applicative using

  instance Applicative Foo where
    pure  = return
    (<*>) = ap  -- defined in Control.Monad


After reading the "Monad of no `return` proposal" below, I have two questions:

1. Shouldn't the above migration guide to be changed to something like

  instance Applicative Foo where
    pure  = <copy-the-definition-of-return>
    ...

  instance Monad Foo where
    return = pure

?

2. Since in Agda code `return` is used everywhere, does follow (1) has
some performance cost?


All the best,


On 24 September 2015 at 16:43, Herbert Valerio Riedel <hvr at gnu.org> wrote:
> Hello *,
>
> Concluding AMP and MFP, We (David and I) proudly present you the final
> installment of the Monad trilogy:
>
>
> Monad of no `return` Proposal
> =============================
>
> TLDR: To complete the AMP, turn `Monad(return)` method into a
>       top-level binding aliasing `Applicative(pure)`.
>
>
> Current Situation
> -----------------
>
> With the implementation of Functor-Applicative-Monad Proposal (AMP)[1] and
> (at some point) the MonadFail proposal (MFP)[2] the AMP class hierarchy
> becomes
>
>
>     class  Functor f  where
>         fmap    :: (a -> b) -> f a -> f b
>
>
>     class  Functor f => Applicative f  where
>         pure    :: a -> f a
>         (<*>)   :: f (a -> b) -> f a -> f b
>
>         (*>)    :: f a -> f b -> f b
>         u *> v  = ?
>
>         (<*)    :: f a -> f b -> f a
>         u <* v  = ?
>
>
>     class  Applicative m => Monad m  where
>         (>>=)   :: m a -> (a -> m b) -> m b
>
>         return  :: a -> m a
>         return  = pure
>
>         (>>)    :: m a -> m b -> m b
>         m >> k  = ?
>
>
>     class  Monad m => MonadFail m  where
>         fail    :: String -> m a
>
>
> Consequently, the `Monad` class is left with a now redundant `return`
> method as a historic artifact, as there's no compelling reason to
> have `pure` and `return` implemented differently.
>
> Traditionally, `return` is often used where `pure` would suffice
> today, forcing a `Monad` constraint even if a weaker `Applicative`
> would have sufficed.
>
> As a result, language extensions like `ApplicativeDo`[3] have to
> rewrite `return` to weaken its `Monad m =>` constraint to
> `Applicative m =>` in order to benefit existing code at the cost
> of introducing magic behavior at the type level.
>
> Finally, this redundancy becomes even more significant when viewed in
> light of the renewed Haskell standardisation process[7]: The next
> Haskell Report will almost certainly incorporate the AMP (and MFP)
> changes, and there's no justification for the Report to retain
> `return` as a method of `Monad`. A good reason would have been to
> retain backward compatibility with Haskell 2010. However, as the AMP
> superclass hierarchy requires `Monad` instances to be accompanied by
> `Applicative` instances (which aren't part of Haskell 2010, c.f. [6]),
> backward compatibility with Haskell 2010 goes out the window when it
> comes to defining `Monad` instances (unless via use of `-XCPP` or
> similar).  Consequently, meeting the high bar for a formal document
> such as the Haskell Report demands that `Monad` shall not carry a
> redundant `return` method that serves no purpose anymore. Moreover,
> getting `return` out of the way is desirable to facilitate
> standardising potential candidates such as the earlier mentioned
> `ApplicativeDo` in the future and avoids the technical debt incurred
> by keeping around this language wart.
>
>
> Proposed Change
> ---------------
>
> Remove `return` as a method from the `Monad` class and in its place
> define a top-level binding with the weaker `Applicative` typeclass
> constraint:
>
>
>     -- | Legacy alias for 'pure'
>     return :: Applicative f => a -> f a
>     return = pure
>
>
> This allows existing code using `return` to benefit from a weaker
> typeclass constraint as well as cleaning the `Monad` class from a
> redundant method in the post-AMP world.
>
> A possible migration strategy is described further below.
>
>
> Compatibility Considerations
> ----------------------------
>
> Generalizing the type signature of a function from a `Monad`
> constraint to its superclass `Applicative` doesn't cause new
> type-errors in existing code.
>
> However, moving a method to a top-level binding obviously breaks code
> that assumes `return` to be a class method. Foremost, code that
> defines `Monad` instances it at risk:
>
> ### Instance Definitions
>
> Code defining `return` as part of an instance definition
> breaks. However, we had the foresight to provide a default
> implementation in `base-4.8` for `return` so that the following
> represents a proper minimal instance definition post-AMP:
>
>
>     instance Functor Foo where
>         fmap g foo  = ?
>
>     instance Applicative Foo where
>         pure x      = ?
>         a1 <*> a2   = ?
>
>     instance Monad Foo where
>         m >>= f     = ?
>
>         -- NB: No mention of `return`
>
>
> Consequently, it is possible to write forward-compatible instances
> that are valid under this proposal starting with GHC 7.10/`base-4.8`.
>
> Heuristically `grep`ing through Hackage source-code reveals a
> non-negligible number of packages defining `Monad` instances with
> explicit `return` definitions[4]. This has a comparable impact to the
> AMP, and similarly will require a transition scheme aided by compiler
> warnings.
>
> ### Module Import/Export Specifications
>
> A second source of incompatibility may be due to
> `import`s. Specifically module import that assert `return` to be a
> method of `Monad`, e.g.:
>
>     import Control.Monad  (Monad ((>>=), return))
>
> or
>
>     import Prelude hiding (Monad(..))
>     import Control.Monad  (Monad(..)) as Monad
>
>     f = Monad.return ()
>
> The dual situation can occur when re-exporting `return` via module
> export specifications.
>
> However, given that `return` is exported by `Prelude` and the examples
> above are rather artificial, we don't expect this to be a major source
> of breakage in the case of `return`. In fact, a heuristic grep[5] over
> Hackage source-code revealed only 21 packages affected.
>
> ### Example for writing compatible code
>
>
>     instance Functor Foo where
>         fmap g foo  = ?
>
>     instance Applicative Foo where
>         pure x      = ?
>         a1 <*> a2   = ?
>
>     instance Monad Foo where
>         m >>= f     = ?
>
>     #if !(MIN_VERSION_base(4,8,0))
>         return = pure
>     #endif
>
>
> Migration Strategy
> ------------------
>
> The migration strategy is straightforward:
>
> **Phase 1** *(GHC 8.0)*: Implement new warning in GHC which gets
>    triggered when `Monad` instances explicitly override the
>    default `return` method implementation.
>
> **Phase 2** *(GHC 8.2 or later)*: When we're confident that the
>    majority of Hackage has reacted to the warning (with the help of
>    Stackage actively pursuing maintainers to update their packages) we
>    turn the `return` method into a top-level binding and remove the
>    warning implemented in Phase 1 from GHC again.
>
>
> Discussion period
> -----------------
>
> A discussion period of three weeks (until 2015-10-15) should be enough
> to allow everyone to chime in as well as leave enough time to make the
> required preparations for GHC 8.0 should this proposal pass as we hope.
>
> ----
>
>  [1]: https://wiki.haskell.org/Functor-Applicative-Monad_Proposal
>  [2]: https://wiki.haskell.org/MonadFail_Proposal
>  [3]: https://ghc.haskell.org/trac/ghc/wiki/ApplicativeDo
>  [4]: https://gist.github.com/hvr/b0e34463d85b58f169d9
>  [5]: https://gist.github.com/hvr/afcd040783d980594883
>  [6]: https://ghc.haskell.org/trac/ghc/ticket/9590
>  [7]: https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html
>
> --
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>



-- 
Andr?s

From johnw at newartisans.com  Sat Oct  3 18:52:01 2015
From: johnw at newartisans.com (John Wiegley)
Date: Sat, 03 Oct 2015 11:52:01 -0700
Subject: Monad of no `return` Proposal (MRP): Moving `return` out of
 `Monad`
In-Reply-To: <560FA7A9.1050806@nottingham.ac.uk> (Henrik Nilsson's message of
 "Sat, 03 Oct 2015 11:02:17 +0100")
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <mumqmr$r00$1@ger.gmane.org> <560F28D8.1070406@nottingham.ac.uk>
 <muo5rf$jok$1@ger.gmane.org> <560FA7A9.1050806@nottingham.ac.uk>
Message-ID: <m2k2r3ss32.fsf@newartisans.com>

>>>>> Henrik Nilsson <Henrik.Nilsson at nottingham.ac.uk> writes:

> Again, Graham and I were not saying "don't break things". We were saying "if
> things are to be broken, then there had better be very compelling reasons".

> That's a big difference.

You made a great argument, Henrik, and you've changed my enthusiastic +1 to
+0, until it can be bundled with some other, more necessary, breaking change.

John

From hvr at gnu.org  Sun Oct  4 00:15:36 2015
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Sun, 04 Oct 2015 02:15:36 +0200
Subject: Monad of no `return` Proposal (MRP): Moving `return` out of
 `Monad`
In-Reply-To: <560F28D8.1070406@nottingham.ac.uk> (Henrik Nilsson's message of
 "Sat, 03 Oct 2015 02:01:12 +0100")
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <mumqmr$r00$1@ger.gmane.org> <560F28D8.1070406@nottingham.ac.uk>
Message-ID: <87r3lbwkt3.fsf@gnu.org>

On 2015-10-03 at 03:01:12 +0200, Henrik Nilsson wrote:

[...]

>> Have you surveyed the actual number of books out
>> there which show how to implement Monad instances and
>> how many of them would be affected?
>
> No. we have not. But ought not the burden of proof rest
> with those who are proposing a non-essential breaking
> change? If not, why not?

Well, afaik the books commonly used in teaching are largely based on
Haskell 98 or Haskell 2010.

( IMO, the problem here is rather the expectation that the latest GHC
  would still provide a Haskell 2010 library environment, even though
  the few books based on GHC for the most part let the reader run GHC in
  default mode and mention neither `-XHaskell2010` nor `-package
  haskell2010`.  And yes, GHC 7.10 effectively had to drop support for
  `-package haskell2010`. Otoh, There's several Linux distributions
  still stuck on GHC 7.6.3 (e.g. Debian & Ubuntu) or even older.
   
  Btw, would the concern be addressed if a future GHC would recover a
  legacy Haskell2010 library environment?
)

All books I've looked at so far will undoubtedly have their examples
defining `Monad` instances be broken under the next Haskell Report, even
*without* the MRP which simplifies the Haskell Report and is surely more
desirable from a pedagogical point of view as well.

----------------------------------------------------------------------------

For instance, in Graham Hutton's Book the section about defining Monad
instances in chapter 10[1] is rather short (defining `Monad` instances
is not an essential part of that book) and presents the Monads
type-class literally as

  class Monad m where
     return :: a -> m a
     (>>=)  :: m a -> (a -> m b) -> m b

and goes on to claim

| Using this declaration, parsers and interactive programs can then be
| made into instances of the class of monadic types, by defining the two
| member functions in the appropriate manner:

And this will clearly not apply anymore under the next Haskell Report.
On the bright side, `fail` is not mentioned, so at least it won't break
under the MonadFail change.

----

Richard Bird's "Thinking Functionally with Haskell" from 2014 sticks to
Haskell2010, and presents the `Monad` class exactly like Graham's book
(i.e. providing only `return` and `(>>=)`). Curiously, even though
published in 2014, `Applicative` isn't mentioned anywhere in the
book. In any case, this Book's `Monad`-instance examples will be broken
as well under a new Haskell Report due to the AMP change.

----

Simon Thompson's "Haskell - the Craft of Functional Programming, 3ed"
(2011), on the other hand presents the `Monad` class exactly as written
into the Haskell 2010 Report, namely:


   class Monad m where
    (>>=)   :: m a -> (a -> m b) -> m b
    return  :: a -> m a
    (>>)    :: m a -> m b -> m b
    fail    :: String -> m a

    m >> k  =  m >>= \_ -> k
    fail s  = error s


Consequently, `Monad`-defining examples in that book break on accounts
of both, AMP *and* MonadFail changes.

----

The "Real World Haskell" book predates Haskell 2010 by a few years but
features the `Applicative` class. `Monad`-instance examples contained in
the book break on accounts of AMP and MonadFail as well.

----

Miran Lipovaca's very popular "Learn You a Haskell for Great Good" (2011)
book is written in a more casual style and targets mostly Haskell
2010. The `Monad` class is presented with the 4 methods according to the
Haskell 2010 Report.[2]

The `Applicative` class is mentioned and the missing superclass
relationship is pointed out:

| Shouldn't there be a class constraint in there along the lines of
| `class (Applicative m) => Monad m where` so that a type has to be an
| applicative functor first before it can be made a monad? Well, there
| should, but when Haskell was made, it hadn't occured to people that
| applicative functors are a good fit for Haskell so they weren't in
| there.

It's also noteworthy that the book has to explain why there are two
different verbs for the same purpose:

| The first function that the Monad type class defines is `return`. It's
| the same as `pure`, only with a different name. Its type is `(Monad m)
| => a -> m a`. It takes a value and puts it in a minimal default
| context that still holds that value. In other words, it takes
| something and wraps it in a monad. It always does the same thing as
| the `pure` function from the `Applicative` type class, which means
| we're already acquainted with `return`. We already used `return` when
| doing I/O. We used it to take a value and make a bogus I/O action that
| does nothing but yield that value.

The `MonadFail` class, however, is neither mentioned nor anticipated. So
LYAH will need to be updated as well regarding AMP and MonadFail induced
breakages.

----

Finally, Alejandro Serrano Mena's more practical "Beginning Haskell" book
also provides to the full Haskell 2010 `Monad` class
definition. The `Applicative` class is described as well. However, the
book was clearly written in the knowledge of the upcoming AMP:

| If any Monad instance is also an instance of Functor, why is this
| relation not shown in the declaration of those classes? This is a
| historical accident, and you should expect Functor to soon become a
| superclass of Monad . In the meantime, you should ensure that you have
| an instance of Functor for each of your Monad instances: you can build
| one easily using the aforementioned liftM function.

as well as

| The fact that Applicative does not appear as a superclass of Monad is
| again a historical accident: the Monad concept was used widely much
| earlier than the concept of Applicative . For compatibility reasons,
| Monad hasn?t changed its definition to include any of Functor or
| Applicative as superclasses. This will change soon, though, and the
| full hierarchy Functor , then Applicative , then Monad will be
| apparent in the type classes.

But at the time of writing the MonadFail proposal couldn't be
foreseen.

----------------------------------------------------------------------------

These may not be all the Haskell books out there, but these examples
clearly show that we've already set a precedent with the AMP and the
MonadFail proposal alone. There are a few other base-library transitions
already happened or in mid-flight that have a similar effect on
published books and materials which leave the boundaries of the Haskell
2010 Library Report.

So if the primary argument is that published literature shouldn't get
broken. Well, that's already happened. And there will unavoidably be
incompatible changes between Haskell2010 and Haskell201x.


The point of this Monad-of-no-return Proposal was to provide the formal
basis to be able to write the AMP into the next upcoming Haskell Report
in a sensible way (and I think we can all agree that this is the right
thing to do as there is no good justification for including the
`Monad(return)`-method in an Haskell Report integrating the AMP changes)


However, one thing that seems to have been mostly ignored in this whole
discussion so far is that just because the next Haskell Report
anticipates the removal of `return` and `(>>)` as methods this doesn't
mean that GHC's `base` library has to follow suit immediately!

The proposal states that phase 2 can happen in GHC 8.2 *or later*. This
could also mean e.g. GHC 8.4, GHC 8.8, or even GHC 9.0!  This is very
different from the AMP, MFP or FTP which are/were subject to a swift
transition scheme with a rigid timeframe.

Old code still overriding `return` will continue to compile (if it
didn't break already for AMP/MFP/...) for as many years in GHC as
desired.

And code written against the new Haskell Report (especially when
ignoring the existence of the `return`-method) would work just fine
against GHC's `base` as well.

So there's not that much immediate breakage due to MRP specifically
after all.


Regards,
  H.V.Riedel

 [1]: http://i.imgur.com/DyPTZml.png
 [2]: http://learnyouahaskell.com/a-fistful-of-monads#the-monad-type-class

From johnw at newartisans.com  Sun Oct  4 00:20:18 2015
From: johnw at newartisans.com (John Wiegley)
Date: Sat, 03 Oct 2015 17:20:18 -0700
Subject: Monad of no `return` Proposal (MRP): Moving `return` out of
 `Monad`
In-Reply-To: <87r3lbwkt3.fsf@gnu.org> (Herbert Valerio Riedel's message of
 "Sun, 04 Oct 2015 02:15:36 +0200")
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <mumqmr$r00$1@ger.gmane.org> <560F28D8.1070406@nottingham.ac.uk>
 <87r3lbwkt3.fsf@gnu.org>
Message-ID: <m2k2r3lc1p.fsf@newartisans.com>

>>>>> Herbert Valerio Riedel <hvr at gnu.org> writes:

> The point of this Monad-of-no-return Proposal was to provide the formal
> basis to be able to write the AMP into the next upcoming Haskell Report in a
> sensible way (and I think we can all agree that this is the right thing to
> do as there is no good justification for including the
> `Monad(return)`-method in an Haskell Report integrating the AMP changes)

> However, one thing that seems to have been mostly ignored in this whole
> discussion so far is that just because the next Haskell Report anticipates
> the removal of `return` and `(>>)` as methods this doesn't mean that GHC's
> `base` library has to follow suit immediately!

> The proposal states that phase 2 can happen in GHC 8.2 *or later*. This
> could also mean e.g. GHC 8.4, GHC 8.8, or even GHC 9.0! This is very
> different from the AMP, MFP or FTP which are/were subject to a swift
> transition scheme with a rigid timeframe.

> Old code still overriding `return` will continue to compile (if it didn't
> break already for AMP/MFP/...) for as many years in GHC as desired.

> And code written against the new Haskell Report (especially when ignoring
> the existence of the `return`-method) would work just fine against GHC's
> `base` as well.

> So there's not that much immediate breakage due to MRP specifically after
> all.

Then count me again as +1, thanks for the clarification, Herbert.

John

From hvr at gnu.org  Sun Oct  4 09:35:45 2015
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Sun, 04 Oct 2015 11:35:45 +0200
Subject: Monad of no `return` Proposal (MRP): Moving `return` out of
 `Monad`
In-Reply-To: <CAOUWSGBEXXaapvUupETmjUbkEjGmOTnKR_RQuVdC+jX4GsaLFQ@mail.gmail.com>
 (=?utf-8?Q?=22Andr=C3=A9s_Sicard-Ram=C3=ADrez=22's?= message of "Sat, 3 Oct
 2015 09:43:53 -0500")
References: <CAOUWSGBEXXaapvUupETmjUbkEjGmOTnKR_RQuVdC+jX4GsaLFQ@mail.gmail.com>
Message-ID: <87612n0ydq.fsf@gnu.org>

Hello,

On 2015-10-03 at 16:43:53 +0200, Andr?s Sicard-Ram?rez wrote:
> In Agda, we added support for GHC 7.10.* following the migration guide
> available at
>
>   https://ghc.haskell.org/trac/ghc/wiki/Migration/7.10
>
> In particular, we added instances of Applicative using
>
>   instance Applicative Foo where
>     pure  = return
>     (<*>) = ap  -- defined in Control.Monad
>
>
> After reading the "Monad of no `return` proposal" below, I have two questions:
>
> 1. Shouldn't the above migration guide to be changed to something like
>
>   instance Applicative Foo where
>     pure  = <copy-the-definition-of-return>
>     ...
>
>   instance Monad Foo where
>     return = pure
>
> ?

Indeed, I've updated the GHC wiki page accordingly, thanks for pointing
that out!

> 2. Since in Agda code `return` is used everywhere, does follow (1) has
> some performance cost?

If you have generic code which doesn't get specialised to a specific
class dictionary for Monad/Applicative then there's the overhead of an
additional indirection (depending on which way around the
Monad/Applicative instances were defined).

The AMP instructions were formulated in a way to make manual refactoring
easiest, while they don't necessarily match how you'd define instances
from scratch in a post-AMP setting.

Given the convenience of the post-AMP default-method-implementation of
`return`, I expect new code to start defining `return` in terms of
`pure` rather than the other way around, and older existing code will
probably slowly migrate to that state as well.

Given the usual 3-major-GHC-version compatibility window convention we
strive for in Hackage-released Haskell code, starting with GHC 8.2, code
written not defining `return` explicitly anymore will be compliant with
this convention.

In any case, if you *know* that you incur an overhead if you use
`return` rather than `pure` in your code (due to
e.g. non-specialisation) and don't want to refactor your code just yet
to use `pure` instead of `return`, you can hide the import of `return`
and define an inlineable `return = pure` top-level binding in its
place. Otoh, if you have code which doesn't specialise the
Monad-instances I'd expect the `return`-induced overhead to be a minor
contribution as GHC will have already missed a few other opportunities
to inline and optimise your code.

Cheers,
  hvr

From thomasmiedema at gmail.com  Sun Oct  4 10:47:01 2015
From: thomasmiedema at gmail.com (Thomas Miedema)
Date: Sun, 4 Oct 2015 12:47:01 +0200
Subject: Monad of no `return` Proposal (MRP): Moving `return` out of
 `Monad`
Message-ID: <CAD3WKggj9nVg24_QZYf8guqOhr4_OwyVNAR6nCCMzeqJx7+G_Q@mail.gmail.com>

>
> > So there's not that much immediate breakage due to MRP specifically after
> > all.
>
> Then count me again as +1, thanks for the clarification, Herbert.
>

+1 as well

- The books are already outdated. Libraries can be updated.
- This proposal simplifies the language and the next Haskell report.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151004/67d32454/attachment.html>

From lemming at henning-thielemann.de  Sun Oct  4 14:03:03 2015
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Sun, 4 Oct 2015 16:03:03 +0200 (CEST)
Subject: updating stream-fusion for GHC-7.10
Message-ID: <alpine.DEB.2.02.1510041600460.7814@sputnik>


Attached is a patch to the stream-fusion package that makes it compileable 
by GHC-7.10. Unfortunately the authors did not reply to my patch request. 
How can I get the patch into the package?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: stream-fusion-ghc-7.10.diff
Type: text/x-diff
Size: 1789 bytes
Desc: 
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151004/64619df9/attachment.diff>

From ben at smart-cactus.org  Sun Oct  4 14:10:40 2015
From: ben at smart-cactus.org (Ben Gamari)
Date: Sun, 04 Oct 2015 16:10:40 +0200
Subject: Monad of no `return` Proposal (MRP): Moving `return` out of
 `Monad`
In-Reply-To: <87io6zmr2x.fsf@gnu.org>
References: <87io6zmr2x.fsf@gnu.org>
Message-ID: <87y4fizpun.fsf@smart-cactus.org>

Herbert Valerio Riedel <hvr at gnu.org> writes:

> Hello *,
>
> Concluding AMP and MFP, We (David and I) proudly present you the final
> installment of the Monad trilogy:
>
> Monad of no `return` Proposal
> =============================
>
> TLDR: To complete the AMP, turn `Monad(return)` method into a
>       top-level binding aliasing `Applicative(pure)`.
>
+1

With a sufficiently long timeframe for adoption (with removal no earlier
than 8.4) it seems like the immediate cost of this change shouldn't be
so onerous; if we managed AMP then we should be able to pull this off as
well. It seems to be the right thing to do and I sincerely believe we
can keep the cost to users low; let's do it.

I find this especially true in light of the recent advances made in the
area of tooling. We are now in a much better position to be offering
tools for automated refactoring than we were even when we considered
AMP. Perhaps one of the HaRe contributors can comment on the feasibility
of automatically rewriting `return` definitions to `pure` definitions?
It feels like this should be quite workable in most cases.

It also helps that we have the luxury of being able to pick this change up
at a relaxed pace. For a long time, we as a community have lamented the
lack of tools (both language features and otherwise) for restructuring
typeclass hierarchies (e.g. see #4879, #2119, #10071). Since we now have
the experience of AMP under our collective belts, it seems like we are
in a much better position to put forward some concrete proposals for
easing this sort of interface refactoring and deprecation.

The `DEPRECATED`/`REMOVED` pragmas on class methods would be a great
step towards this end. With a bit of work we could greatly reduce the
impact of changes like these; an improvement that could bring benefits
well beyond the core libraries. Those interested in contributing in this
area should see the Wiki [1].

With respect to invalidating teaching materials, I think this ship has
already sailed with AMP and `MonadFail`, as Herbert has pointed out.
Nevertheless we can help their users evolve along with the language with
deprecation mechanisms, tools, and approachable error messages.

Cheers,

- Ben


[1] https://ghc.haskell.org/trac/ghc/wiki/Design/DeprecationMechanisms
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151004/03bfbbd6/attachment.sig>

From david.feuer at gmail.com  Sun Oct  4 14:16:41 2015
From: david.feuer at gmail.com (David Feuer)
Date: Sun, 4 Oct 2015 10:16:41 -0400
Subject: updating stream-fusion for GHC-7.10
In-Reply-To: <alpine.DEB.2.02.1510041600460.7814@sputnik>
References: <alpine.DEB.2.02.1510041600460.7814@sputnik>
Message-ID: <CAMgWh9typUsrYRtQfEhaM0hE5BpapGbNiJRxgGrsxS8=81bCJA@mail.gmail.com>

Open up https://github.com/haskell-infra/hackage-trustees/ , read the
instructions, and file an issue with the required information.

David Feuer
On Oct 4, 2015 10:03 AM, "Henning Thielemann" <lemming at henning-thielemann.de>
wrote:

>
> Attached is a patch to the stream-fusion package that makes it compileable
> by GHC-7.10. Unfortunately the authors did not reply to my patch request.
> How can I get the patch into the package?
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151004/956175d4/attachment.html>

From greg at gregweber.info  Sun Oct  4 17:18:22 2015
From: greg at gregweber.info (Greg Weber)
Date: Sun, 4 Oct 2015 10:18:22 -0700
Subject: Monad of no `return` Proposal (MRP): Moving `return` out of
 `Monad`
In-Reply-To: <87y4fizpun.fsf@smart-cactus.org>
References: <87io6zmr2x.fsf@gnu.org> <87y4fizpun.fsf@smart-cactus.org>
Message-ID: <CAKRanNAqqZKUinhxWPVZvf_p-C6S70SZ75AeJjZXQvNozfygTg@mail.gmail.com>

1) I would like to ban the usage of the term "C++" in all libraries mailing
list discussions except for those discussing binding C++ code. I have never
seen intelligent discussion result from bringing up "C++" in an unrelated
context.
2) Is there an updated wiki page for this proposal that explains the
migration path for the community

It seems that there is a lot of discussion about what this proposal might
be and it is time to make it more concrete (particularly with respect to
how exactly library and application authors handle breakage) if there is
going to be more productive conversation going forward.
Also, one should not be required to re-read this long thread and pick out
important details to understand the proposal as it exists now.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151004/9afd6fe5/attachment.html>

From marcin.jan.mrotek at gmail.com  Sun Oct  4 17:27:04 2015
From: marcin.jan.mrotek at gmail.com (Marcin Mrotek)
Date: Sun, 4 Oct 2015 19:27:04 +0200
Subject: Monad of no `return` Proposal (MRP): Moving `return` out of
 `Monad`
In-Reply-To: <87y4fizpun.fsf@smart-cactus.org>
References: <87io6zmr2x.fsf@gnu.org>
	<87y4fizpun.fsf@smart-cactus.org>
Message-ID: <CAJcfPzkWSV79b=basm4W06MMvgD4-nL+mFAa=wow489ZTUD4DA@mail.gmail.com>

> I find this especially true in light of the recent advances made in the
> area of tooling. We are now in a much better position to be offering
> tools for automated refactoring than we were even when we considered
> AMP.

Well, it's not like this particular proposal requires tools any more
sophisticated than cut&paste (for instance declarations) and
search&replace (/return/pure/). The only code that will be negatively
affected is code that is not maintained or is printed on dead trees.

Best regards,
Marcin Mrotek

From carter.schonwald at gmail.com  Sun Oct  4 18:08:02 2015
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sun, 4 Oct 2015 14:08:02 -0400
Subject: Monad of no `return` Proposal (MRP): Moving `return` out of
 `Monad`
In-Reply-To: <87io6zmr2x.fsf@gnu.org>
References: <87io6zmr2x.fsf@gnu.org>
Message-ID: <CAHYVw0yRDdwNF-fEc+DufnWztFgpz7nk5OjyJWMnRjTEvBGxog@mail.gmail.com>

Strong +1

this needs to happen.

I'm ok with the migration overhead, and nows a good time to clean up these
core things now that we understand what they should be / how they're
interrelated. Most of the concerns i've seen seem to be a rehash of those
from AMP and friends, which worked out pretty well I think!

cheers!

On Thu, Sep 24, 2015 at 5:43 PM, Herbert Valerio Riedel <hvr at gnu.org> wrote:

> Hello *,
>
> Concluding AMP and MFP, We (David and I) proudly present you the final
> installment of the Monad trilogy:
>
>
> Monad of no `return` Proposal
> =============================
>
> TLDR: To complete the AMP, turn `Monad(return)` method into a
>       top-level binding aliasing `Applicative(pure)`.
>
>
> Current Situation
> -----------------
>
> With the implementation of Functor-Applicative-Monad Proposal (AMP)[1] and
> (at some point) the MonadFail proposal (MFP)[2] the AMP class hierarchy
> becomes
>
>
>     class  Functor f  where
>         fmap    :: (a -> b) -> f a -> f b
>
>
>     class  Functor f => Applicative f  where
>         pure    :: a -> f a
>         (<*>)   :: f (a -> b) -> f a -> f b
>
>         (*>)    :: f a -> f b -> f b
>         u *> v  = ?
>
>         (<*)    :: f a -> f b -> f a
>         u <* v  = ?
>
>
>     class  Applicative m => Monad m  where
>         (>>=)   :: m a -> (a -> m b) -> m b
>
>         return  :: a -> m a
>         return  = pure
>
>         (>>)    :: m a -> m b -> m b
>         m >> k  = ?
>
>
>     class  Monad m => MonadFail m  where
>         fail    :: String -> m a
>
>
> Consequently, the `Monad` class is left with a now redundant `return`
> method as a historic artifact, as there's no compelling reason to
> have `pure` and `return` implemented differently.
>
> Traditionally, `return` is often used where `pure` would suffice
> today, forcing a `Monad` constraint even if a weaker `Applicative`
> would have sufficed.
>
> As a result, language extensions like `ApplicativeDo`[3] have to
> rewrite `return` to weaken its `Monad m =>` constraint to
> `Applicative m =>` in order to benefit existing code at the cost
> of introducing magic behavior at the type level.
>
> Finally, this redundancy becomes even more significant when viewed in
> light of the renewed Haskell standardisation process[7]: The next
> Haskell Report will almost certainly incorporate the AMP (and MFP)
> changes, and there's no justification for the Report to retain
> `return` as a method of `Monad`. A good reason would have been to
> retain backward compatibility with Haskell 2010. However, as the AMP
> superclass hierarchy requires `Monad` instances to be accompanied by
> `Applicative` instances (which aren't part of Haskell 2010, c.f. [6]),
> backward compatibility with Haskell 2010 goes out the window when it
> comes to defining `Monad` instances (unless via use of `-XCPP` or
> similar).  Consequently, meeting the high bar for a formal document
> such as the Haskell Report demands that `Monad` shall not carry a
> redundant `return` method that serves no purpose anymore. Moreover,
> getting `return` out of the way is desirable to facilitate
> standardising potential candidates such as the earlier mentioned
> `ApplicativeDo` in the future and avoids the technical debt incurred
> by keeping around this language wart.
>
>
> Proposed Change
> ---------------
>
> Remove `return` as a method from the `Monad` class and in its place
> define a top-level binding with the weaker `Applicative` typeclass
> constraint:
>
>
>     -- | Legacy alias for 'pure'
>     return :: Applicative f => a -> f a
>     return = pure
>
>
> This allows existing code using `return` to benefit from a weaker
> typeclass constraint as well as cleaning the `Monad` class from a
> redundant method in the post-AMP world.
>
> A possible migration strategy is described further below.
>
>
> Compatibility Considerations
> ----------------------------
>
> Generalizing the type signature of a function from a `Monad`
> constraint to its superclass `Applicative` doesn't cause new
> type-errors in existing code.
>
> However, moving a method to a top-level binding obviously breaks code
> that assumes `return` to be a class method. Foremost, code that
> defines `Monad` instances it at risk:
>
> ### Instance Definitions
>
> Code defining `return` as part of an instance definition
> breaks. However, we had the foresight to provide a default
> implementation in `base-4.8` for `return` so that the following
> represents a proper minimal instance definition post-AMP:
>
>
>     instance Functor Foo where
>         fmap g foo  = ?
>
>     instance Applicative Foo where
>         pure x      = ?
>         a1 <*> a2   = ?
>
>     instance Monad Foo where
>         m >>= f     = ?
>
>         -- NB: No mention of `return`
>
>
> Consequently, it is possible to write forward-compatible instances
> that are valid under this proposal starting with GHC 7.10/`base-4.8`.
>
> Heuristically `grep`ing through Hackage source-code reveals a
> non-negligible number of packages defining `Monad` instances with
> explicit `return` definitions[4]. This has a comparable impact to the
> AMP, and similarly will require a transition scheme aided by compiler
> warnings.
>
> ### Module Import/Export Specifications
>
> A second source of incompatibility may be due to
> `import`s. Specifically module import that assert `return` to be a
> method of `Monad`, e.g.:
>
>     import Control.Monad  (Monad ((>>=), return))
>
> or
>
>     import Prelude hiding (Monad(..))
>     import Control.Monad  (Monad(..)) as Monad
>
>     f = Monad.return ()
>
> The dual situation can occur when re-exporting `return` via module
> export specifications.
>
> However, given that `return` is exported by `Prelude` and the examples
> above are rather artificial, we don't expect this to be a major source
> of breakage in the case of `return`. In fact, a heuristic grep[5] over
> Hackage source-code revealed only 21 packages affected.
>
> ### Example for writing compatible code
>
>
>     instance Functor Foo where
>         fmap g foo  = ?
>
>     instance Applicative Foo where
>         pure x      = ?
>         a1 <*> a2   = ?
>
>     instance Monad Foo where
>         m >>= f     = ?
>
>     #if !(MIN_VERSION_base(4,8,0))
>         return = pure
>     #endif
>
>
> Migration Strategy
> ------------------
>
> The migration strategy is straightforward:
>
> **Phase 1** *(GHC 8.0)*: Implement new warning in GHC which gets
>    triggered when `Monad` instances explicitly override the
>    default `return` method implementation.
>
> **Phase 2** *(GHC 8.2 or later)*: When we're confident that the
>    majority of Hackage has reacted to the warning (with the help of
>    Stackage actively pursuing maintainers to update their packages) we
>    turn the `return` method into a top-level binding and remove the
>    warning implemented in Phase 1 from GHC again.
>
>
> Discussion period
> -----------------
>
> A discussion period of three weeks (until 2015-10-15) should be enough
> to allow everyone to chime in as well as leave enough time to make the
> required preparations for GHC 8.0 should this proposal pass as we hope.
>
> ----
>
>  [1]: https://wiki.haskell.org/Functor-Applicative-Monad_Proposal
>  [2]: https://wiki.haskell.org/MonadFail_Proposal
>  [3]: https://ghc.haskell.org/trac/ghc/wiki/ApplicativeDo
>  [4]: https://gist.github.com/hvr/b0e34463d85b58f169d9
>  [5]: https://gist.github.com/hvr/afcd040783d980594883
>  [6]: https://ghc.haskell.org/trac/ghc/ticket/9590
>  [7]:
> https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html
>
> --
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151004/521f357d/attachment-0001.html>

From malcolm.wallace at me.com  Mon Oct  5 09:05:24 2015
From: malcolm.wallace at me.com (Malcolm Wallace)
Date: Mon, 05 Oct 2015 10:05:24 +0100
Subject: Monad of no `return` Proposal (MRP): Moving `return` out of
 `Monad`
In-Reply-To: <560E57D1.9060302@nottingham.ac.uk>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
Message-ID: <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>

I am also a strong -1 on small changes that break huge numbers of things for somewhat trivial benefits.

Regards,
    Malcolm

On 2 Oct 2015, at 11:09, Henrik Nilsson wrote:

> Hi all,
> 
> I have discussed the monad of no return proposal with
> my colleague Graham Hutton: a long-standing member of
> the Haskell community, well-known researcher, some 20
> years of experience of teaching Haskell to
> undergraduate students, and author of one of the most
> successful introductory Haskell textbooks there are.
> 
> The upshot of this e-mail is a strong collective -2
> from us both on particular proposal, and a general call
> for much more caution when it comes to breaking changes
> that are not critically important.
> 
> First, on a general note, there has recently been a
> flurry of breaking changes to the (de facto) Haskell
> standards. In many cases for very good reasons, but
> sometimes it seems more in a quest for perfection
> without due consideration for the consequences. It used
> to be the case that breaking changes were very rare
> indeed. And for good reason.
> 
> Right now, the main "measure of breakage" in the
> on-line discussions seems to be how many packages that
> break in Hackage. Which of course makes sense: the
> Hackage repository is very important and such a measure
> is objective, as far as it goes.
> 
> But we should not forget that breakage can go far
> beyond Hackage. For starters, there is *lots* of code
> that is not in Hackage, yet critically important to its
> users, however many or few they are. There are more
> than hundreds of thousands of copies of books out there
> where that may break in that examples may no longer
> work. And they cannot be changed. There are countless
> research papers that may break in the same way. Every
> single institution that use Haskell in their teaching
> may have to update their teaching materials (slides,
> code, lab instructions) for every module that teaches
> or uses Haskell. And last but not the least, what
> countless of programmers and students have learned
> about Haskell over decades, most of whom are *not*
> power users who can take these changes in their stride,
> may also break.
> 
> Now, of course a language has to evolve, and sometimes
> breaking backwards compatibility is more or less
> essential for the long-term benefit of the language.
> But we should not let perfection be the enemy of the
> good.
> 
> As to this particular proposal, the monad of no return,
> it does not seem essential to us, but mostly motivated
> by a quest for "perfection" as defined by a very
> knowledgeable but in relative terms small group of
> people.
> 
> One argument put forward was that applicative code that
> uses "return" instead of "pure" should get a less
> constrained type. But such code is relatively new. The
> methods of the Monad class have been return and bind
> for some 25 years. So indeed, as Henning Thielemann
> wrote: why should not the newer code be adapted and use
> "pure" instead? In fact, the use of "pure" in such code
> could serve as a quite useful cue that the code is
> applicative rather than monadic, especially where
> applicative do is employed.
> 
> Another reason put forward is support for the
> applicative do syntax. But that is, in standard terms,
> only a future possibility at this point. Further, the
> syntax is arguably rather dubious anyway as it, in
> particular to someone with an imperative background,
> suggests a sequential reading which is exactly what
> applicative is not and why it is useful. So from that
> perspective, using the applicative operators directly,
> without any syntactic sugar, actually amounts to a much
> more transparent and honest syntax, even if a bit more
> verbose in some cases.
> 
> The bottom line is that it is premature to put forward
> support for the applicative do syntax as a rationale
> for a non-essential breaking change.
> 
> Best regards,
> 
> Henrik Nilsson and Graham Hutton
> 
> -- 
> Henrik Nilsson
> School of Computer Science
> The University of Nottingham
> nhn at cs.nott.ac.uk


From malcolm.wallace at me.com  Mon Oct  5 09:30:01 2015
From: malcolm.wallace at me.com (Malcolm Wallace)
Date: Mon, 05 Oct 2015 10:30:01 +0100
Subject: Monad of no `return` Proposal (MRP): Moving `return` out of
 `Monad`
In-Reply-To: <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
Message-ID: <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>

On other social media forums, I am seeing educators who use Haskell as a vehicle for their main work, but would not consider themselves Haskell researchers, and certainly do not have the time to follow Haskell mailing lists, who are beginning to say that these kinds of annoying breakages to the language, affecting their research and teaching materials, are beginning to disincline them to continue using Haskell.  They are feeling like they would be less well disposed to reviewing papers that use Haskell, and less well disposed to collaborating on writing papers that involve Haskell.

Please can the Haskell Prime Committee take into account the views of such "peripheral" users of the language, who after all, form some measure of its recent "success".  Haskell is a real-world tool for many people, and breakage of their code, and their sources of information about Haskell, is a powerful disincentive to continue with it.

Regards,
   Malcolm


> On 5 Oct 2015, at 10:05, Malcolm Wallace wrote:
> 
>> I am also a strong -1 on small changes that break huge numbers of things for somewhat trivial benefits.
>> 
>> Regards,
>>   Malcolm
>> 
>> On 2 Oct 2015, at 11:09, Henrik Nilsson wrote:
>> 
>>> Hi all,
>>> 
>>> I have discussed the monad of no return proposal with
>>> my colleague Graham Hutton: a long-standing member of
>>> the Haskell community, well-known researcher, some 20
>>> years of experience of teaching Haskell to
>>> undergraduate students, and author of one of the most
>>> successful introductory Haskell textbooks there are.
>>> 
>>> The upshot of this e-mail is a strong collective -2
>>> from us both on particular proposal, and a general call
>>> for much more caution when it comes to breaking changes
>>> that are not critically important.
>>> 
>>> First, on a general note, there has recently been a
>>> flurry of breaking changes to the (de facto) Haskell
>>> standards. In many cases for very good reasons, but
>>> sometimes it seems more in a quest for perfection
>>> without due consideration for the consequences. It used
>>> to be the case that breaking changes were very rare
>>> indeed. And for good reason.
>>> 
>>> Right now, the main "measure of breakage" in the
>>> on-line discussions seems to be how many packages that
>>> break in Hackage. Which of course makes sense: the
>>> Hackage repository is very important and such a measure
>>> is objective, as far as it goes.
>>> 
>>> But we should not forget that breakage can go far
>>> beyond Hackage. For starters, there is *lots* of code
>>> that is not in Hackage, yet critically important to its
>>> users, however many or few they are. There are more
>>> than hundreds of thousands of copies of books out there
>>> where that may break in that examples may no longer
>>> work. And they cannot be changed. There are countless
>>> research papers that may break in the same way. Every
>>> single institution that use Haskell in their teaching
>>> may have to update their teaching materials (slides,
>>> code, lab instructions) for every module that teaches
>>> or uses Haskell. And last but not the least, what
>>> countless of programmers and students have learned
>>> about Haskell over decades, most of whom are *not*
>>> power users who can take these changes in their stride,
>>> may also break.
>>> 
>>> Now, of course a language has to evolve, and sometimes
>>> breaking backwards compatibility is more or less
>>> essential for the long-term benefit of the language.
>>> But we should not let perfection be the enemy of the
>>> good.
>>> 
>>> As to this particular proposal, the monad of no return,
>>> it does not seem essential to us, but mostly motivated
>>> by a quest for "perfection" as defined by a very
>>> knowledgeable but in relative terms small group of
>>> people.
>>> 
>>> One argument put forward was that applicative code that
>>> uses "return" instead of "pure" should get a less
>>> constrained type. But such code is relatively new. The
>>> methods of the Monad class have been return and bind
>>> for some 25 years. So indeed, as Henning Thielemann
>>> wrote: why should not the newer code be adapted and use
>>> "pure" instead? In fact, the use of "pure" in such code
>>> could serve as a quite useful cue that the code is
>>> applicative rather than monadic, especially where
>>> applicative do is employed.
>>> 
>>> Another reason put forward is support for the
>>> applicative do syntax. But that is, in standard terms,
>>> only a future possibility at this point. Further, the
>>> syntax is arguably rather dubious anyway as it, in
>>> particular to someone with an imperative background,
>>> suggests a sequential reading which is exactly what
>>> applicative is not and why it is useful. So from that
>>> perspective, using the applicative operators directly,
>>> without any syntactic sugar, actually amounts to a much
>>> more transparent and honest syntax, even if a bit more
>>> verbose in some cases.
>>> 
>>> The bottom line is that it is premature to put forward
>>> support for the applicative do syntax as a rationale
>>> for a non-essential breaking change.
>>> 
>>> Best regards,
>>> 
>>> Henrik Nilsson and Graham Hutton
>>> 
>>> -- 
>>> Henrik Nilsson
>>> School of Computer Science
>>> The University of Nottingham
>>> nhn at cs.nott.ac.uk
>> 
> 


From mjgajda at gmail.com  Mon Oct  5 09:47:21 2015
From: mjgajda at gmail.com (=?UTF-8?Q?Micha=C5=82_J_Gajda?=)
Date: Mon, 5 Oct 2015 17:47:21 +0800
Subject: Monad of no `return` Proposal (MRP): Moving `return` out of
 `Monad`
In-Reply-To: <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
Message-ID: <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>

Hi,

As a person who used Haskell in all three capacities (for scientific
research, for commercial purpose, and to introduce others to benefits of
pure and strongly typed programming), I must voice an supportive voice for
this change:
1. Orthogonal type classes are easier to explain.
2. Gradual improvements helps us to generalize further, and this in turn
makes education easier.
3. Gradual change that break only a little help to prevent either
stagnation (FORTRAN) and big breakage (py3k). That keeps us excited.

That would also call to split TCs into their orthogonal elements: return,
ap, bind having the basic TC on their own.

So:
+1, but only if it is possible to have compatibilty mode. I believe that
rebindable syntax should allow us to otherwise make our own prelude, if we
want such a split. Then we could test it well before it is used by the base
library.

That said, I would appreciate Haskell2010 option just like Haskell98 wad,
so that we can compile old programs without changes. Even by using some
Compat version of standard library. Would that satisfy need for stability?

PS And since all experts were beginners some time ago, I beg that we do not
call them "peripheral".
--
  Best regards
    Micha?

On Monday, 5 October 2015, Malcolm Wallace <malcolm.wallace at me.com> wrote:

> On other social media forums, I am seeing educators who use Haskell as a
> vehicle for their main work, but would not consider themselves Haskell
> researchers, and certainly do not have the time to follow Haskell mailing
> lists, who are beginning to say that these kinds of annoying breakages to
> the language, affecting their research and teaching materials, are
> beginning to disincline them to continue using Haskell.  They are feeling
> like they would be
>
(...)


-- 
  Pozdrawiam
    Micha?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151005/a81235d3/attachment.html>

From duncan.coutts at googlemail.com  Mon Oct  5 10:29:10 2015
From: duncan.coutts at googlemail.com (Duncan Coutts)
Date: Mon, 05 Oct 2015 11:29:10 +0100
Subject: updating stream-fusion for GHC-7.10
In-Reply-To: <alpine.DEB.2.02.1510041600460.7814@sputnik>
References: <alpine.DEB.2.02.1510041600460.7814@sputnik>
Message-ID: <1444040950.31600.410.camel@googlemail.com>

On Sun, 2015-10-04 at 16:03 +0200, Henning Thielemann wrote:
> Attached is a patch to the stream-fusion package that makes it compileable 
> by GHC-7.10. Unfortunately the authors did not reply to my patch request. 
> How can I get the patch into the package?

Henning, would you like to become maintainer of this package?

Ping me on IRC and we can sort it out.


From ivan.perez at keera.co.uk  Mon Oct  5 11:10:41 2015
From: ivan.perez at keera.co.uk (Ivan Perez)
Date: Mon, 5 Oct 2015 12:10:41 +0100
Subject: Monad of no `return` Proposal (MRP): Moving `return` out of
 `Monad`
In-Reply-To: <CAK-tuPZqVEe2N4H1T4NmkLi5Hn93RyRkrzbgXCNVKzbB=Smagw@mail.gmail.com>
References: <mailman.12750.1443833743.13545.libraries@haskell.org>
 <7CDB196F-2A8D-43B6-9AE7-7C02BE217F1F@steinitz.org>
 <CAK-tuPZqVEe2N4H1T4NmkLi5Hn93RyRkrzbgXCNVKzbB=Smagw@mail.gmail.com>
Message-ID: <56125AB1.3000505@keera.co.uk>

On 03/10/15 09:00, johan.tibell at gmail.com (Johan Tibell) wrote:
> -1 from me as well.
>
> I don't find the proposal convincing.
>
> Cons:
>   * Major breakages to existing code (which needs to be updated), docs (many
> of which can't be updated), and future code (coding with ifdefs is error
> prone).
>
> Pros:
>   * A feeling of cleanliness.
Completely agree.

-1 for us too.

Breaking changes are a major problem for us:

- At Keera Studios we are maintaining a bunch of legacy libraries 
internally (some of which we
are releasing back via github), for all platforms.

- Also, GHC's Android backend is currently based on 7.8, and don't have 
the manpower to maintain it.

> I think there's an implicit argument being made here, that if we let time
> go towards infinity every breaking change is eventually paid off, no matter
> how small the gain. Time doesn't go to infinity for us. Haskell currently
> has a window of opportunity for being adopted and bringing more functional
> programmers to the world. This window isn't very big, perhaps a couple of
> years to a decade. If we make programming in Haskell annoying by
> continuously breaking anything, people will lose interest in Haskell and
> move on to other languages.
In general, regarding how these changes are being introduced:

Time runs fast for us, and our company sits in this window of 
opportunity that Johan mentions.

While we understand that changes are necessary, and that this kind of 
change benefits from spread adoption to test the community's response 
quickly, the decision process that is currently taking place leads to a 
form of continuous releases that breaks libraries very often. This costs 
us a time that we simply do not have.

We currently deploy Haskell worldwide. Even if our audience is 
relatively small in numbers, it is geographically spread. Frequent 
backwards-incompatible changes require huge amounts of testing if we 
want to do things right. Testing, in our market, without access to your 
client's terminal, is expensive.

We prefer to invest time once, fix legacy code once, test it once and 
know it's set and working for 3-5 years at least. We have users who have 
been running updates of the same Haskell software for 4 years straight 
now, without ever hitting a runtime bug. We see consider that not our 
success, but Haskell's. We'd like to keep it that way.

Ivan

From marcin.jan.mrotek at gmail.com  Mon Oct  5 11:26:28 2015
From: marcin.jan.mrotek at gmail.com (Marcin Mrotek)
Date: Mon, 5 Oct 2015 13:26:28 +0200
Subject: Monad of no `return` Proposal (MRP): Moving `return` out of
 `Monad`
In-Reply-To: <56125AB1.3000505@keera.co.uk>
References: <mailman.12750.1443833743.13545.libraries@haskell.org>
 <7CDB196F-2A8D-43B6-9AE7-7C02BE217F1F@steinitz.org>
 <CAK-tuPZqVEe2N4H1T4NmkLi5Hn93RyRkrzbgXCNVKzbB=Smagw@mail.gmail.com>
 <56125AB1.3000505@keera.co.uk>
Message-ID: <CAJcfPznV1UYE5P_6xE-ymfMvAjsykqAryP6Rytxs-VrcXG2+2w@mail.gmail.com>

Perhaps introducing the change now, but extending the transition
period until the next major breakage would bring the best of both
worlds?

Best regards,
Marcin Mrotek

From svenpanne at gmail.com  Mon Oct  5 13:27:53 2015
From: svenpanne at gmail.com (Sven Panne)
Date: Mon, 5 Oct 2015 15:27:53 +0200
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
Message-ID: <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>

2015-10-05 11:59 GMT+02:00 Simon Thompson <s.j.thompson at kent.ac.uk>:

> [...] It?s really interesting to have this discussion, which pulls in all
> sorts of well-made points about orthogonality, teaching, the evolution of
> the language and so on, but it simply goes to show that the process of
> evolving Haskell is profoundly broken. [...]
>

I wouldn't necessarily call the process "broken", but it's a bit annoying:
Because of the constant flux of minor changes in the language and the
libraries, I've reached the stage where I'm totally unable to tell if my
code will work for the whole GHC 7.x series. The only way I see is doing
heavy testing on Travis CI and littering the code with #ifdefs after
compilation failures. (BTW: Fun exercise: Try using (<>) and/or (<$>) in
conjunction with -Wall. Bonus points for keeping the #ifdefs centralized.
No clue how to do that...) This is less than satisfactory IMHO, and I would
really prefer some other mode for introducing such changes: Perhaps these
should be bundled and released e.g. every 2 years as Haskell2016,
Haskell2018, etc. This way some stuff which belongs together (AMP, FTP,
kicking out return, etc.) comes in slightly larger, but more sensible
chunks.

Don't get me wrong: Most of the proposed changes in itself are OK and
should be done, it's only the way they are introduced should be improved...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151005/632c915c/attachment.html>

From greg at gregweber.info  Mon Oct  5 13:46:04 2015
From: greg at gregweber.info (Greg Weber)
Date: Mon, 5 Oct 2015 06:46:04 -0700
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
Message-ID: <CAKRanNA7H13u22opFfcX07tbLdxpk-_cYn6s8QWrHmVm-kvPzQ@mail.gmail.com>

Does anyone here use base-compat? It has worked quite well in my very
limited usage. I think that if the libraries committee officially
maintained it then most of the complaints about the difficulties of
maintaining backwards-compatible code and having to use conditional
compilation would go away. So we have a solution for a large subset of the
complaints here, why is nobody using it?

On Mon, Oct 5, 2015 at 6:27 AM, Sven Panne <svenpanne at gmail.com> wrote:

> 2015-10-05 11:59 GMT+02:00 Simon Thompson <s.j.thompson at kent.ac.uk>:
>
>> [...] It?s really interesting to have this discussion, which pulls in all
>> sorts of well-made points about orthogonality, teaching, the evolution of
>> the language and so on, but it simply goes to show that the process of
>> evolving Haskell is profoundly broken. [...]
>>
>
> I wouldn't necessarily call the process "broken", but it's a bit annoying:
> Because of the constant flux of minor changes in the language and the
> libraries, I've reached the stage where I'm totally unable to tell if my
> code will work for the whole GHC 7.x series. The only way I see is doing
> heavy testing on Travis CI and littering the code with #ifdefs after
> compilation failures. (BTW: Fun exercise: Try using (<>) and/or (<$>) in
> conjunction with -Wall. Bonus points for keeping the #ifdefs centralized.
> No clue how to do that...) This is less than satisfactory IMHO, and I would
> really prefer some other mode for introducing such changes: Perhaps these
> should be bundled and released e.g. every 2 years as Haskell2016,
> Haskell2018, etc. This way some stuff which belongs together (AMP, FTP,
> kicking out return, etc.) comes in slightly larger, but more sensible
> chunks.
>
> Don't get me wrong: Most of the proposed changes in itself are OK and
> should be done, it's only the way they are introduced should be improved...
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151005/815c07f2/attachment.html>

From hesselink at gmail.com  Mon Oct  5 13:57:39 2015
From: hesselink at gmail.com (Erik Hesselink)
Date: Mon, 5 Oct 2015 15:57:39 +0200
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <CAKRanNA7H13u22opFfcX07tbLdxpk-_cYn6s8QWrHmVm-kvPzQ@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 <CAKRanNA7H13u22opFfcX07tbLdxpk-_cYn6s8QWrHmVm-kvPzQ@mail.gmail.com>
Message-ID: <CAPeieQES=Yvb20pV10RtuF+L6--wz14bgmPT76zu0zcaRjeeyA@mail.gmail.com>

We use base-compat, and it works for addition of functions and
instances. It doesn't work for type class changes like this one.

On 5 October 2015 at 15:46, Greg Weber <greg at gregweber.info> wrote:
> Does anyone here use base-compat? It has worked quite well in my very
> limited usage. I think that if the libraries committee officially maintained
> it then most of the complaints about the difficulties of maintaining
> backwards-compatible code and having to use conditional compilation would go
> away. So we have a solution for a large subset of the complaints here, why
> is nobody using it?
>
> On Mon, Oct 5, 2015 at 6:27 AM, Sven Panne <svenpanne at gmail.com> wrote:
>>
>> 2015-10-05 11:59 GMT+02:00 Simon Thompson <s.j.thompson at kent.ac.uk>:
>>>
>>> [...] It?s really interesting to have this discussion, which pulls in all
>>> sorts of well-made points about orthogonality, teaching, the evolution of
>>> the language and so on, but it simply goes to show that the process of
>>> evolving Haskell is profoundly broken. [...]
>>
>>
>> I wouldn't necessarily call the process "broken", but it's a bit annoying:
>> Because of the constant flux of minor changes in the language and the
>> libraries, I've reached the stage where I'm totally unable to tell if my
>> code will work for the whole GHC 7.x series. The only way I see is doing
>> heavy testing on Travis CI and littering the code with #ifdefs after
>> compilation failures. (BTW: Fun exercise: Try using (<>) and/or (<$>) in
>> conjunction with -Wall. Bonus points for keeping the #ifdefs centralized. No
>> clue how to do that...) This is less than satisfactory IMHO, and I would
>> really prefer some other mode for introducing such changes: Perhaps these
>> should be bundled and released e.g. every 2 years as Haskell2016,
>> Haskell2018, etc. This way some stuff which belongs together (AMP, FTP,
>> kicking out return, etc.) comes in slightly larger, but more sensible
>> chunks.
>>
>> Don't get me wrong: Most of the proposed changes in itself are OK and
>> should be done, it's only the way they are introduced should be improved...
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>

From hvr at gnu.org  Mon Oct  5 14:32:40 2015
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Mon, 05 Oct 2015 16:32:40 +0200
Subject: Language Change Management (was: [Haskell-cafe] Monad of no `return`
 Proposal (MRP): Moving `return` out of `Monad`)
In-Reply-To: <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 (Sven Panne's message of "Mon, 5 Oct 2015 15:27:53 +0200")
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
Message-ID: <87lhbhperb.fsf_-_@gnu.org>

On 2015-10-05 at 15:27:53 +0200, Sven Panne wrote:
> 2015-10-05 11:59 GMT+02:00 Simon Thompson <s.j.thompson at kent.ac.uk>:
>
>> [...] It?s really interesting to have this discussion, which pulls in all
>> sorts of well-made points about orthogonality, teaching, the evolution of
>> the language and so on, but it simply goes to show that the process of
>> evolving Haskell is profoundly broken. [...]
>>
>
> I wouldn't necessarily call the process "broken", but it's a bit
> annoying: Because of the constant flux of minor changes in the
> language and the libraries, I've reached the stage where I'm totally
> unable to tell if my code will work for the whole GHC 7.x series. The
> only way I see is doing heavy testing on Travis CI and littering the
> code with #ifdefs after compilation failures. (BTW: Fun exercise: Try
> using (<>) and/or (<$>) in conjunction with -Wall. Bonus points for
> keeping the #ifdefs centralized.  No clue how to do that...) This is
> less than satisfactory IMHO, and I would really prefer some other mode
> for introducing such changes: Perhaps these should be bundled and
> released e.g. every 2 years as Haskell2016, Haskell2018, etc. This way
> some stuff which belongs together (AMP, FTP, kicking out return, etc.)
> comes in slightly larger, but more sensible chunks.
>
> Don't get me wrong: Most of the proposed changes in itself are OK and
> should be done, it's only the way they are introduced should be
> improved...

I think that part of the reason we have seen these changes occur in a
"constant flux" rather than in bigger coordinated chunks is that faith
in the Haskell Report process was (understandably) abandoned. And
without the Haskell Report as some kind of "clock generator" with which
to align/bundle related changes into logical units, changes occur
whenever they're proposed and agreed upon (which may take several
attempts as we've seen with the AMP and others).

I hope that the current attempt to revive the Haskell Prime process will
give us a chance to clean up the unfinished intermediate `base-4.8`
situation we're left with now after AMP, FTP et al, as the next Haskell
Report revision provides us with a milestone to work towards.

That being said, there's also the desire to have changes field-tested by
a wide audience on a wide range before integrating them into a Haskell
Report. Also I'm not sure if there would be less complaints if
AMP/FTP/MFP/MRP/etc as part of a new Haskell Report would be switched on
all at once in e.g. `base-5.0`, breaking almost *every* single package
out there at once.

For language changes we have a great way to field-test new extensions
before integrating them into the Report via `{-# LANGUAGE #-}` pragmas
in a nicely modular and composable way (i.e. a package enabling a
certain pragma doesn't require other packages to use it as well) which
have proven to be quite popular.

However, for the library side we lack a comparable mechanism at this
point. The closest we have, for instance, to support an isolated
Haskell2010 legacy environment is to use RebindableSyntax which IMO
isn't good enough in its current form[1]. And then there's the question
whether we want a Haskell2010 legacy environment that's isolated or
rather shares the types & typeclasses w/ `base`. If we require sharing
types and classes, then we may need some facility to implicitly
instanciate new superclasses (e.g. implicitly define Functor and
Applicative if only a Monad instance is defined). If we don't want to
share types & classes, we run into the problem that we can't easily mix
packages which depend on different revisions of the standard-library
(e.g. one using `base-4.8` and others which depend on a legacy
`haskell2010` base-API).  One way to solve this could be to mutually
exclude depending on both , `base-4.8` and `haskell2010`, in the same
install-plan (assuming `haskell2010` doesn't depend itself on
`base-4.8`)

In any case, I think we will have to think hard how to address
language/library change management in the future, especially if the
Haskell code-base continues to grow. Even just migrating the code base
between Haskell Report revisions is a problem. An extreme example
is the Python 2->3 transition which the Python ecosystem is still
suffering from today (afaik). Ideas welcome!



 [1]: IMO, we need something to be used at the definition site providing
      desugaring rules, rather than requiring the use-site to enable a
      generalised desugaring mechanism; I've been told that Agda has an
      interesting solution to this in its base libraries via 
      {-# LANGUAGE BUILTIN ... #-} pragmas.


Regards,
  H.V.Riedel

From gershomb at gmail.com  Mon Oct  5 14:32:21 2015
From: gershomb at gmail.com (Gershom B)
Date: Mon, 5 Oct 2015 10:32:21 -0400
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
Message-ID: <etPan.56128a31.41b8da8.7b73@mbp.local>

On October 5, 2015 at 6:00:00 AM, Simon Thompson (s.j.thompson at kent.ac.uk) wrote:
> Hello all. I write this to be a little provocative, but ?
>  
> It?s really interesting to have this discussion, which pulls in all sorts of well-made  
> points about orthogonality, teaching, the evolution of the language and so on, but it  
> simply goes to show that the process of evolving Haskell is profoundly broken.
>  
> Other languages do evolve, but in a managed and reflective way. Simply throwing in changes  
> that would have a profound impact on systems that are commercially and potentially safety  
> critical in an ? la carte, offhand, way seems like a breakdown of the collective responsibility  
> of the Haskell community to its users and, indirectly, to its future.

Hi Simon. I do in fact think this is provocative :-P

I want to object here to your characterization of what has been going on as ?simply throwing in changes?. The proposal seems very well and carefully worked through to provide a good migration strategy, even planning to alter the source of GHC to ensure that adequate hints are given for the indefinite transition period.

I also want to object to the idea that these changes would have ?a profound impact on systems?. As it stands, and I think this is an important criteria in any change, when ?phase 2? goes into affect, code that has compiled before may cease to compile until a minor change is made. However, code that continues to compile will continue to compile with the same behavior.

Now as to process itself, this is a change to core libraries. It has been proposed on the libraries list, which seems appropriate, and a vigorous discussion has ensued. This seems like a pretty decent process to me thus far. Do you have a better one in mind?

?Gershom

P.S. as a general point, I sympathize with concerns about breakage resulting from this, but I also think that the migration strategy proposed is good, and if people are concerned about breakage I think it would be useful if they could explain where they feel the migration strategy is insufficient to allay their concerns.

From hvriedel at gmail.com  Mon Oct  5 14:40:05 2015
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Mon, 05 Oct 2015 16:40:05 +0200
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <CAPeieQES=Yvb20pV10RtuF+L6--wz14bgmPT76zu0zcaRjeeyA@mail.gmail.com>
 (Erik Hesselink's message of "Mon, 5 Oct 2015 15:57:39 +0200")
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 <CAKRanNA7H13u22opFfcX07tbLdxpk-_cYn6s8QWrHmVm-kvPzQ@mail.gmail.com>
 <CAPeieQES=Yvb20pV10RtuF+L6--wz14bgmPT76zu0zcaRjeeyA@mail.gmail.com>
Message-ID: <87egh9peey.fsf@gmail.com>

On 2015-10-05 at 15:57:39 +0200, Erik Hesselink wrote:
>> Does anyone here use base-compat? It has worked quite well in my very
>> limited usage. I think that if the libraries committee officially maintained
>> it then most of the complaints about the difficulties of maintaining
>> backwards-compatible code and having to use conditional compilation would go
>> away. So we have a solution for a large subset of the complaints here, why
>> is nobody using it?

> We use base-compat, and it works for addition of functions and
> instances. It doesn't work for type class changes like this one.

Btw, this is exactly why GHC 7.10 droped support for the `haskell2010`
library package. See also

  https://ghc.haskell.org/ticket/9590

for more details about that (and some ideas how to recover a `haskell2010`
package in future GHC versions albeit with some tradeoffs).

Cheers,
  hvr

From bos at serpentine.com  Mon Oct  5 14:59:32 2015
From: bos at serpentine.com (Bryan O'Sullivan)
Date: Mon, 5 Oct 2015 07:59:32 -0700
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <etPan.56128a31.41b8da8.7b73@mbp.local>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
Message-ID: <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>

I would like to suggest that the bar for breaking all existing libraries, books, papers, and lecture notes should be very high; and that the benefit associated with such a breaking change should be correspondingly huge.

This proposal falls far short of both bars, to the extent that I am astonished and disappointed it is being seriously discussed ? and to general approval, no less ? on a date other than April 1. Surely some design flaws have consequences so small that they are not worth fixing.

I'll survive if it goes through, obviously, but it will commit me to a bunch of pointless make-work and compatibility ifdefs. I've previously expressed my sense that cross-version compatibility is a big tax on library maintainers. This proposal does not give me confidence that this cost is being taken seriously.

Thanks,
Bryan.

> On Oct 5, 2015, at 7:32 AM, Gershom B <gershomb at gmail.com> wrote:
> 
>> On October 5, 2015 at 6:00:00 AM, Simon Thompson (s.j.thompson at kent.ac.uk) wrote:
>> Hello all. I write this to be a little provocative, but ?
>> 
>> It?s really interesting to have this discussion, which pulls in all sorts of well-made  
>> points about orthogonality, teaching, the evolution of the language and so on, but it  
>> simply goes to show that the process of evolving Haskell is profoundly broken.
>> 
>> Other languages do evolve, but in a managed and reflective way. Simply throwing in changes  
>> that would have a profound impact on systems that are commercially and potentially safety  
>> critical in an ? la carte, offhand, way seems like a breakdown of the collective responsibility  
>> of the Haskell community to its users and, indirectly, to its future.
> 
> Hi Simon. I do in fact think this is provocative :-P
> 
> I want to object here to your characterization of what has been going on as ?simply throwing in changes?. The proposal seems very well and carefully worked through to provide a good migration strategy, even planning to alter the source of GHC to ensure that adequate hints are given for the indefinite transition period.
> 
> I also want to object to the idea that these changes would have ?a profound impact on systems?. As it stands, and I think this is an important criteria in any change, when ?phase 2? goes into affect, code that has compiled before may cease to compile until a minor change is made. However, code that continues to compile will continue to compile with the same behavior.
> 
> Now as to process itself, this is a change to core libraries. It has been proposed on the libraries list, which seems appropriate, and a vigorous discussion has ensued. This seems like a pretty decent process to me thus far. Do you have a better one in mind?
> 
> ?Gershom
> 
> P.S. as a general point, I sympathize with concerns about breakage resulting from this, but I also think that the migration strategy proposed is good, and if people are concerned about breakage I think it would be useful if they could explain where they feel the migration strategy is insufficient to allay their concerns.
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

From gershomb at gmail.com  Mon Oct  5 15:09:23 2015
From: gershomb at gmail.com (Gershom B)
Date: Mon, 5 Oct 2015 11:09:23 -0400
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
Message-ID: <etPan.561292df.6eacb1b6.7b73@mbp.local>

On October 5, 2015 at 10:59:35 AM, Bryan O'Sullivan (bos at serpentine.com) wrote:
> I would like to suggest that the bar for breaking all existing libraries, books, papers,  
> and lecture notes should be very high; and that the benefit associated with such a breaking  
> change should be correspondingly huge.
>  

My understanding of the argument here, which seems to make sense to me, is that the AMP already introduced a significant breaking change with regards to monads. Books and lecture notes have already not caught up to this, by and large. Hence, by introducing a further change, which _completes_ the general AMP project, then by the time books and lecture notes are all updated, they will be able to tell a much nicer story than the current one?

As for libraries, it has been pointed out, I believe, that without CPP one can write instances compatible with AMP, and also with AMP + MRP. One can also write code, sans CPP, compatible with pre- and post- AMP.

So the reason for choosing to not do MRP simultaneous with AMP was precisely to allow a gradual migration path where, sans CPP, people could write code compatible with the last three versions of GHC, as the general criteria has been.

So without arguing the necessity or not, I just want to weigh in with a technical opinion that if this goes through, my _estimation_ is that there will be a smooth and relatively painless migration period, the sky will not fall, good teaching material will remain good, those libraries that bitrot will tend to do so for a variety of reasons more significant than this, etc.

It is totally reasonable to have a discussion on whether this change is worth it at all. But let?s not overestimate the cost of it just to further tip the scales :-)

?gershom

From johan.tibell at gmail.com  Mon Oct  5 15:12:38 2015
From: johan.tibell at gmail.com (Johan Tibell)
Date: Mon, 5 Oct 2015 17:12:38 +0200
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <etPan.561292df.6eacb1b6.7b73@mbp.local>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
Message-ID: <CAK-tuPYL7anMKMeD4NNOvvR1iktsMeGdvQP7RMNCi_NQ21V0TQ@mail.gmail.com>

Perhaps we should weigh the +1 and -1s in this thread with the number of
lines of Haskell written by the voter? ;)

On Mon, Oct 5, 2015 at 5:09 PM, Gershom B <gershomb at gmail.com> wrote:

> On October 5, 2015 at 10:59:35 AM, Bryan O'Sullivan (bos at serpentine.com)
> wrote:
> > I would like to suggest that the bar for breaking all existing
> libraries, books, papers,
> > and lecture notes should be very high; and that the benefit associated
> with such a breaking
> > change should be correspondingly huge.
> >
>
> My understanding of the argument here, which seems to make sense to me, is
> that the AMP already introduced a significant breaking change with regards
> to monads. Books and lecture notes have already not caught up to this, by
> and large. Hence, by introducing a further change, which _completes_ the
> general AMP project, then by the time books and lecture notes are all
> updated, they will be able to tell a much nicer story than the current one?
>
> As for libraries, it has been pointed out, I believe, that without CPP one
> can write instances compatible with AMP, and also with AMP + MRP. One can
> also write code, sans CPP, compatible with pre- and post- AMP.
>
> So the reason for choosing to not do MRP simultaneous with AMP was
> precisely to allow a gradual migration path where, sans CPP, people could
> write code compatible with the last three versions of GHC, as the general
> criteria has been.
>
> So without arguing the necessity or not, I just want to weigh in with a
> technical opinion that if this goes through, my _estimation_ is that there
> will be a smooth and relatively painless migration period, the sky will not
> fall, good teaching material will remain good, those libraries that bitrot
> will tend to do so for a variety of reasons more significant than this, etc.
>
> It is totally reasonable to have a discussion on whether this change is
> worth it at all. But let?s not overestimate the cost of it just to further
> tip the scales :-)
>
> ?gershom
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151005/3beea509/attachment.html>

From lemming at henning-thielemann.de  Mon Oct  5 17:11:23 2015
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Mon, 5 Oct 2015 19:11:23 +0200 (CEST)
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <CAK-tuPYL7anMKMeD4NNOvvR1iktsMeGdvQP7RMNCi_NQ21V0TQ@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAK-tuPYL7anMKMeD4NNOvvR1iktsMeGdvQP7RMNCi_NQ21V0TQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1510051910060.7643@sputnik>


On Mon, 5 Oct 2015, Johan Tibell wrote:

> Perhaps we should weigh the +1 and -1s in this thread with the number of 
> lines of Haskell written by the voter? ;)

My prefered measure would the number of Haskell packages hosted at 
hub.darcs.net. :-)

From greg at gregorycollins.net  Mon Oct  5 18:34:31 2015
From: greg at gregorycollins.net (Gregory Collins)
Date: Mon, 5 Oct 2015 11:34:31 -0700
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <etPan.561292df.6eacb1b6.7b73@mbp.local>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
Message-ID: <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>

On Mon, Oct 5, 2015 at 8:09 AM, Gershom B <gershomb at gmail.com> wrote:

> My understanding of the argument here, which seems to make sense to me, is
> that the AMP already introduced a significant breaking change with regards
> to monads. Books and lecture notes have already not caught up to this, by
> and large. Hence, by introducing a further change, which _completes_ the
> general AMP project, then by the time books and lecture notes are all
> updated, they will be able to tell a much nicer story than the current one?


This is a multi-year, "boil the ocean"-style project, affecting literally
every Haskell user, and the end result after all of this labor is going to
be... a slightly spiffier bike shed?

Strongly -1 from me also. My experience over the last couple of years is
that every GHC release breaks my libraries in annoying ways that require
CPP to fix:

~/personal/src/snap ?  find . -name '*.hs' | xargs egrep
'#if.*(MIN_VERSION)|(GLASGOW_HASKELL)' | wc -l
64


As a user this is another bikeshedding change that is not going to benefit
me at all. Maintaining a Haskell library can be an exasperating exercise of
running on a treadmill to keep up with busywork caused by changes to the
core language and libraries. My feeling is starting to become that the
libraries committee is doing as much (if not more) to *cause* problems and
work for me than it is doing to improve the common infrastructure.

G
-- 
Gregory Collins <greg at gregorycollins.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151005/0016c4cd/attachment-0001.html>

From svenpanne at gmail.com  Mon Oct  5 18:58:57 2015
From: svenpanne at gmail.com (Sven Panne)
Date: Mon, 5 Oct 2015 20:58:57 +0200
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <etPan.561292df.6eacb1b6.7b73@mbp.local>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
Message-ID: <CANBN=mv6WPLRdvLJppOZ2=1zkd7sWKAHwTF3rHie27RS_YLesA@mail.gmail.com>

2015-10-05 17:09 GMT+02:00 Gershom B <gershomb at gmail.com>:

> On October 5, 2015 at 10:59:35 AM, Bryan O'Sullivan (bos at serpentine.com)
> wrote:
> [...] As for libraries, it has been pointed out, I believe, that without
> CPP one can write instances compatible with AMP, and also with AMP + MRP.
> One can also write code, sans CPP, compatible with pre- and post- AMP. [...]
>

Nope, at least not if you care about -Wall: If you take e.g. (<$>) which is
now part of the Prelude, you can't simply import some compatibility module,
because GHC might tell you (rightfully) that that import is redundant,
because (<$>) is already visible through the Prelude. So you'll have to use
CPP to avoid that import on base >= 4.8, be it from it Data.Functor,
Control.Applicative or some compat-* module. And you'll have to use CPP in
each and every module using <$> then, unless I miss something obvious.
AFAICT all transitioning guides ignore -Wall and friends...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151005/f3c8d168/attachment.html>

From johan.tibell at gmail.com  Mon Oct  5 19:01:16 2015
From: johan.tibell at gmail.com (Johan Tibell)
Date: Mon, 5 Oct 2015 21:01:16 +0200
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
Message-ID: <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>

On Mon, Oct 5, 2015 at 8:34 PM, Gregory Collins <greg at gregorycollins.net>
wrote:

>
> On Mon, Oct 5, 2015 at 8:09 AM, Gershom B <gershomb at gmail.com> wrote:
>
>> My understanding of the argument here, which seems to make sense to me,
>> is that the AMP already introduced a significant breaking change with
>> regards to monads. Books and lecture notes have already not caught up to
>> this, by and large. Hence, by introducing a further change, which
>> _completes_ the general AMP project, then by the time books and lecture
>> notes are all updated, they will be able to tell a much nicer story than
>> the current one?
>
>
> This is a multi-year, "boil the ocean"-style project, affecting literally
> every Haskell user, and the end result after all of this labor is going to
> be... a slightly spiffier bike shed?
>
> Strongly -1 from me also. My experience over the last couple of years is
> that every GHC release breaks my libraries in annoying ways that require
> CPP to fix:
>
> ~/personal/src/snap ?  find . -name '*.hs' | xargs egrep
> '#if.*(MIN_VERSION)|(GLASGOW_HASKELL)' | wc -l
> 64
>
>
> As a user this is another bikeshedding change that is not going to benefit
> me at all. Maintaining a Haskell library can be an exasperating exercise of
> running on a treadmill to keep up with busywork caused by changes to the
> core language and libraries. My feeling is starting to become that the
> libraries committee is doing as much (if not more) to *cause* problems
> and work for me than it is doing to improve the common infrastructure.
>

On the libraries I maintain and have a copy of on my computer right now: 329
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151005/4542b2ff/attachment.html>

From hesselink at gmail.com  Mon Oct  5 19:02:26 2015
From: hesselink at gmail.com (Erik Hesselink)
Date: Mon, 5 Oct 2015 21:02:26 +0200
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <CANBN=mv6WPLRdvLJppOZ2=1zkd7sWKAHwTF3rHie27RS_YLesA@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CANBN=mv6WPLRdvLJppOZ2=1zkd7sWKAHwTF3rHie27RS_YLesA@mail.gmail.com>
Message-ID: <CAPeieQFUzFD4q0tToxZiNc4_GKkH2TbVvZpe65P_NzawOftCrA@mail.gmail.com>

On 5 October 2015 at 20:58, Sven Panne <svenpanne at gmail.com> wrote:
> 2015-10-05 17:09 GMT+02:00 Gershom B <gershomb at gmail.com>:
>>
>> [...] As for libraries, it has been pointed out, I believe, that without
>> CPP one can write instances compatible with AMP, and also with AMP + MRP.
>> One can also write code, sans CPP, compatible with pre- and post- AMP. [...]
>
> Nope, at least not if you care about -Wall: If you take e.g. (<$>) which is
> now part of the Prelude, you can't simply import some compatibility module,
> because GHC might tell you (rightfully) that that import is redundant,
> because (<$>) is already visible through the Prelude. So you'll have to use
> CPP to avoid that import on base >= 4.8, be it from it Data.Functor,
> Control.Applicative or some compat-* module. And you'll have to use CPP in
> each and every module using <$> then, unless I miss something obvious.
> AFAICT all transitioning guides ignore -Wall and friends...

Does the hack mentioned on the GHC trac [1] work for this? It seems a
bit fragile but that page says it works and it avoids CPP.

Erik

[1] https://ghc.haskell.org/trac/ghc/wiki/Migration/7.10#GHCsaysTheimportof...isredundant

From johan.tibell at gmail.com  Mon Oct  5 19:05:40 2015
From: johan.tibell at gmail.com (Johan Tibell)
Date: Mon, 5 Oct 2015 21:05:40 +0200
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <CAPeieQFUzFD4q0tToxZiNc4_GKkH2TbVvZpe65P_NzawOftCrA@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CANBN=mv6WPLRdvLJppOZ2=1zkd7sWKAHwTF3rHie27RS_YLesA@mail.gmail.com>
 <CAPeieQFUzFD4q0tToxZiNc4_GKkH2TbVvZpe65P_NzawOftCrA@mail.gmail.com>
Message-ID: <CAK-tuPa7w_=5gXfZ78NDWPAWX1K8_rM+9jUbm7yZUCAwZYdr5Q@mail.gmail.com>

On Mon, Oct 5, 2015 at 9:02 PM, Erik Hesselink <hesselink at gmail.com> wrote:

> On 5 October 2015 at 20:58, Sven Panne <svenpanne at gmail.com> wrote:
> > 2015-10-05 17:09 GMT+02:00 Gershom B <gershomb at gmail.com>:
> >>
> >> [...] As for libraries, it has been pointed out, I believe, that without
> >> CPP one can write instances compatible with AMP, and also with AMP +
> MRP.
> >> One can also write code, sans CPP, compatible with pre- and post- AMP.
> [...]
> >
> > Nope, at least not if you care about -Wall: If you take e.g. (<$>) which
> is
> > now part of the Prelude, you can't simply import some compatibility
> module,
> > because GHC might tell you (rightfully) that that import is redundant,
> > because (<$>) is already visible through the Prelude. So you'll have to
> use
> > CPP to avoid that import on base >= 4.8, be it from it Data.Functor,
> > Control.Applicative or some compat-* module. And you'll have to use CPP
> in
> > each and every module using <$> then, unless I miss something obvious.
> > AFAICT all transitioning guides ignore -Wall and friends...
>
> Does the hack mentioned on the GHC trac [1] work for this? It seems a
> bit fragile but that page says it works and it avoids CPP.
>

No it doesn't, if you also don't want closed import lists (which you
should).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151005/fbc07861/attachment.html>

From cma at bitemyapp.com  Mon Oct  5 19:08:09 2015
From: cma at bitemyapp.com (Christopher Allen)
Date: Mon, 5 Oct 2015 14:08:09 -0500
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
Message-ID: <CADnndOqmZteBtMHveFO=+=vmnPDki2rJ7=+bOEXhWMD9sfnGWw@mail.gmail.com>

I'm writing a book (http://haskellbook.com/) with my coauthor. It is up to
date with GHC 7.10. AMP made things better, not harder, with respect to
teaching Haskell. BBP required some explanation of "ignore this type, we're
asserting a different one", but the positives are still better than the
negatives.

Please don't use existing or forthcoming books as an excuse to do or not-do
things. Do what's right for the users of the language.

On Mon, Oct 5, 2015 at 2:01 PM, Johan Tibell <johan.tibell at gmail.com> wrote:

> On Mon, Oct 5, 2015 at 8:34 PM, Gregory Collins <greg at gregorycollins.net>
> wrote:
>
>>
>> On Mon, Oct 5, 2015 at 8:09 AM, Gershom B <gershomb at gmail.com> wrote:
>>
>>> My understanding of the argument here, which seems to make sense to me,
>>> is that the AMP already introduced a significant breaking change with
>>> regards to monads. Books and lecture notes have already not caught up to
>>> this, by and large. Hence, by introducing a further change, which
>>> _completes_ the general AMP project, then by the time books and lecture
>>> notes are all updated, they will be able to tell a much nicer story than
>>> the current one?
>>
>>
>> This is a multi-year, "boil the ocean"-style project, affecting literally
>> every Haskell user, and the end result after all of this labor is going to
>> be... a slightly spiffier bike shed?
>>
>> Strongly -1 from me also. My experience over the last couple of years is
>> that every GHC release breaks my libraries in annoying ways that require
>> CPP to fix:
>>
>> ~/personal/src/snap ?  find . -name '*.hs' | xargs egrep
>> '#if.*(MIN_VERSION)|(GLASGOW_HASKELL)' | wc -l
>> 64
>>
>>
>> As a user this is another bikeshedding change that is not going to
>> benefit me at all. Maintaining a Haskell library can be an exasperating
>> exercise of running on a treadmill to keep up with busywork caused by
>> changes to the core language and libraries. My feeling is starting to
>> become that the libraries committee is doing as much (if not more) to
>> *cause* problems and work for me than it is doing to improve the common
>> infrastructure.
>>
>
> On the libraries I maintain and have a copy of on my computer right now:
> 329
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>


-- 
Chris Allen
Currently working on http://haskellbook.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151005/e339ef4e/attachment-0001.html>

From simons at cryp.to  Mon Oct  5 19:17:25 2015
From: simons at cryp.to (Peter Simons)
Date: Mon, 05 Oct 2015 21:17:25 +0200
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CANBN=mv6WPLRdvLJppOZ2=1zkd7sWKAHwTF3rHie27RS_YLesA@mail.gmail.com>
Message-ID: <874mi5jfay.fsf@write-only.cryp.to>

Sven Panne <svenpanne at gmail.com> writes:

 > If you take e.g. (<$>) which is now part of the Prelude, you can't
 > simply import some compatibility module, because GHC might tell you
 > (rightfully) that that import is redundant, because (<$>) is already
 > visible through the Prelude.

Yes, the proper solution is slightly more complicated than just
importing Prelude.Compat [1]. You also have to specify "import
Prelude ()" -- or compile with NoImplicitPrelude, if you prefer
that kind of thing.

Best regards
Peter


[1] http://hackage.haskell.org/package/base-compat-0.8.2/docs/Prelude-Compat.html


From gale at sefer.org  Mon Oct  5 20:17:48 2015
From: gale at sefer.org (Yitzchak Gale)
Date: Mon, 5 Oct 2015 23:17:48 +0300
Subject: Monad of no `return` Proposal (MRP): Moving `return` out of
 `Monad`
In-Reply-To: <m2k2r3ss32.fsf@newartisans.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <mumqmr$r00$1@ger.gmane.org> <560F28D8.1070406@nottingham.ac.uk>
 <muo5rf$jok$1@ger.gmane.org> <560FA7A9.1050806@nottingham.ac.uk>
 <m2k2r3ss32.fsf@newartisans.com>
Message-ID: <CAOrUaLbGqkYLSFhVJ7HRoDx3HQXJBcNaNiTMX1T19d+g5OanrA@mail.gmail.com>

John Wiegley wrote:
> You made a great argument, Henrik, and you've changed my enthusiastic +1 to
> +0, until it can be bundled with some other, more necessary, breaking change.

I, too, am hereby changing my +1 to a 0.

(Even though John himself eventually went back to +1.)

I am one of the people who would eventually pay a steep
price for this change. I voted +1 only because there seemed
to be a clear consensus to do it. I intended to express
with my vote that I am willing to pay that price if there
is such a consensus.

But since then, quite a few very prominent members of
the community have come out strongly against
this change. So I am now climbing back onto the fence,
which is where I will sit until/unless a consensus one
way or the other develops again.

-Yitz

From acfoltzer at gmail.com  Mon Oct  5 21:23:08 2015
From: acfoltzer at gmail.com (Adam Foltzer)
Date: Mon, 5 Oct 2015 14:23:08 -0700
Subject: Language Change Management (was: [Haskell-cafe] Monad of no
 `return` Proposal (MRP): Moving `return` out of `Monad`)
In-Reply-To: <87lhbhperb.fsf_-_@gnu.org>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 <87lhbhperb.fsf_-_@gnu.org>
Message-ID: <CAPorAaGN0P8PMh4Nvu=zD_XGc7g+t_gQZBtzKtQTDSgWrjEs8Q@mail.gmail.com>

Thanks for splitting this off, as it really deserves its own conversation.

% find cryptol -name '*.hs' | xargs egrep
'#if.*(MIN_VERSION)|(GLASGOW_HASKELL)' | wc -l
      49
% find saw-script -name '*.hs' | xargs egrep
'#if.*(MIN_VERSION)|(GLASGOW_HASKELL)' | wc -l
     242

I introduced most of these in order to accommodate AMP, and now I learn
that there is another proposal that is considered to be part-and-parcel
with AMP where I will have to make yet more changes to the same code and
presumably introduce another layer of #ifdefs. As proposed, I will spend
2*n hours implementing, testing, and releasing these changes. Had both
changes been bundled, it would have been 2*(n+?).

 Also I'm not sure if there would be less complaints if AMP/FTP/MFP/MRP/etc
> as part of a new Haskell Report would be switched on all at once in e.g.
> `base-5.0`, breaking almost *every* single package out there at once.


I doubt the number of complaints-per-change would be fewer, but I'm
strongly in favor of moving away from what feels like a treadmill that
doesn't value the time of developers and that doesn't account for the
more-than-sum-of-parts cost of the "constant flux".

Thanks,
Adam

On Mon, Oct 5, 2015 at 7:32 AM, Herbert Valerio Riedel <hvr at gnu.org> wrote:

> On 2015-10-05 at 15:27:53 +0200, Sven Panne wrote:
> > 2015-10-05 11:59 GMT+02:00 Simon Thompson <s.j.thompson at kent.ac.uk>:
> >
> >> [...] It?s really interesting to have this discussion, which pulls in
> all
> >> sorts of well-made points about orthogonality, teaching, the evolution
> of
> >> the language and so on, but it simply goes to show that the process of
> >> evolving Haskell is profoundly broken. [...]
> >>
> >
> > I wouldn't necessarily call the process "broken", but it's a bit
> > annoying: Because of the constant flux of minor changes in the
> > language and the libraries, I've reached the stage where I'm totally
> > unable to tell if my code will work for the whole GHC 7.x series. The
> > only way I see is doing heavy testing on Travis CI and littering the
> > code with #ifdefs after compilation failures. (BTW: Fun exercise: Try
> > using (<>) and/or (<$>) in conjunction with -Wall. Bonus points for
> > keeping the #ifdefs centralized.  No clue how to do that...) This is
> > less than satisfactory IMHO, and I would really prefer some other mode
> > for introducing such changes: Perhaps these should be bundled and
> > released e.g. every 2 years as Haskell2016, Haskell2018, etc. This way
> > some stuff which belongs together (AMP, FTP, kicking out return, etc.)
> > comes in slightly larger, but more sensible chunks.
> >
> > Don't get me wrong: Most of the proposed changes in itself are OK and
> > should be done, it's only the way they are introduced should be
> > improved...
>
> I think that part of the reason we have seen these changes occur in a
> "constant flux" rather than in bigger coordinated chunks is that faith
> in the Haskell Report process was (understandably) abandoned. And
> without the Haskell Report as some kind of "clock generator" with which
> to align/bundle related changes into logical units, changes occur
> whenever they're proposed and agreed upon (which may take several
> attempts as we've seen with the AMP and others).
>
> I hope that the current attempt to revive the Haskell Prime process will
> give us a chance to clean up the unfinished intermediate `base-4.8`
> situation we're left with now after AMP, FTP et al, as the next Haskell
> Report revision provides us with a milestone to work towards.
>
> That being said, there's also the desire to have changes field-tested by
> a wide audience on a wide range before integrating them into a Haskell
> Report. Also I'm not sure if there would be less complaints if
> AMP/FTP/MFP/MRP/etc as part of a new Haskell Report would be switched on
> all at once in e.g. `base-5.0`, breaking almost *every* single package
> out there at once.
>
> For language changes we have a great way to field-test new extensions
> before integrating them into the Report via `{-# LANGUAGE #-}` pragmas
> in a nicely modular and composable way (i.e. a package enabling a
> certain pragma doesn't require other packages to use it as well) which
> have proven to be quite popular.
>
> However, for the library side we lack a comparable mechanism at this
> point. The closest we have, for instance, to support an isolated
> Haskell2010 legacy environment is to use RebindableSyntax which IMO
> isn't good enough in its current form[1]. And then there's the question
> whether we want a Haskell2010 legacy environment that's isolated or
> rather shares the types & typeclasses w/ `base`. If we require sharing
> types and classes, then we may need some facility to implicitly
> instanciate new superclasses (e.g. implicitly define Functor and
> Applicative if only a Monad instance is defined). If we don't want to
> share types & classes, we run into the problem that we can't easily mix
> packages which depend on different revisions of the standard-library
> (e.g. one using `base-4.8` and others which depend on a legacy
> `haskell2010` base-API).  One way to solve this could be to mutually
> exclude depending on both , `base-4.8` and `haskell2010`, in the same
> install-plan (assuming `haskell2010` doesn't depend itself on
> `base-4.8`)
>
> In any case, I think we will have to think hard how to address
> language/library change management in the future, especially if the
> Haskell code-base continues to grow. Even just migrating the code base
> between Haskell Report revisions is a problem. An extreme example
> is the Python 2->3 transition which the Python ecosystem is still
> suffering from today (afaik). Ideas welcome!
>
>
>
>  [1]: IMO, we need something to be used at the definition site providing
>       desugaring rules, rather than requiring the use-site to enable a
>       generalised desugaring mechanism; I've been told that Agda has an
>       interesting solution to this in its base libraries via
>       {-# LANGUAGE BUILTIN ... #-} pragmas.
>
>
> Regards,
>   H.V.Riedel
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151005/f7f523ac/attachment.html>

From greg at gregorycollins.net  Tue Oct  6 00:40:43 2015
From: greg at gregorycollins.net (Gregory Collins)
Date: Mon, 5 Oct 2015 17:40:43 -0700
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <CAGcFDtjuOAd0M2AVRK8Cx3kG0AEAHZ_D7WR9Z9yOmZ6Lo7uYEw@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca>
 <CAGcFDtjuOAd0M2AVRK8Cx3kG0AEAHZ_D7WR9Z9yOmZ6Lo7uYEw@mail.gmail.com>
Message-ID: <CAHZrzdqPbv5OHzE8UEnxQ0_TXcmQbatJZC6g2mg9eBz1-SP_Dw@mail.gmail.com>

On Mon, Oct 5, 2015 at 3:18 PM, Bryan Richter <b at chreekat.net> wrote:

> Hang on a moment, are you saying that all the people writing to argue
> that these changes would require them to write dozens more #ifdef's
> actually don't have to write any at all?
>

Um, no, it usually isn't anything like that. Here's a sampling of some of
the things I've used CPP for in the past few years:

   - After GHC 7.4, when using a newtype in FFI imports you need to import
   the constructor, i.e. "import Foreign.C.Types(CInt(..))" --- afaik CPP is
   the only way to shut up warnings everywhere
   - defaultTimeLocale moved from System.Locale to Data.Time.Format in
   time-1.5 (no compat package for this, afaik)
   - one of many various changes to Typeable in the GHC 7.* series
   (deriving works better now, mkTyCon vs mkTyCon3, etc)
   - Do I have to hide "catch" from Prelude, or not? It got moved, and
   "hiding" gives an error if the symbol you're trying to hide is missing.
   Time to break out the CPP (and curse myself for not just using the
   qualified import in the first place)
   - Do I get monoid functions from Prelude or from Data.Monoid? Same w/
   Applicative, Foldable, Word. I don't know where anything is supposed to
   live anymore, or which sequence of imports will shut up spurious warnings
   on all four versions of GHC I support, so the lowest-friction fix is: break
   out the #ifdef spackle
   - ==# and friends return Int# instead of Bool after GHC 7.8.1
   - To use functions like "tryReadMVar", "unsafeShiftR", and
   "atomicModifyIORef'" that are in recent base versions but not older ones
   (this is a place where CPP use is actually justified)

-- 
Gregory Collins <greg at gregorycollins.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151005/c398f795/attachment-0001.html>

From wren at community.haskell.org  Tue Oct  6 00:49:19 2015
From: wren at community.haskell.org (wren romano)
Date: Mon, 5 Oct 2015 20:49:19 -0400
Subject: Language Change Management (was: [Haskell-cafe] Monad of no
 `return` Proposal (MRP): Moving `return` out of `Monad`)
In-Reply-To: <CAPorAaGN0P8PMh4Nvu=zD_XGc7g+t_gQZBtzKtQTDSgWrjEs8Q@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 <87lhbhperb.fsf_-_@gnu.org>
 <CAPorAaGN0P8PMh4Nvu=zD_XGc7g+t_gQZBtzKtQTDSgWrjEs8Q@mail.gmail.com>
Message-ID: <CABUjdS5W5cac8m9kUEXD=LQibJADoj32w1fc9KsfPZPe803gtQ@mail.gmail.com>

On Mon, Oct 5, 2015 at 5:23 PM, Adam Foltzer <acfoltzer at gmail.com> wrote:
>>  Also I'm not sure if there would be less complaints if
>> AMP/FTP/MFP/MRP/etc as part of a new Haskell Report would be switched on all
>> at once in e.g. `base-5.0`, breaking almost *every* single package out there
>> at once.
>
> I doubt the number of complaints-per-change would be fewer, but I'm strongly
> in favor of moving away from what feels like a treadmill that doesn't value
> the time of developers and that doesn't account for the
> more-than-sum-of-parts cost of the "constant flux".

Broadly speaking, I'm a "fix it now rather than later" sort of person
in Haskell because I've seen how long things can linger before finally
getting fixed (even when everyone agrees on what the fix should be and
agrees that it should be done). However, as I mentioned in the
originating thread, I think that ?at this point? when it comes to
AMP/FTP/MFP/MRP/etc we should really aim for the haskell' committee to
work out a comprehensive solution (as soon as possible), and then
enact all the changes at once when switching to
Haskell201X/base-5.0/whatevs. I understand the motivations for wanting
things to be field-tested before making it into the report, but I
don't think having a series of rapid incremental changes is the
correct approach here. Because we're dealing with the Prelude and the
core classes, the amount of breakage (and CPP used to paper over it)
here is much higher than our usual treadmill of changes; so we should
take that into account when planning how to roll the changes out.

-- 
Live well,
~wren

From rf at rufflewind.com  Tue Oct  6 01:00:21 2015
From: rf at rufflewind.com (Phil Ruffwind)
Date: Mon, 5 Oct 2015 21:00:21 -0400
Subject: Language Change Management (was: [Haskell-cafe] Monad of no
 `return` Proposal (MRP): Moving `return` out of `Monad`)
In-Reply-To: <CAPorAaGN0P8PMh4Nvu=zD_XGc7g+t_gQZBtzKtQTDSgWrjEs8Q@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 <87lhbhperb.fsf_-_@gnu.org>
 <CAPorAaGN0P8PMh4Nvu=zD_XGc7g+t_gQZBtzKtQTDSgWrjEs8Q@mail.gmail.com>
Message-ID: <CADb8sTN6vZ6NgAnRTrgUsDhpgn_hF64bovq1uWxMiCzokyEUVg@mail.gmail.com>

Having so many #ifdefs isn't by itself a major problem.  Yes, it does
introduce a small increase in compilation time and the size of the
codebase.  The real cost is the developer time: every developer has to
come up with these these #ifdef clauses from scratch for every change
that gets made, tailored to their specific code.  As more and more get
added, it becomes more and more of a confusing mess.

It makes me wonder if this can be automated somehow.  It would be nice
to have a mechanism to alleviate this cost so that most developers
downstream (provided that the code was written in a reasonable manner)
only need to make a minimal effort to keep up, while still being able
to write code that works for a reasonably large range of GHC versions.
The burden of breaking changes right now is on the downstream
developers, but perhaps there could be a way to shift most of that
upstream to avoid this large duplication of effort.

Haskell should be allowed to evolve, but there also needs to be a
counterweight mechanism that provides stability in the face of
constant changes.  It would be something similar in spirit to
base-compat, but I don't think a library package alone is powerful
enough to solve the problem: a missing 'return' for example is not
something a library can just patch in.

I don't have any preference for "lots of small changes" vs "one big
change": in the former, there is a lot of overhead needed to keep
track of and fix these small changes; in the latter, there is a risk
of introducing a rift that fragments the community (cf Python 2 vs 3).
Maybe something in-between would be the best.

From amindfv at gmail.com  Tue Oct  6 01:24:26 2015
From: amindfv at gmail.com (amindfv at gmail.com)
Date: Mon, 5 Oct 2015 21:24:26 -0400
Subject: Language Change Management (was: [Haskell-cafe] Monad of no
 `return` Proposal (MRP): Moving `return` out of `Monad`)
In-Reply-To: <CADb8sTN6vZ6NgAnRTrgUsDhpgn_hF64bovq1uWxMiCzokyEUVg@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 <87lhbhperb.fsf_-_@gnu.org>
 <CAPorAaGN0P8PMh4Nvu=zD_XGc7g+t_gQZBtzKtQTDSgWrjEs8Q@mail.gmail.com>
 <CADb8sTN6vZ6NgAnRTrgUsDhpgn_hF64bovq1uWxMiCzokyEUVg@mail.gmail.com>
Message-ID: <2F902D16-CED6-46D4-A596-5826DC14E5EF@gmail.com>

Another problem with #ifdefs (especially machine-generated ones) is that it makes code much harder to read. One of the things I love about Haskell is the ability to read code and literally see an author describe how they're thinking about the domain. #ifdefs make life less fun :)

Tom


> El 5 oct 2015, a las 21:00, Phil Ruffwind <rf at rufflewind.com> escribi?:
> 
> Having so many #ifdefs isn't by itself a major problem.  Yes, it does
> introduce a small increase in compilation time and the size of the
> codebase.  The real cost is the developer time: every developer has to
> come up with these these #ifdef clauses from scratch for every change
> that gets made, tailored to their specific code.  As more and more get
> added, it becomes more and more of a confusing mess.
> 
> It makes me wonder if this can be automated somehow.  It would be nice
> to have a mechanism to alleviate this cost so that most developers
> downstream (provided that the code was written in a reasonable manner)
> only need to make a minimal effort to keep up, while still being able
> to write code that works for a reasonably large range of GHC versions.
> The burden of breaking changes right now is on the downstream
> developers, but perhaps there could be a way to shift most of that
> upstream to avoid this large duplication of effort.
> 
> Haskell should be allowed to evolve, but there also needs to be a
> counterweight mechanism that provides stability in the face of
> constant changes.  It would be something similar in spirit to
> base-compat, but I don't think a library package alone is powerful
> enough to solve the problem: a missing 'return' for example is not
> something a library can just patch in.
> 
> I don't have any preference for "lots of small changes" vs "one big
> change": in the former, there is a lot of overhead needed to keep
> track of and fix these small changes; in the latter, there is a risk
> of introducing a rift that fragments the community (cf Python 2 vs 3).
> Maybe something in-between would be the best.
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

From oleg.grenrus at iki.fi  Tue Oct  6 04:17:53 2015
From: oleg.grenrus at iki.fi (Oleg Grenrus)
Date: Tue, 6 Oct 2015 07:17:53 +0300
Subject: Since notice in instance declarations.
In-Reply-To: <CADb8sTNRnsYnGbUWRXYYZB9_CBt+YQH+hE0dhowx=MPfd_D_ZA@mail.gmail.com>
References: <9E1012B5-20F9-4D0F-AAF6-50C203A9B055@iki.fi>
 <CADb8sTNRnsYnGbUWRXYYZB9_CBt+YQH+hE0dhowx=MPfd_D_ZA@mail.gmail.com>
Message-ID: <14CD79E8-BA00-4637-B161-0C60A1DBC41E@iki.fi>

I created a github issue for this

https://github.com/haskell/haddock/issues/452 <https://github.com/haskell/haddock/issues/452>

Still e.g. `base` does since annotations manually. In fact, every package I contributed lately does them manually :(

- Oleg G

> On 02 Oct 2015, at 19:32, Phil Ruffwind <rf at rufflewind.com> wrote:
> 
> Since Haddock now supports the '@since' annotation, it might be better
> to implement it in Haddock rather than have everyone do it manually.
> 
> https://github.com/haskell/haddock/issues/26
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151006/d69d069f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151006/d69d069f/attachment.sig>

From ivan.miljenovic at gmail.com  Tue Oct  6 07:04:02 2015
From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic)
Date: Tue, 6 Oct 2015 18:04:02 +1100
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <CAHZrzdqPbv5OHzE8UEnxQ0_TXcmQbatJZC6g2mg9eBz1-SP_Dw@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca>
 <CAGcFDtjuOAd0M2AVRK8Cx3kG0AEAHZ_D7WR9Z9yOmZ6Lo7uYEw@mail.gmail.com>
 <CAHZrzdqPbv5OHzE8UEnxQ0_TXcmQbatJZC6g2mg9eBz1-SP_Dw@mail.gmail.com>
Message-ID: <CA+u6gbw5g9jqA17O_wFWkyaTmKXJF0oXYSp72pVCxEY4i21uRg@mail.gmail.com>

On 6 October 2015 at 11:40, Gregory Collins <greg at gregorycollins.net> wrote:
>
> defaultTimeLocale moved from System.Locale to Data.Time.Format in time-1.5
> (no compat package for this, afaik)

http://hackage.haskell.org/package/time-locale-compat

-- 
Ivan Lazar Miljenovic
Ivan.Miljenovic at gmail.com
http://IvanMiljenovic.wordpress.com

From spam at scientician.net  Tue Oct  6 07:40:49 2015
From: spam at scientician.net (Bardur Arantsson)
Date: Tue, 6 Oct 2015 09:40:49 +0200
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <CAHZrzdqPbv5OHzE8UEnxQ0_TXcmQbatJZC6g2mg9eBz1-SP_Dw@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca>
 <CAGcFDtjuOAd0M2AVRK8Cx3kG0AEAHZ_D7WR9Z9yOmZ6Lo7uYEw@mail.gmail.com>
 <CAHZrzdqPbv5OHzE8UEnxQ0_TXcmQbatJZC6g2mg9eBz1-SP_Dw@mail.gmail.com>
Message-ID: <muvtu1$jc0$1@ger.gmane.org>

On 10/06/2015 02:40 AM, Gregory Collins wrote:
> On Mon, Oct 5, 2015 at 3:18 PM, Bryan Richter <b at chreekat.net> wrote:
> 
>> Hang on a moment, are you saying that all the people writing to argue
>> that these changes would require them to write dozens more #ifdef's
>> actually don't have to write any at all?
>>
> 
> Um, no, it usually isn't anything like that. Here's a sampling of some of
> the things I've used CPP for in the past few years:
> 
>    - After GHC 7.4, when using a newtype in FFI imports you need to import
>    the constructor, i.e. "import Foreign.C.Types(CInt(..))" --- afaik CPP is
>    the only way to shut up warnings everywhere

Having code meant for 4 different versions of a compiler be completely
-Wall clean is not a reasonable goal. This doesn't even happen for C++
compilers! (If my experience is anything to go by.)

It's also the reason -Werror is forbidden in Hackage uploads. (At least,
I think it is. Isn't it?)

Also, GHC 7.4 was released 2? years ago. You may have my sympathies for
trying to support it, but unless you're getting paid for it I don't
think it's reasonable to expect you to. (If you're getting paid, then I
don't understand the complaint -- it might be a bit of make-work, but I
think everybody is subjected to that.)

>    - defaultTimeLocale moved from System.Locale to Data.Time.Format in
>    time-1.5 (no compat package for this, afaik)

"time-locale-compat" as Ivan pointed out.

>    - one of many various changes to Typeable in the GHC 7.* series
>    (deriving works better now, mkTyCon vs mkTyCon3, etc)

I think these were because people learned that they could be done
better? (Also, I believe there was something here about these changes
being necessary for Safe Haskell, namely forbidding user-written instances?)

Is Typeable part of Haskell 2010?

>    - Do I have to hide "catch" from Prelude, or not? It got moved, and
>    "hiding" gives an error if the symbol you're trying to hide is missing.
>    Time to break out the CPP (and curse myself for not just using the
>    qualified import in the first place)

Could you solve it with a qualified import? Then why use CPP?

(Incidentally, I think this is evidence that the Prelude should be an
explicit import like in PureScript.)

>    - Do I get monoid functions from Prelude or from Data.Monoid? Same w/
>    Applicative, Foldable, Word. I don't know where anything is supposed to
>    live anymore, or which sequence of imports will shut up spurious warnings
>    on all four versions of GHC I support, so the lowest-friction fix is: break
>    out the #ifdef spackle

You don't *have* to shut up all warnings. (Unless we're talking
deprecation warnings *and* you're getting close to the cutoff point.)

>    - ==# and friends return Int# instead of Bool after GHC 7.8.1

Hoogle find ==# (and I've never heard it of before).

>    - To use functions like "tryReadMVar", "unsafeShiftR", and
>    "atomicModifyIORef'" that are in recent base versions but not older ones
>    (this is a place where CPP use is actually justified)
> 

Well, yeah, new functions don't magically appear in old versions. I
don't anybody expects that :).

Regards,



From johan.tibell at gmail.com  Tue Oct  6 08:12:13 2015
From: johan.tibell at gmail.com (Johan Tibell)
Date: Tue, 6 Oct 2015 10:12:13 +0200
Subject: MRP, 3-year-support-window, and the non-requirement of CPP (was:
 [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return`
 out of `Monad`)
In-Reply-To: <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
Message-ID: <CAK-tuPYxNM9uoywucSOT6O3RFhw2AGhCvBTKjOruKQK2V5dY3Q@mail.gmail.com>

(Resending with smaller recipient list to avoid getting stuck in the
moderator queue.)

On Tue, Oct 6, 2015 at 9:10 AM, Herbert Valerio Riedel <hvr at gnu.org> wrote:

> On 2015-10-05 at 21:01:16 +0200, Johan Tibell wrote:
> > On the libraries I maintain and have a copy of on my computer right now:
> 329
>
>
> Although this was already pointed out to you in a response to a Tweet of
> yours, I'd like to expand on this here to clarify:
>
>
> You say that you stick to the 3-major-ghc-release support-window
> convention for your libraries. This is good, because then you don't need
> any CPP at all! Here's why:
>
> [...]
>

So what do I have to write today to have my Monad instances be:

 * Warning free - Warnings are useful. Turning them off or having spurious
warnings both contribute to bugs.
 * Use imports that either are qualified or have explicit import lists -
Unqualified imports makes code more likely to break when dependencies add
exports.
 * Don't use CPP.

Neither AMP or MRP includes a recipe for this in their proposal. AMP got
one post-facto on the Wiki. It turns out that the workaround there didn't
work (we tried it in Cabal and it conflicted with one of the above
requirements.)

PS: I'm a bit disappointed you seem to dismiss this proposal right away
>     categorically without giving us a chance to address your
>     concerns. The proposal is not a rigid all-or-nothing thing that
>     can't be tweaked and revised.  That's why we're having these
>     proposal-discussions in the first place (rather than doing blind
>     +1/-1 polls), so we can hear everyone out and try to maximise the
>     agreement (even if we will never reach 100% consensus on any
>     proposal).
>
>     So please, keep on discussing!
>

The problem by discussions is that they are done between two groups with
quite a difference in experience. On one hand you have people like Bryan,
who have considerable contributions to the Haskell ecosystem and much
experience in large scale software development (e.g. from Facebook). On the
other hand you have people who don't. That's okay. We've all been at the
latter group at some point of our career.

What's frustrating is that people don't take a step bad and realize that
they might be in the latter group and should perhaps listen to those in the
former. This doesn't happen, instead we get lots of "C++ and Java so bad
and we don't want to be like them." Haskell is not at risk of becoming C++
or Java (which are a large improvement compared to the languages came
before them). We're at risk of missing our window of opportunity. I think
that would be a shame, as I think Haskell is a step forward compared to
those languages and I would like to see more software that used be written
in Haskell.

We've been through this many times before on the libraries list. I'm not
going to win an argument on this mailing list. Between maintaining
libraries you all use and managing a largish team at Google, I don't have
much time for a discussion which approaches a hundred emails and is won by
virtue of having lots of time to write emails.

-- Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151006/1981f347/attachment-0001.html>

From ben at smart-cactus.org  Tue Oct  6 08:44:29 2015
From: ben at smart-cactus.org (Ben Gamari)
Date: Tue, 06 Oct 2015 10:44:29 +0200
Subject: Reducing the need for CPP (was: Monad of no `return` Proposal (MRP):
 Moving `return` out of `Monad`)
In-Reply-To: <CANBN=mv6WPLRdvLJppOZ2=1zkd7sWKAHwTF3rHie27RS_YLesA@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CANBN=mv6WPLRdvLJppOZ2=1zkd7sWKAHwTF3rHie27RS_YLesA@mail.gmail.com>
Message-ID: <87k2r0z8r6.fsf@smart-cactus.org>

Sven Panne <svenpanne at gmail.com> writes:

> 2015-10-05 17:09 GMT+02:00 Gershom B <gershomb at gmail.com>:
>
>> On October 5, 2015 at 10:59:35 AM, Bryan O'Sullivan (bos at serpentine.com)
>> wrote:
>> [...] As for libraries, it has been pointed out, I believe, that without
>> CPP one can write instances compatible with AMP, and also with AMP + MRP.
>> One can also write code, sans CPP, compatible with pre- and post- AMP. [...]
>>
>
> Nope, at least not if you care about -Wall: If you take e.g. (<$>) which is
> now part of the Prelude, you can't simply import some compatibility module,
> because GHC might tell you (rightfully) that that import is redundant,
> because (<$>) is already visible through the Prelude. So you'll have to use
> CPP to avoid that import on base >= 4.8, be it from it Data.Functor,
> Control.Applicative or some compat-* module. And you'll have to use CPP in
> each and every module using <$> then, unless I miss something obvious.
> AFAICT all transitioning guides ignore -Wall and friends...
>
This is a fair point that comes up fairly often. The fact that CPP is
required to silence redundant import warnings is quite unfortunate.
Others languages have better stories in this area. One example is Rust,
which has a quite flexible `#[allow(...)]` pragma which can be used to
acknowledge and silence a wide variety of warnings and lints [1].

I can think of a few ways (some better than others) how we might
introduce a similar idea for import redundancy checks in Haskell,

 1. Attach a `{-# ALLOW redundant_import #-}` pragma to a definition,
        
        -- in Control.Applicative
        {-# ALLOW redundant_import (<$>) #-}
        (<$>) :: (a -> b) -> f a -> f b
        (<$>) = fmap

    asking the compiler to pretend that any import of the symbol did not
    exist when looking for redundant imports. This would allow library
    authors to appropriately mark definitions when they are moved,
    saving downstream users from having to make any change whatsoever.

 2. Or alternatively we could make this a idea a bit more precise,
        
        -- in Control.Applicative
        {-# ALLOW redundant_import Prelude.(<$>) #-}
        (<$>) :: (a -> b) -> f a -> f b
        (<$>) = fmap

    Which would ignore imports of `Control.Applicative.(<$>)` only if
    `Prelude.(<$>)` were also in scope.

 3. Attach a `{-# ALLOW redundancy_import #-}` pragma to an import,

        import {-# ALLOW redundant_import #-} Control.Applicative

        -- or perhaps
        import Control.Applicative
        {-# ALLOW redundant_import Control.Applicative #-}

    allowing the user to explicitly state that they are aware that this
    import may be redundant.

 4. Attach a `{-# ALLOW redundancy_import #-}` pragma to a name in an
    import list,

        import Control.Applicative ((<$>) {-# ALLOW redundant_import #-})

    allowing the user to explicitly state that they are aware that this
    imported function may be redundant.

In general I'd like to reiterate that many of the comments in this
thread describe genuine sharp edges in our language which have presented
a real cost in developer time during the AMP and and FTP transitions. I
think it is worth thinking of ways to soften these edges; we may be
surprised how easy it is to fix some of them.

- Ben


[1] https://doc.rust-lang.org/stable/reference.html#lint-check-attributes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151006/42e097e1/attachment.sig>

From johan.tibell at gmail.com  Tue Oct  6 09:11:47 2015
From: johan.tibell at gmail.com (Johan Tibell)
Date: Tue, 6 Oct 2015 11:11:47 +0200
Subject: Reducing the need for CPP (was: Monad of no `return` Proposal
 (MRP): Moving `return` out of `Monad`)
In-Reply-To: <87k2r0z8r6.fsf@smart-cactus.org>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CANBN=mv6WPLRdvLJppOZ2=1zkd7sWKAHwTF3rHie27RS_YLesA@mail.gmail.com>
 <87k2r0z8r6.fsf@smart-cactus.org>
Message-ID: <CAK-tuPYhF3e2nPesPZKtDoo350sL8254WGvf0g5cdFu8QZtnww@mail.gmail.com>

It might be enough to just add a NOWARN <warning type> pragma that acts on
a single line/expression. I've seen it in both C++ and Python linters and
it works reasonably well and it's quite general.

On Tue, Oct 6, 2015 at 10:44 AM, Ben Gamari <ben at smart-cactus.org> wrote:

> Sven Panne <svenpanne at gmail.com> writes:
>
> > 2015-10-05 17:09 GMT+02:00 Gershom B <gershomb at gmail.com>:
> >
> >> On October 5, 2015 at 10:59:35 AM, Bryan O'Sullivan (bos at serpentine.com
> )
> >> wrote:
> >> [...] As for libraries, it has been pointed out, I believe, that without
> >> CPP one can write instances compatible with AMP, and also with AMP +
> MRP.
> >> One can also write code, sans CPP, compatible with pre- and post- AMP.
> [...]
> >>
> >
> > Nope, at least not if you care about -Wall: If you take e.g. (<$>) which
> is
> > now part of the Prelude, you can't simply import some compatibility
> module,
> > because GHC might tell you (rightfully) that that import is redundant,
> > because (<$>) is already visible through the Prelude. So you'll have to
> use
> > CPP to avoid that import on base >= 4.8, be it from it Data.Functor,
> > Control.Applicative or some compat-* module. And you'll have to use CPP
> in
> > each and every module using <$> then, unless I miss something obvious.
> > AFAICT all transitioning guides ignore -Wall and friends...
> >
> This is a fair point that comes up fairly often. The fact that CPP is
> required to silence redundant import warnings is quite unfortunate.
> Others languages have better stories in this area. One example is Rust,
> which has a quite flexible `#[allow(...)]` pragma which can be used to
> acknowledge and silence a wide variety of warnings and lints [1].
>
> I can think of a few ways (some better than others) how we might
> introduce a similar idea for import redundancy checks in Haskell,
>
>  1. Attach a `{-# ALLOW redundant_import #-}` pragma to a definition,
>
>         -- in Control.Applicative
>         {-# ALLOW redundant_import (<$>) #-}
>         (<$>) :: (a -> b) -> f a -> f b
>         (<$>) = fmap
>
>     asking the compiler to pretend that any import of the symbol did not
>     exist when looking for redundant imports. This would allow library
>     authors to appropriately mark definitions when they are moved,
>     saving downstream users from having to make any change whatsoever.
>
>  2. Or alternatively we could make this a idea a bit more precise,
>
>         -- in Control.Applicative
>         {-# ALLOW redundant_import Prelude.(<$>) #-}
>         (<$>) :: (a -> b) -> f a -> f b
>         (<$>) = fmap
>
>     Which would ignore imports of `Control.Applicative.(<$>)` only if
>     `Prelude.(<$>)` were also in scope.
>
>  3. Attach a `{-# ALLOW redundancy_import #-}` pragma to an import,
>
>         import {-# ALLOW redundant_import #-} Control.Applicative
>
>         -- or perhaps
>         import Control.Applicative
>         {-# ALLOW redundant_import Control.Applicative #-}
>
>     allowing the user to explicitly state that they are aware that this
>     import may be redundant.
>
>  4. Attach a `{-# ALLOW redundancy_import #-}` pragma to a name in an
>     import list,
>
>         import Control.Applicative ((<$>) {-# ALLOW redundant_import #-})
>
>     allowing the user to explicitly state that they are aware that this
>     imported function may be redundant.
>
> In general I'd like to reiterate that many of the comments in this
> thread describe genuine sharp edges in our language which have presented
> a real cost in developer time during the AMP and and FTP transitions. I
> think it is worth thinking of ways to soften these edges; we may be
> surprised how easy it is to fix some of them.
>
> - Ben
>
>
> [1] https://doc.rust-lang.org/stable/reference.html#lint-check-attributes
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151006/5d878455/attachment.html>

From _deepfire at feelingofgreen.ru  Tue Oct  6 09:30:12 2015
From: _deepfire at feelingofgreen.ru (Kosyrev Serge)
Date: Tue, 06 Oct 2015 12:30:12 +0300
Subject: [Haskell-cafe] Reducing the need for CPP
In-Reply-To: <87k2r0z8r6.fsf@smart-cactus.org>
 (sfid-20151006_130812_301207_6B09ABEE) (Ben Gamari's message of "Tue,
 06 Oct 2015 10:44:29 +0200")
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CANBN=mv6WPLRdvLJppOZ2=1zkd7sWKAHwTF3rHie27RS_YLesA@mail.gmail.com>
 <87k2r0z8r6.fsf@smart-cactus.org>
Message-ID: <87h9m4l4yj.fsf@feelingofgreen.ru>

Ben Gamari <ben at smart-cactus.org> writes:
> This is a fair point that comes up fairly often. The fact that CPP is
> required to silence redundant import warnings is quite unfortunate.
> Others languages have better stories in this area. One example is Rust,
> which has a quite flexible `#[allow(...)]` pragma which can be used to
> acknowledge and silence a wide variety of warnings and lints [1].
>
> I can think of a few ways (some better than others) how we might
> introduce a similar idea for import redundancy checks in Haskell,
>
>  1. Attach a `{-# ALLOW redundant_import #-}` pragma to a definition,
...
>  2. Or alternatively we could make this a idea a bit more precise,
>         {-# ALLOW redundant_import Prelude.(<$>) #-}
...
>  3. Attach a `{-# ALLOW redundancy_import #-}` pragma to an import,
>         import {-# ALLOW redundant_import #-} Control.Applicative
...
>  4. Attach a `{-# ALLOW redundancy_import #-}` pragma to a name in an
>     import list,
>         import Control.Applicative ((<$>) {-# ALLOW redundant_import #-})

What I don't like about this solution is how specific it is -- the gut
instinct that it can't be the last such extension, if we were to start
replacing CPP piecemeal.

And after a while, we'd accomodate a number of such extensions..
and they would keep coming.. until it converges to a trainwreck.

I think that what instead needs to be done, is this:

  1. a concerted effort to summarize *all* uses of CPP in Haskell code
  2. a bit of forward thinking, to include desirables that would be easy
     to get with a more generic solution

Personally, I think that any such effort, approached with generality
that would be truly satisfying, should inevitably converge to an
AST-level mechanism.

..but then I remember how CPP can be used to paper over incompatible
syntax changes..

Hmm..

-- 
? ???????e? / respectfully,
??????? ??????

From Henrik.Nilsson at nottingham.ac.uk  Tue Oct  6 11:32:31 2015
From: Henrik.Nilsson at nottingham.ac.uk (Henrik Nilsson)
Date: Tue, 06 Oct 2015 12:32:31 +0100
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
Message-ID: <5613B14F.9070107@nottingham.ac.uk>

Dear all,

Executive Summary: Please let us defer further discussion
and ultimate decision on MRP to the resurrected HaskellPrime
committee

While we can discuss the extent of additional breakage
MRP would cause, the fact remains it is a further
breaking change. A survey of breakage to books as
Herbert did is certainly valuable  (thanks!), but
much breakage will (effectively) remain unquantifiable.

It is also clear from the discussions over the last
couple of weeks, on the Haskell libraries list as well
as various other forums and social media, that MRP is
highly contentions.

This begs two questions:

   1. Is the Haskell Libraries list and informal voting process
      really an appropriate, or even acceptable, way to adopt
      such far-reaching changes to what effectively amounts to
      Haskell itself?

   2. Why the hurry to push MRP through?

As to question 1, to Graham Hutton's and my knowledge,
the libraries list and its voting process was originally
set up for 3rd-party libraries in fptools. It seems to
have experienced some form of "mission creep" since.
Maybe that is understandable given that there was no
obvious alternative as HaskellPrime has been defunct
for a fair few years. But, as has been pointed out in a
number of postings, a lot of people with very valuable
perspectives are also very busy, and thus likely to
miss a short discussion period (as has happened in the
past in relation to the Burning the Bridges proposal)
and also have very little time for engaging in long and
complicated e-mail discussions that, from their
perspective, happen at a completely random point in
time and for which they thus have not had a chance to
set aside time even if they wanted to participate.

Just as one data point, AMP etc. mostly passed Graham
and me by simply because a) we were too busy to notice
and b) we simply didn't think there was a mandate for
such massive overhauls outside of a process like
HaskellPrime. And we are demonstrably not alone.

This brings us to question 2. Now that HaskellPrime is
being resurrected, why the hurry to push MRP through?
Surely HaskellPrime is the forum where breaking
changes like MRP should be discussed, allowing as much
time as is necessary and allowing for an as wide range
of perspectives as possible to properly be taken into
account?

The need to "field test" MRP prior to discussing
it in HaskellPrime has been mentioned. Graham and I
are very sceptical. In the past, at least in the
past leading up to Haskell 2010 or so, the community
at large was not roped in as involuntary field testers.

If MRP is pushed through now, with a resurrection of
HaskellPrime being imminent, Graham and I strongly believe
that risks coming across to a very large part of the
Haskell community as preempting proper process by facing
the new HaskellPrime committee with (yet another) fait
accompli.

Therefore, please let us defer further discussion and
ultimate decision on MRP to the resurrected
HaskellPrime committee, which is where it properly
belongs. Otherwise, the Haskell community itself might
be one of the things that MRP breaks.

Best regards,

/Henrik

-- 
Henrik Nilsson
School of Computer Science
The University of Nottingham
nhn at cs.nott.ac.uk




This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it. 

Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.


From hvr at gnu.org  Tue Oct  6 07:10:12 2015
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Tue, 06 Oct 2015 09:10:12 +0200
Subject: MRP, 3-year-support-window,
 and the non-requirement of CPP (was: [Haskell-cafe] Monad of no
 `return` Proposal (MRP): Moving `return` out of `Monad`)
In-Reply-To: <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 (Johan Tibell's message of "Mon, 5 Oct 2015 21:01:16 +0200")
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
Message-ID: <87zizw8obv.fsf_-_@gnu.org>

On 2015-10-05 at 21:01:16 +0200, Johan Tibell wrote:
> On Mon, Oct 5, 2015 at 8:34 PM, Gregory Collins <greg at gregorycollins.net>
[...]

>> Strongly -1 from me also. My experience over the last couple of years is
>> that every GHC release breaks my libraries in annoying ways that require
>> CPP to fix:
>>
>> ~/personal/src/snap ?  find . -name '*.hs' | xargs egrep
>> '#if.*(MIN_VERSION)|(GLASGOW_HASKELL)' | wc -l
>> 64

[...]

> On the libraries I maintain and have a copy of on my computer right now: 329


Although this was already pointed out to you in a response to a Tweet of
yours, I'd like to expand on this here to clarify:


You say that you stick to the 3-major-ghc-release support-window
convention for your libraries. This is good, because then you don't need
any CPP at all! Here's why:

So when GHC 8.2 is released, your support-window requires you to support
GHC 7.10 and GHC 8.0 in addition to GHC 8.2.

At this point you'll be happy that you can start dropping those #ifdefs
you added for GHC 7.10 in your code in order to adapt to FTP & AMP.

And when you do *that*, you can also drop all your `return = pure`
methods overrides. (Because we prepared for MRP already in GHC 7.10 by
introducing the default implementation for `return`!)

This way, you don't need to introduce any CPP whatsoever due to MRP!


Finally, since we're not gonna remove `return` in GHC 8.2 anyway, as GHC
8.2 was just the *earliest theoretical* possible GHC in which this
*could* have happened. Realistically, this would happen at a much later
point, say GHC 8.6 or even later! Therefore, the scheme above would
actually work for 5-year time-windows! And there's even an idea on the
table to have a lawful `return = pure` method override be tolerated by
GHC even when `return` has already moved out of `Monad`!


PS: I'm a bit disappointed you seem to dismiss this proposal right away
    categorically without giving us a chance to address your
    concerns. The proposal is not a rigid all-or-nothing thing that
    can't be tweaked and revised.  That's why we're having these
    proposal-discussions in the first place (rather than doing blind
    +1/-1 polls), so we can hear everyone out and try to maximise the
    agreement (even if we will never reach 100% consensus on any
    proposal).

    So please, keep on discussing!

From Lennart.Augustsson at sc.com  Tue Oct  6 11:57:23 2015
From: Lennart.Augustsson at sc.com (Augustsson, Lennart)
Date: Tue, 6 Oct 2015 11:57:23 +0000
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <5613B14F.9070107@nottingham.ac.uk>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <5613B14F.9070107@nottingham.ac.uk>
Message-ID: <22B950C955F8AB4196E72698FBD00002D0290B59@UKWPISXMB01D.zone1.scb.net>

To question 1 my answer is NO!  I think voting to decide these kind of issues a terrible idea; we might as well throw dice.

-----Original Message-----
From: Haskell-Cafe [mailto:haskell-cafe-bounces at haskell.org] On Behalf Of Henrik Nilsson
Sent: 06 October 2015 12:33
To: haskell-prime at haskell.org List; Haskell Libraries; haskell cafe
Subject: Re: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

Dear all,

Executive Summary: Please let us defer further discussion and ultimate decision on MRP to the resurrected HaskellPrime committee

While we can discuss the extent of additional breakage MRP would cause, the fact remains it is a further breaking change. A survey of breakage to books as Herbert did is certainly valuable  (thanks!), but much breakage will (effectively) remain unquantifiable.

It is also clear from the discussions over the last couple of weeks, on the Haskell libraries list as well as various other forums and social media, that MRP is highly contentions.

This begs two questions:

   1. Is the Haskell Libraries list and informal voting process
      really an appropriate, or even acceptable, way to adopt
      such far-reaching changes to what effectively amounts to
      Haskell itself?

   2. Why the hurry to push MRP through?

As to question 1, to Graham Hutton's and my knowledge, the libraries list and its voting process was originally set up for 3rd-party libraries in fptools. It seems to have experienced some form of "mission creep" since.
Maybe that is understandable given that there was no obvious alternative as HaskellPrime has been defunct for a fair few years. But, as has been pointed out in a number of postings, a lot of people with very valuable perspectives are also very busy, and thus likely to miss a short discussion period (as has happened in the past in relation to the Burning the Bridges proposal) and also have very little time for engaging in long and complicated e-mail discussions that, from their perspective, happen at a completely random point in time and for which they thus have not had a chance to set aside time even if they wanted to participate.

Just as one data point, AMP etc. mostly passed Graham and me by simply because a) we were too busy to notice and b) we simply didn't think there was a mandate for such massive overhauls outside of a process like HaskellPrime. And we are demonstrably not alone.

This brings us to question 2. Now that HaskellPrime is being resurrected, why the hurry to push MRP through?
Surely HaskellPrime is the forum where breaking changes like MRP should be discussed, allowing as much time as is necessary and allowing for an as wide range of perspectives as possible to properly be taken into account?

The need to "field test" MRP prior to discussing it in HaskellPrime has been mentioned. Graham and I are very sceptical. In the past, at least in the past leading up to Haskell 2010 or so, the community at large was not roped in as involuntary field testers.

If MRP is pushed through now, with a resurrection of HaskellPrime being imminent, Graham and I strongly believe that risks coming across to a very large part of the Haskell community as preempting proper process by facing the new HaskellPrime committee with (yet another) fait accompli.

Therefore, please let us defer further discussion and ultimate decision on MRP to the resurrected HaskellPrime committee, which is where it properly belongs. Otherwise, the Haskell community itself might be one of the things that MRP breaks.

Best regards,

/Henrik

--
Henrik Nilsson
School of Computer Science
The University of Nottingham
nhn at cs.nott.ac.uk




This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it. 

Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe at haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at http://www.standardchartered.com/en/incorporation-details.html

Insofar as this communication contains any market commentary, the market commentary has been prepared by sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied for any other purpose, and is subject to the relevant disclaimers available at http://wholesalebanking.standardchartered.com/en/utility/Pages/d-mkt.aspx

Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign on the term sheet to acknowledge in respect of the same.

Please visit http://wholesalebanking.standardchartered.com/en/capabilities/financialmarkets/Pages/doddfrankdisclosures.aspx for important information with respect to derivative products.

From hesselink at gmail.com  Tue Oct  6 12:06:11 2015
From: hesselink at gmail.com (Erik Hesselink)
Date: Tue, 6 Oct 2015 14:06:11 +0200
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <5613B14F.9070107@nottingham.ac.uk>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <5613B14F.9070107@nottingham.ac.uk>
Message-ID: <CAPeieQFHywiaQ60OEB1xf=RHGVu+46xi30iXTmXTeGSxmAp2fw@mail.gmail.com>

I was always under the impression that +1/-1 was just a quick
indicator of opinion, not a vote, and that it was the core libraries
committee that would make the final call if enough consensus was
reached to enact the change.

Erik

On 6 October 2015 at 13:32, Henrik Nilsson
<Henrik.Nilsson at nottingham.ac.uk> wrote:
> Dear all,
>
> Executive Summary: Please let us defer further discussion
> and ultimate decision on MRP to the resurrected HaskellPrime
> committee
>
> While we can discuss the extent of additional breakage
> MRP would cause, the fact remains it is a further
> breaking change. A survey of breakage to books as
> Herbert did is certainly valuable  (thanks!), but
> much breakage will (effectively) remain unquantifiable.
>
> It is also clear from the discussions over the last
> couple of weeks, on the Haskell libraries list as well
> as various other forums and social media, that MRP is
> highly contentions.
>
> This begs two questions:
>
>   1. Is the Haskell Libraries list and informal voting process
>      really an appropriate, or even acceptable, way to adopt
>      such far-reaching changes to what effectively amounts to
>      Haskell itself?
>
>   2. Why the hurry to push MRP through?
>
> As to question 1, to Graham Hutton's and my knowledge,
> the libraries list and its voting process was originally
> set up for 3rd-party libraries in fptools. It seems to
> have experienced some form of "mission creep" since.
> Maybe that is understandable given that there was no
> obvious alternative as HaskellPrime has been defunct
> for a fair few years. But, as has been pointed out in a
> number of postings, a lot of people with very valuable
> perspectives are also very busy, and thus likely to
> miss a short discussion period (as has happened in the
> past in relation to the Burning the Bridges proposal)
> and also have very little time for engaging in long and
> complicated e-mail discussions that, from their
> perspective, happen at a completely random point in
> time and for which they thus have not had a chance to
> set aside time even if they wanted to participate.
>
> Just as one data point, AMP etc. mostly passed Graham
> and me by simply because a) we were too busy to notice
> and b) we simply didn't think there was a mandate for
> such massive overhauls outside of a process like
> HaskellPrime. And we are demonstrably not alone.
>
> This brings us to question 2. Now that HaskellPrime is
> being resurrected, why the hurry to push MRP through?
> Surely HaskellPrime is the forum where breaking
> changes like MRP should be discussed, allowing as much
> time as is necessary and allowing for an as wide range
> of perspectives as possible to properly be taken into
> account?
>
> The need to "field test" MRP prior to discussing
> it in HaskellPrime has been mentioned. Graham and I
> are very sceptical. In the past, at least in the
> past leading up to Haskell 2010 or so, the community
> at large was not roped in as involuntary field testers.
>
> If MRP is pushed through now, with a resurrection of
> HaskellPrime being imminent, Graham and I strongly believe
> that risks coming across to a very large part of the
> Haskell community as preempting proper process by facing
> the new HaskellPrime committee with (yet another) fait
> accompli.
>
> Therefore, please let us defer further discussion and
> ultimate decision on MRP to the resurrected
> HaskellPrime committee, which is where it properly
> belongs. Otherwise, the Haskell community itself might
> be one of the things that MRP breaks.
>
> Best regards,
>
> /Henrik
>
> --
> Henrik Nilsson
> School of Computer Science
> The University of Nottingham
> nhn at cs.nott.ac.uk
>
>
>
>
> This message and any attachment are intended solely for the addressee
> and may contain confidential information. If you have received this
> message in error, please send it back to me, and immediately delete it.
> Please do not use, copy or disclose the information contained in this
> message or in any attachment.  Any views or opinions expressed by the
> author of this email do not necessarily reflect the views of the
> University of Nottingham.
>
> This message has been checked for viruses but the contents of an
> attachment may still contain software viruses which could damage your
> computer system, you are advised to perform your own checks. Email
> communications with the University of Nottingham may be monitored as
> permitted by UK legislation.
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

From jmaessen at alum.mit.edu  Tue Oct  6 12:25:34 2015
From: jmaessen at alum.mit.edu (Jan-Willem Maessen)
Date: Tue, 6 Oct 2015 08:25:34 -0400
Subject: Reducing the need for CPP (was: Monad of no `return` Proposal
 (MRP): Moving `return` out of `Monad`)
In-Reply-To: <87k2r0z8r6.fsf@smart-cactus.org>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CANBN=mv6WPLRdvLJppOZ2=1zkd7sWKAHwTF3rHie27RS_YLesA@mail.gmail.com>
 <87k2r0z8r6.fsf@smart-cactus.org>
Message-ID: <CANs0n6x+HHHdVdS1g16V0Fwa=jtN2_EFtC2YfHvN7pF4PoYPEg@mail.gmail.com>

On Tue, Oct 6, 2015 at 4:44 AM, Ben Gamari <ben at smart-cactus.org> wrote:

> Sven Panne <svenpanne at gmail.com> writes:
>
> > 2015-10-05 17:09 GMT+02:00 Gershom B <gershomb at gmail.com>:
> >
> >> On October 5, 2015 at 10:59:35 AM, Bryan O'Sullivan (bos at serpentine.com
> )
> >> wrote:
> >> [...] As for libraries, it has been pointed out, I believe, that without
> >> CPP one can write instances compatible with AMP, and also with AMP +
> MRP.
> >> One can also write code, sans CPP, compatible with pre- and post- AMP.
> [...]
> >>
> >
> > Nope, at least not if you care about -Wall: If you take e.g. (<$>) which
> is
> > now part of the Prelude, you can't simply import some compatibility
> module,
> > because GHC might tell you (rightfully) that that import is redundant,
> > because (<$>) is already visible through the Prelude. So you'll have to
> use
> > CPP to avoid that import on base >= 4.8, be it from it Data.Functor,
> > Control.Applicative or some compat-* module. And you'll have to use CPP
> in
> > each and every module using <$> then, unless I miss something obvious.
> > AFAICT all transitioning guides ignore -Wall and friends...
> >
> This is a fair point that comes up fairly often. The fact that CPP is
> required to silence redundant import warnings is quite unfortunate.
> Others languages have better stories in this area. One example is Rust,
> which has a quite flexible `#[allow(...)]` pragma which can be used to
> acknowledge and silence a wide variety of warnings and lints [1].
>
> I can think of a few ways (some better than others) how we might
> introduce a similar idea for import redundancy checks in Haskell,
>
>  1. Attach a `{-# ALLOW redundant_import #-}` pragma to a definition,
>
>         -- in Control.Applicative
>         {-# ALLOW redundant_import (<$>) #-}
>         (<$>) :: (a -> b) -> f a -> f b
>         (<$>) = fmap
>
>     asking the compiler to pretend that any import of the symbol did not
>     exist when looking for redundant imports. This would allow library
>     authors to appropriately mark definitions when they are moved,
>     saving downstream users from having to make any change whatsoever.
>
>  2. Or alternatively we could make this a idea a bit more precise,
>
>         -- in Control.Applicative
>         {-# ALLOW redundant_import Prelude.(<$>) #-}
>         (<$>) :: (a -> b) -> f a -> f b
>         (<$>) = fmap
>
>     Which would ignore imports of `Control.Applicative.(<$>)` only if
>     `Prelude.(<$>)` were also in scope.
>

One obvious solution I haven't seen mentioned is the ability to add
nonexistent identifier to a hiding clause (these identifiers might
presumably exist in some other version of the import):

import Prelude hiding ((<$>))

I can see the argument for marking such imports with a pragma, though it
gets a bit ugly.

-Jan-Willem Maessen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151006/c4319a11/attachment.html>

From hvr at gnu.org  Tue Oct  6 13:00:41 2015
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Tue, 06 Oct 2015 15:00:41 +0200
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <CAPeieQFHywiaQ60OEB1xf=RHGVu+46xi30iXTmXTeGSxmAp2fw@mail.gmail.com>
 (Erik Hesselink's message of "Tue, 6 Oct 2015 14:06:11 +0200")
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <5613B14F.9070107@nottingham.ac.uk>
 <CAPeieQFHywiaQ60OEB1xf=RHGVu+46xi30iXTmXTeGSxmAp2fw@mail.gmail.com>
Message-ID: <87si5o6tja.fsf@gnu.org>

On 2015-10-06 at 14:06:11 +0200, Erik Hesselink wrote:
> I was always under the impression that +1/-1 was just a quick
> indicator of opinion, not a vote, and that it was the core libraries
> committee that would make the final call if enough consensus was
> reached to enact the change.

I'd like to point out, that the core libraries committee ought to
continue to do so (as hinted at in [1]) in its function as a Haskell
Prime sub-Committee (c.f. sub-teams in the Rust community[2]).

While there will be surely overlap of interests, contributions,
cross-reviewing and discussion, the principal task and responsibility of
the new sought members is to concentrate on the language part of the
Haskell Report where quite a bit of work is awaiting them.

Cheers,
  hvr

 [1]: https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html
 [2]: https://www.rust-lang.org/team.html

From spam at scientician.net  Tue Oct  6 13:16:36 2015
From: spam at scientician.net (Bardur Arantsson)
Date: Tue, 6 Oct 2015 15:16:36 +0200
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <CAPeieQFHywiaQ60OEB1xf=RHGVu+46xi30iXTmXTeGSxmAp2fw@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <5613B14F.9070107@nottingham.ac.uk>
 <CAPeieQFHywiaQ60OEB1xf=RHGVu+46xi30iXTmXTeGSxmAp2fw@mail.gmail.com>
Message-ID: <mv0hjk$eem$1@ger.gmane.org>

On 10/06/2015 02:06 PM, Erik Hesselink wrote:
> I was always under the impression that +1/-1 was just a quick
> indicator of opinion, not a vote, and that it was the core libraries
> committee that would make the final call if enough consensus was
> reached to enact the change.
> 

Ditto.

(At the very least for simple +1/-1 posts rather than posts that spell
out any particular pros/cons/etc.)

Regards,



From spam at scientician.net  Tue Oct  6 16:15:39 2015
From: spam at scientician.net (Bardur Arantsson)
Date: Tue, 6 Oct 2015 18:15:39 +0200
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <5613B14F.9070107@nottingham.ac.uk>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <5613B14F.9070107@nottingham.ac.uk>
Message-ID: <mv0s3b$c2a$1@ger.gmane.org>

On 10/06/2015 01:32 PM, Henrik Nilsson wrote:
> Dear all,
> 
[--snip--]
> 
> While we can discuss the extent of additional breakage
> MRP would cause, the fact remains it is a further
> breaking change. A survey of breakage to books as
> Herbert did is certainly valuable  (thanks!), but
> much breakage will (effectively) remain unquantifiable.
> 

This is an argument from FUD. If it's unquantifiable then it can (almost
by definition) neither count for nor against, can it?

> It is also clear from the discussions over the last
> couple of weeks, on the Haskell libraries list as well
> as various other forums and social media, that MRP is
> highly contentions.

Indeed.

> 
> This begs two questions:
> 
>   1. Is the Haskell Libraries list and informal voting process
>      really an appropriate, or even acceptable, way to adopt
>      such far-reaching changes to what effectively amounts to
>      Haskell itself?

I don't think that was ever the idea. (See other the other post by Erik.)

> 
>   2. Why the hurry to push MRP through?
> 

Personally, I don't think there's much need to push the actual
*breaking* change through, but I *do* think that deprecation warnings
should go in as quickly as possible.

[--snip--]
> 
> This brings us to question 2. Now that HaskellPrime is
> being resurrected, why the hurry to push MRP through?
> Surely HaskellPrime is the forum where breaking
> changes like MRP should be discussed, allowing as much
> time as is necessary and allowing for an as wide range
> of perspectives as possible to properly be taken into
> account?

Isn't that what we're trying to do on this very thread?

> 
> The need to "field test" MRP prior to discussing
> it in HaskellPrime has been mentioned. Graham and I
> are very sceptical. In the past, at least in the
> past leading up to Haskell 2010 or so, the community
> at large was not roped in as involuntary field testers.
> 

It seems to me that the community *is* being involved rather than being,
as you say, "involuntary field testers". (Again: see the very existence
of this thread).

Perhaps we should also be discussing what, exactly, is meant by
"community". It seems people have different ideas about that.

(For myself, I would certainly presume that being a member of the
community would include following along on at least a few mailing lists
or reddit or *somewhere* where all things Haskell get discussed.)

> If MRP is pushed through now, with a resurrection of
> HaskellPrime being imminent, Graham and I strongly believe
> that risks coming across to a very large part of the
> Haskell community as preempting proper process by facing
> the new HaskellPrime committee with (yet another) fait
> accompli.
> 
> Therefore, please let us defer further discussion and
> ultimate decision on MRP to the resurrected
> HaskellPrime committee, which is where it properly
> belongs. Otherwise, the Haskell community itself might
> be one of the things that MRP breaks.
> 

As I've certainly mentioned in this thread, the previous committee
didn't actually accomplish very much [1]. I also note that much of what
they *did* get through was actually mostly already field-tested in GHC
beforehand. (So there goes that argument, I guess.)

Regards,

[1] Though what they did accomplish is very much appreciated. Here's the
list linked from the Wiki page:
https://prime.haskell.org/query?state=accepted&milestone=Haskell+2010&order=priority


From spam at scientician.net  Tue Oct  6 16:16:52 2015
From: spam at scientician.net (Bardur Arantsson)
Date: Tue, 6 Oct 2015 18:16:52 +0200
Subject: Reducing the need for CPP
In-Reply-To: <CAK-tuPYhF3e2nPesPZKtDoo350sL8254WGvf0g5cdFu8QZtnww@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CANBN=mv6WPLRdvLJppOZ2=1zkd7sWKAHwTF3rHie27RS_YLesA@mail.gmail.com>
 <87k2r0z8r6.fsf@smart-cactus.org>
 <CAK-tuPYhF3e2nPesPZKtDoo350sL8254WGvf0g5cdFu8QZtnww@mail.gmail.com>
Message-ID: <mv0s5k$c2a$2@ger.gmane.org>

On 10/06/2015 11:11 AM, Johan Tibell wrote:
> It might be enough to just add a NOWARN <warning type> pragma that acts on
> a single line/expression. I've seen it in both C++ and Python linters and
> it works reasonably well and it's quite general.

+1. Simple is good and can hopefully also be backported to older GHC
releases. (Provided someone's willing to do said releases, obviously.)



From hvr at gnu.org  Tue Oct  6 16:47:08 2015
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Tue, 06 Oct 2015 18:47:08 +0200
Subject: MRP, 3-year-support-window, and the non-requirement of CPP
In-Reply-To: <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 (Johan Tibell's message of "Tue, 6 Oct 2015 10:10:01 +0200")
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
Message-ID: <87612k6j1v.fsf@gnu.org>

On 2015-10-06 at 10:10:01 +0200, Johan Tibell wrote:
[...]
>> You say that you stick to the 3-major-ghc-release support-window
>> convention for your libraries. This is good, because then you don't need
>> any CPP at all! Here's why:
>>
>> [...]
>>
>
> So what do I have to write today to have my Monad instances be:
>
>  * Warning free - Warnings are useful. Turning them off or having spurious
> warnings both contribute to bugs.

Depends on the warnings. Some warnings are more of an advisory kind
(hlint-ish). I wouldn't consider redundant imports a source of
bugs. Leaving off a top-level signature shouldn't be a source of
correctness bugs either. Also, warnings about upcoming changes
(i.e. deprecation warnings) also are not necessarily a bug, but rather a
way to raise awareness of API changes.

At the other end of the spectrum are more serious warnings I'd almost
consider errors, such as failing to define a non-defaulting method or
violating a MINIMAL pragma specification, as that can lead to bottoms
either in the form of runtime errors or even worse, hanging computations
(in case of cyclic definitions).

IMO, GHC should classify its warnings into severities/categories or
introduce some compromise between -Wall and not-Wall.

>  * Use imports that either are qualified or have explicit import lists -
> Unqualified imports makes code more likely to break when dependencies add
> exports.
>  * Don't use CPP.

That being said, as how to write your Monad instances today with GHC
7.10 w/o CPP, while supporting at least GHC 7.4/7.6/7.8/7.10: This
*does* work (admittedly for an easy example, but this can be
generalised):


--8<---------------cut here---------------start------------->8---
module MyMaybe where

import Control.Applicative (Applicative(..))
import Prelude (Functor(..), Monad(..), (.))
-- or alternatively: `import qualified Prelude as P`

data Maybe' a = Nothing' | Just' a

instance Functor Maybe' where
    fmap f (Just' v) = Just' (f v)
    fmap _ Nothing'  = Nothing'

instance Applicative Maybe' where
    pure = Just'
    f1 <*> f2   = f1 >>= \v1 -> f2 >>= (pure . v1)

instance Monad Maybe' where
    Nothing' >>= _  = Nothing'
    Just' x  >>= f  = f x

    return = pure -- "deprecated" since GHC 7.10

--8<---------------cut here---------------end--------------->8---

This example above compiles -Wall-clean and satisfies all your 3 stated
requirements afaics. I do admit this probably not what you had in mind.

But to be consistent, if you want to avoid unqualified imports at all
costs in order to have full control of what gets imported into your
namespace, you shouldn't tolerate an implicit unqualified wildcard
`Prelude` import either. As `Prelude` can, even if seldom, gain new
exports as well (or even loose them -- `interact` *could* be a candidate
for removal at some point).


> Neither AMP or MRP includes a recipe for this in their proposal.

That's because -Wall-hygiene (w/o opting out of harmless) warnings
across multiple GHC versions is not considered a show-stopper.

In the specific case of MRP, I can offer you a Wall-perfect transition
scheme by either using `ghc-options: -fno-mrp-warnings` in your
cabal-file, or if that doesn't satisfy you, we can delay phase1
(i.e. redundant return-def warnings) to GHC 8.2:

Now you can continue to write `return = pure` w/o GHC warning bothering
you until GHC 8.2, at which point the 3-year-window will reach to GHC
7.10.

Then starting with GHC 8.2 you can drop the `return` definition, and
keep your 


More generally though, we need more language-features and/or
modifications to the way GHC triggers warnings to make such
refactorings/changes to the libraries -Wall-perfect as well.

Beyond what Ben already suggested in another post, there was also the
more general suggestion to implicitly suppress warnings when you
explicitly name an import. E.g.

  import Control.Applicative (Applicative(..))
 
would suppress the redundant-import warning for Applicative via Prelude,
because we specifically requested Applicative, so we don't mind that
Prelude re-exports the same symbol.


> AMP got one post-facto on the Wiki. It turns out that the workaround
> there didn't work (we tried it in Cabal and it conflicted with one of
> the above requirements.)

Yes, that unqualified `import Prelude`-last trick mentioned on the Wiki
breaks down for more complex imports with (redundant) explicit import
lists.

However, the Maybe-example above works at the cost of a wordy
Prelude-import, but it's more robust, as you pin down exactly which
symbol you expect to get from each module.



> The problem by discussions is that they are done between two groups with
> quite a difference in experience. On one hand you have people like Bryan,
> who have considerable contributions to the Haskell ecosystem and much
> experience in large scale software development (e.g. from Facebook). On the
> other hand you have people who don't. That's okay. We've all been at the
> latter group at some point of our career.
[...]

At the risk of stating the obvious: I don't think it matters from which
group a given argument comes from as its validity doesn't depend on the
messenger. Neither does it matter whether an argument is repeated
several times or stated only once. Also, every argument deserves to be
considered regardless of its origin or frequency.


-- hvr

From hvr at gnu.org  Tue Oct  6 17:26:06 2015
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Tue, 06 Oct 2015 19:26:06 +0200
Subject: MRP, 3-year-support-window, and the non-requirement of CPP
In-Reply-To: <87612k6j1v.fsf@gnu.org> (Herbert Valerio Riedel's message of
 "Tue, 06 Oct 2015 18:47:08 +0200")
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 <87612k6j1v.fsf@gnu.org>
Message-ID: <87oagb6h8x.fsf@gnu.org>


I hit "send" too early, so here's the incomplete section completed:

On 2015-10-06 at 18:47:08 +0200, Herbert Valerio Riedel wrote:

[...]

> In the specific case of MRP, I can offer you a Wall-perfect transition
> scheme by either using `ghc-options: -fno-mrp-warnings` in your
> cabal-file, or if that doesn't satisfy you, we can delay phase1
> (i.e. redundant return-def warnings) to GHC 8.2:
>
> Now you can continue to write `return = pure` w/o GHC warning bothering
> you until GHC 8.2, at which point the 3-year-window will reach to GHC
> 7.10.
>
> Then starting with GHC 8.2 you can drop the `return` definition, and

...keep supporting a 3-year-window back till GHC 7.10 (which
incorporates AMP and doesn't need `return` explicitly defined anymore)
without CPP.

And since you don't define `return` anymore, you don't get hit by the
MRP warning either, which would start with GHC 8.2.

GHC can keep providing as long as we want it to, and consider `return`
being an extra method of `Monad` simply a GHC-ism.

Future Haskell books and learning materials will hopefully be based on
the next Haskell Report incorporating the AMP and stop referring to the
historical `return` accident (which I consider badly named anyway from a
pedagogically perspective).

Code written unaware of `return` being a method of Monad will work
anyway just fine.

Do you see any problems with this scheme?


From Henrik.Nilsson at nottingham.ac.uk  Tue Oct  6 17:33:37 2015
From: Henrik.Nilsson at nottingham.ac.uk (Henrik Nilsson)
Date: Tue, 06 Oct 2015 18:33:37 +0100
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <mv0s3b$c2a$1@ger.gmane.org>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <5613B14F.9070107@nottingham.ac.uk> <mv0s3b$c2a$1@ger.gmane.org>
Message-ID: <561405F1.80805@nottingham.ac.uk>

Hi,

Bardur Arantsson wrote:

 > This is an argument from FUD. If it's unquantifiable then it can
 > (almost by definition) neither count for nor against, can it?

Of course 25 years+ of legacy is there. Quantifiable or not.
And of course it must count if we wish Haskell to be taken
seriously and be increasingly successful. That is at least
the view of a significant part of the Haskell community.
And the way to account for it, both that which is quantifiable
and that which is not, is to make sure that fundamental
language changes are given due consideration in a forum
where all stakeholders are adequately represented.

 > Personally, I don't think there's much need to push the actual
 > *breaking* change through, but I *do* think that deprecation warnings
 > should go in as quickly as possible.

What would the point of that be unless MRP eventually will go through?
I am afraid it comes across as an attempt to preempt proper process.

I'm somewhat baffled, to say the least.

 > It seems to me that the community *is* being involved rather than
 > being, as you say, "involuntary field testers".

Well, there are many prominent people who I have not seen posting
here. There are others who only found out via facebook postings
and the like, alerted by people who like me feel this is not
a proper process for a breaking change. The fact that there now
is a discussion

 > As I've certainly mentioned in this thread, the previous committee
 > didn't actually accomplish very much [1].

Measuring "accomplishment" in terms of number of changes seems both
naive and worrying to me, I must say. Maybe the committee actually
accomplished a great deal by not breaking things unnecessarily, for example?

 > I also note that much of what they *did* get through was actually
 > mostly already field-tested in GHC beforehand.

But with only a couple of possible exceptions, those were not
breaking changes affecting pretty much every single user.

Best,

/Henrik

-- 
Henrik Nilsson
School of Computer Science
The University of Nottingham
nhn at cs.nott.ac.uk




This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it. 

Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.


From svenpanne at gmail.com  Tue Oct  6 17:41:51 2015
From: svenpanne at gmail.com (Sven Panne)
Date: Tue, 6 Oct 2015 19:41:51 +0200
Subject: [Haskell-cafe] MRP, 3-year-support-window, and the
 non-requirement of CPP
In-Reply-To: <87612k6j1v.fsf@gnu.org>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 <87612k6j1v.fsf@gnu.org>
Message-ID: <CANBN=mu_un8bJR3eCSMmpoXpL3_Mu-wsgdnZ+ZOiUGP-j4RWmw@mail.gmail.com>

2015-10-06 18:47 GMT+02:00 Herbert Valerio Riedel <hvr at gnu.org>:

> [...] That being said, as how to write your Monad instances today with GHC
> 7.10 w/o CPP, while supporting at least GHC 7.4/7.6/7.8/7.10: This
> *does* work (admittedly for an easy example, but this can be
> generalised):
>
>
> --8<---------------cut here---------------start------------->8---
> module MyMaybe where
>
> import Control.Applicative (Applicative(..))
> import Prelude (Functor(..), Monad(..), (.))
> -- or alternatively: `import qualified Prelude as P`
> [...]
> --8<---------------cut here---------------end--------------->8---
>
> This example above compiles -Wall-clean and satisfies all your 3 stated
> requirements afaics. I do admit this probably not what you had in mind.
>

OK, so the trick is that you're effectively hiding Applicative from the
Prelude (which might be a no-op). This "works" somehow, but is not
satisfactory IMHO for several reasons:

   * If you explicitly import all entities from Prelude, your import list
will typically get *very* long and unreadable. Furthermore, if that's the
suggested technique, what's the point of having a Prelude at all?

   * Some people see qualified imports as the holy grail, but having to
prefix tons of things with "P." is IMHO very ugly. Things are even worse
for operators: The whole notion of operators in itself is totally useless
and superfluous *except* for a single reason: Readability. And exactly that
gets destroyed when you have to qualify them, so I would (sadly) prefer
some #ifdef hell, if that gives me readable code elsewhere.

   * With the current trend of moving things to the Prelude, I can envision
a not-so-distant future where the whole Control.Applicative module will be
deprecated. As it is now, it's mostly superfluous and/or contains only
stuff which might better live somewhere else.


> [...] That's because -Wall-hygiene (w/o opting out of harmless) warnings
> across multiple GHC versions is not considered a show-stopper.
>

That's your personal POV, I'm more leaning towards "-Wall -Werror". I've
seen too many projects where neglecting warning over an extended period of
time made fixing them basically impossible at the end. Anyway, I think that
a sane ecosystem should allow *both* POVs, the sloppy one and the strict
one.


> [...] Beyond what Ben already suggested in another post, there was also the
> more general suggestion to implicitly suppress warnings when you
> explicitly name an import. E.g.
>
>   import Control.Applicative (Applicative(..))
>
> would suppress the redundant-import warning for Applicative via Prelude,
> because we specifically requested Applicative, so we don't mind that
> Prelude re-exports the same symbol. [...]
>

Uh, oh... That would be bad, because one normally wants to see redundant
imports. Without the compiler telling me, how should I find out which are
redundant? Manually trying to remove them step by step? :-/

Cheers,
   S.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151006/a0242e30/attachment-0001.html>

From david.feuer at gmail.com  Tue Oct  6 18:12:46 2015
From: david.feuer at gmail.com (David Feuer)
Date: Tue, 6 Oct 2015 14:12:46 -0400
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <5613B14F.9070107@nottingham.ac.uk>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <5613B14F.9070107@nottingham.ac.uk>
Message-ID: <CAMgWh9ua5L7Jpng4a7J-WVXZ5xhrxz7GT0kn+S4jJEernDJueQ@mail.gmail.com>

On Oct 6, 2015 7:32 AM, "Henrik Nilsson" <Henrik.Nilsson at nottingham.ac.uk>
wrote:
> Executive Summary: Please let us defer further discussion
> and ultimate decision on MRP to the resurrected HaskellPrime
> committee

Many more people are on this mailing list than will be chosen for the
committee. Those who are not chosen have useful perspectives as well.

>   1. Is the Haskell Libraries list and informal voting process
>      really an appropriate, or even acceptable, way to adopt
>      such far-reaching changes to what effectively amounts to
>      Haskell itself?

As others have said, no one wants that.

> But, as has been pointed out in a
> number of postings, a lot of people with very valuable
> perspectives are also very busy, and thus likely to
> miss a short discussion period (as has happened in the
> past in relation to the Burning the Bridges proposal)

The Foldable/Traversable BBP indeed was not as well discussed as it should
have been. AMP, on the other hand, was discussed extensively and publicly
for months. I understand that some people need months of notice to prepare
to participate in a discussion. Unfortunately, I don't think those people
can always be included. Life moves too quickly for that. I do think it
might be valuable to set up a moderated, extremely low volume mailing list
for discussion of only the most important changes, with its messages
forwarded to the general list.

> The need to "field test" MRP prior to discussing
> it in HaskellPrime has been mentioned. Graham and I
> are very sceptical. In the past, at least in the
> past leading up to Haskell 2010 or so, the community
> at large was not roped in as involuntary field testers.

No, and Haskell 2010 was, by most measures, a failure. It introduced no new
language features (as far as I can recall) and only a few of the most
conservative library changes imaginable. Standard Haskell has stagnated
since 1998, 17 years ago. Haskell 2010 did not reflect the Haskell people
used in their research our practical work then, and I think people are
justified in their concern that the next standard may be similarly
disappointing. One of the major problems is the (understandable, and in
many ways productive) concentration of development effort in a single
compiler. When there is only one modern Haskell implementation that is
commonly used, it's hard to know how changes to the standard will affect
other important implementation techniques, and therefore hard to justify
any substantial changes. That was true in 2010, and it is, if anything,
more true now.

> Therefore, please let us defer further discussion and
> ultimate decision on MRP to the resurrected
> HaskellPrime committee, which is where it properly
> belongs. Otherwise, the Haskell community itself might
> be one of the things that MRP breaks.

I hope not. Haskell has gained an awful lot from the researchers, teachers,
and developers who create it and use it. I hope we can work out an
appropriate balance of inclusion, caution, and speed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151006/c9d09a69/attachment.html>

From malcolm.wallace at me.com  Tue Oct  6 19:02:12 2015
From: malcolm.wallace at me.com (Malcolm Wallace)
Date: Tue, 06 Oct 2015 20:02:12 +0100
Subject: [Haskell-cafe] MRP, 3-year-support-window,
 and the non-requirement of CPP
In-Reply-To: <87612k6j1v.fsf@gnu.org>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 <87612k6j1v.fsf@gnu.org>
Message-ID: <F351956E-517E-4387-A3E5-29968ADB5ACA@me.com>


On 6 Oct 2015, at 17:47, Herbert Valerio Riedel wrote:

> 
>> The problem by discussions is that they are done between two groups with
>> quite a difference in experience. On one hand you have people like Bryan,
>> who have considerable contributions to the Haskell ecosystem and much
>> experience in large scale software development (e.g. from Facebook). On the
>> other hand you have people who don't. That's okay. We've all been at the
>> latter group at some point of our career.
> [...]
> 
> At the risk of stating the obvious: I don't think it matters from which
> group a given argument comes from as its validity doesn't depend on the
> messenger. 

In that case, I think you are misunderstanding the relevance of Johan's argument here.  Let me try to phrase it differently.  Some people who can reasonably claim to have experience with million-line plus codebases are warning that this change is too disruptive, and makes maintenance harder than it ought to be.  On the other hand, of the people who say the change is not really disruptive, none of them have (yet?) made claims to have experience of the maintenance of extremely large-scale codebases.  The authority of the speaker does matter in technical arguments of this nature: people without the relevant experience are simply unqualified to make guesses about the impact. 

Regards,
    Malcolm

From hvr at gnu.org  Tue Oct  6 17:03:44 2015
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Tue, 06 Oct 2015 19:03:44 +0200
Subject: MRP, 3-year-support-window, and the non-requirement of CPP
In-Reply-To: <87612k6j1v.fsf@gnu.org> (Herbert Valerio Riedel's message of
 "Tue, 06 Oct 2015 18:47:08 +0200")
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 <87612k6j1v.fsf@gnu.org>
Message-ID: <871td86ia7.fsf@gnu.org>


I hit "send" too early, so here's the incomplete section completed:

On 2015-10-06 at 18:47:08 +0200, Herbert Valerio Riedel wrote:

[...]

> In the specific case of MRP, I can offer you a Wall-perfect transition
> scheme by either using `ghc-options: -fno-mrp-warnings` in your
> cabal-file, or if that doesn't satisfy you, we can delay phase1
> (i.e. redundant return-def warnings) to GHC 8.2:
>
> Now you can continue to write `return = pure` w/o GHC warning bothering
> you until GHC 8.2, at which point the 3-year-window will reach to GHC
> 7.10.
>
> Then starting with GHC 8.2 you can drop the `return` definition, and

...keep supporting a 3-year-window back till GHC 7.10 (which
incorporates AMP and doesn't need `return` explicitly defined anymore)
without CPP.

And since you don't define `return` anymore, you don't get hit by the
MRP warning either, which would start with GHC 8.2.

GHC can keep providing as long as we want it to, and consider `return`
being an extra method of `Monad` simply a GHC-ism.

Future Haskell books and learning materials will hopefully be based on
the next Haskell Report incorporating the AMP and stop referring to the
historical `return` accident (which I consider badly named anyway from a
pedagogically perspective).

Code written unaware of `return` being a method of Monad will work
anyway just fine.

Do you see any problems with this scheme?


From adam at bergmark.nl  Tue Oct  6 19:16:22 2015
From: adam at bergmark.nl (Adam Bergmark)
Date: Tue, 6 Oct 2015 21:16:22 +0200
Subject: [Haskell-cafe] Reducing the need for CPP
In-Reply-To: <mv0s5k$c2a$2@ger.gmane.org>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CANBN=mv6WPLRdvLJppOZ2=1zkd7sWKAHwTF3rHie27RS_YLesA@mail.gmail.com>
 <87k2r0z8r6.fsf@smart-cactus.org>
 <CAK-tuPYhF3e2nPesPZKtDoo350sL8254WGvf0g5cdFu8QZtnww@mail.gmail.com>
 <mv0s5k$c2a$2@ger.gmane.org>
Message-ID: <CACnqJZY2-WgAeaUU7bLQE+_tnLrtaJWQXx5wm9CrmnZvZSjnAg@mail.gmail.com>

On Tue, Oct 6, 2015 at 6:16 PM, Bardur Arantsson <spam at scientician.net>
wrote:

> On 10/06/2015 11:11 AM, Johan Tibell wrote:
> > It might be enough to just add a NOWARN <warning type> pragma that acts
> on
> > a single line/expression. I've seen it in both C++ and Python linters and
> > it works reasonably well and it's quite general.
>
> +1. Simple is good and can hopefully also be backported to older GHC
> releases. (Provided someone's willing to do said releases, obviously.)
>

I've thought of this in the past and it would be great to have. Another
possible use case is to allow this for extensions as well, e.g. "Only allow
UndecidableInstances for this declaration"


>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151006/4f48f31d/attachment.html>

From the.dead.shall.rise at gmail.com  Tue Oct  6 19:32:19 2015
From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov)
Date: Tue, 6 Oct 2015 21:32:19 +0200
Subject: [Haskell-cafe] MRP, 3-year-support-window, and the
 non-requirement of CPP
In-Reply-To: <871td86ia7.fsf@gnu.org>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 <87612k6j1v.fsf@gnu.org> <871td86ia7.fsf@gnu.org>
Message-ID: <CA+tcxkCLqxhXDrjKbVsiezDfhptJY9UtjSMabwtvp+0PK1h+cA@mail.gmail.com>

Hi,

On 6 October 2015 at 19:03, Herbert Valerio Riedel <hvr at gnu.org> wrote:
>> In the specific case of MRP, I can offer you a Wall-perfect transition
>> scheme by either using `ghc-options: -fno-mrp-warnings` in your
>> cabal-file, [...]

Apropos, is there a similar option for AMP warnings? I would rather
use that than CPP.

From cma at bitemyapp.com  Tue Oct  6 20:16:40 2015
From: cma at bitemyapp.com (Christopher Allen)
Date: Tue, 6 Oct 2015 15:16:40 -0500
Subject: [Haskell-cafe] MRP, 3-year-support-window, and the
 non-requirement of CPP
In-Reply-To: <F351956E-517E-4387-A3E5-29968ADB5ACA@me.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 <87612k6j1v.fsf@gnu.org>
 <F351956E-517E-4387-A3E5-29968ADB5ACA@me.com>
Message-ID: <CADnndOpOUaRdYMO4QAmQmAia-3Y5H4eWaJyS-QPJ0frBVUwANg@mail.gmail.com>

Do those participating in this thread think sentiments like this are
constructive or inclusive? Is this how we encourage participation from
newer members of the community?

Framing this debate in terms of a programming pecking order is
unprofessional. Many times, those higher in the ranks will prefer a more
conservative approach, as experienced surgeons once resisted the
introduction of the autoclave.

The problem isn't the change; it's what the change costs you. Provide data
and make your case. Talk about what it _costs_ you, show evidence for that
cost, and describe what would make the change acceptable. Do it without
talking down to a constructed "other" of the people who've neglected to
make the same status display you've injected into this conversation. That
could be valuable input to the discussion, so we would could weigh costs
and benefits as a community.

There _are_ costs associated with going ahead with MRP, especially for
those with large 1mm LOC industrial codebases. This is partly why I'm
lukewarm on the change, but I believe it needs to happen sooner or later
and waiting for more 1mm LOC codebases to be born isn't going to make it
any better. The suggestions that we consider the example of 2to3 I believe
have been more constructive, particularly since we have this lovely
language which lends itself so nicely to static analysis anyway.


On Tue, Oct 6, 2015 at 2:02 PM, Malcolm Wallace <malcolm.wallace at me.com>
wrote:

>
> On 6 Oct 2015, at 17:47, Herbert Valerio Riedel wrote:
>
> >
> >> The problem by discussions is that they are done between two groups with
> >> quite a difference in experience. On one hand you have people like
> Bryan,
> >> who have considerable contributions to the Haskell ecosystem and much
> >> experience in large scale software development (e.g. from Facebook). On
> the
> >> other hand you have people who don't. That's okay. We've all been at the
> >> latter group at some point of our career.
> > [...]
> >
> > At the risk of stating the obvious: I don't think it matters from which
> > group a given argument comes from as its validity doesn't depend on the
> > messenger.
>
> In that case, I think you are misunderstanding the relevance of Johan's
> argument here.  Let me try to phrase it differently.  Some people who can
> reasonably claim to have experience with million-line plus codebases are
> warning that this change is too disruptive, and makes maintenance harder
> than it ought to be.  On the other hand, of the people who say the change
> is not really disruptive, none of them have (yet?) made claims to have
> experience of the maintenance of extremely large-scale codebases.  The
> authority of the speaker does matter in technical arguments of this nature:
> people without the relevant experience are simply unqualified to make
> guesses about the impact.
>
> Regards,
>     Malcolm
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>



-- 
Chris Allen
Currently working on http://haskellbook.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151006/f345e2ab/attachment-0001.html>

From hvr at gnu.org  Tue Oct  6 20:16:22 2015
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Tue, 06 Oct 2015 22:16:22 +0200
Subject: MRP, 3-year-support-window, and the non-requirement of CPP
In-Reply-To: <CA+tcxkCLqxhXDrjKbVsiezDfhptJY9UtjSMabwtvp+0PK1h+cA@mail.gmail.com>
 (Mikhail Glushenkov's message of "Tue, 6 Oct 2015 21:32:19 +0200")
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 <87612k6j1v.fsf@gnu.org> <871td86ia7.fsf@gnu.org>
 <CA+tcxkCLqxhXDrjKbVsiezDfhptJY9UtjSMabwtvp+0PK1h+cA@mail.gmail.com>
Message-ID: <87d1wrycq1.fsf@gnu.org>

Hi,

On 2015-10-06 at 21:32:19 +0200, Mikhail Glushenkov wrote:
> On 6 October 2015 at 19:03, Herbert Valerio Riedel <hvr at gnu.org> wrote:
>>> In the specific case of MRP, I can offer you a Wall-perfect transition
>>> scheme by either using `ghc-options: -fno-mrp-warnings` in your
>>> cabal-file, [...]
>
> Apropos, is there a similar option for AMP warnings? I would rather
> use that than CPP.

Sure, added in GHC 7.8:

| In GHC 7.10, Applicative will become a superclass of Monad,
| potentially breaking a lot of user code. To ease this transition, GHC
| now generates warnings when definitions conflict with the
| Applicative-Monad Proposal (AMP).
|
| A warning is emitted if a type is an instance of Monad but not of
| Applicative, MonadPlus but not Alternative, and when a local function
| named join, <*> or pure is defined.
|
| The warnings are enabled by default, and can be controlled using the
| new flag -f[no-]warn-amp.


However, if you use that now with GHC 7.10 you get a warning:

| $ ghc-7.10.2 -fno-warn-amp
|  
| on the commandline: Warning:
|     -fno-warn-amp is deprecated: it has no effect, and will be removed in GHC 7.12

so you you'll need to guard that with something like

  if impl(ghc == 7.8.*) ghc-options: -fno-warn-amp


From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk  Tue Oct  6 20:36:41 2015
From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis)
Date: Tue, 6 Oct 2015 21:36:41 +0100
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <CAHZrzdqPbv5OHzE8UEnxQ0_TXcmQbatJZC6g2mg9eBz1-SP_Dw@mail.gmail.com>
References: <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca>
 <CAGcFDtjuOAd0M2AVRK8Cx3kG0AEAHZ_D7WR9Z9yOmZ6Lo7uYEw@mail.gmail.com>
 <CAHZrzdqPbv5OHzE8UEnxQ0_TXcmQbatJZC6g2mg9eBz1-SP_Dw@mail.gmail.com>
Message-ID: <20151006203641.GS11050@weber>

On Mon, Oct 05, 2015 at 05:40:43PM -0700, Gregory Collins wrote:
>    - defaultTimeLocale moved from System.Locale to Data.Time.Format in
>    time-1.5 (no compat package for this, afaik)

    http://hackage.haskell.org/package/time-compat

From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk  Tue Oct  6 20:39:01 2015
From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis)
Date: Tue, 6 Oct 2015 21:39:01 +0100
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <CAHZrzdqPbv5OHzE8UEnxQ0_TXcmQbatJZC6g2mg9eBz1-SP_Dw@mail.gmail.com>
References: <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca>
 <CAGcFDtjuOAd0M2AVRK8Cx3kG0AEAHZ_D7WR9Z9yOmZ6Lo7uYEw@mail.gmail.com>
 <CAHZrzdqPbv5OHzE8UEnxQ0_TXcmQbatJZC6g2mg9eBz1-SP_Dw@mail.gmail.com>
Message-ID: <20151006203900.GT11050@weber>

On Mon, Oct 05, 2015 at 05:40:43PM -0700, Gregory Collins wrote:
> On Mon, Oct 5, 2015 at 3:18 PM, Bryan Richter <b at chreekat.net> wrote:
> > Hang on a moment, are you saying that all the people writing to argue
> > that these changes would require them to write dozens more #ifdef's
> > actually don't have to write any at all?
> 
> Um, no, it usually isn't anything like that. Here's a sampling of some of
> the things I've used CPP for in the past few years:
> 
>    - After GHC 7.4, when using a newtype in FFI imports you need to import
>    the constructor, i.e. "import Foreign.C.Types(CInt(..))" --- afaik CPP is
>    the only way to shut up warnings everywhere
>    - defaultTimeLocale moved from System.Locale to Data.Time.Format in
>    time-1.5 (no compat package for this, afaik)
>    - one of many various changes to Typeable in the GHC 7.* series
>    (deriving works better now, mkTyCon vs mkTyCon3, etc)
>    - Do I have to hide "catch" from Prelude, or not? It got moved, and
>    "hiding" gives an error if the symbol you're trying to hide is missing.
>    Time to break out the CPP (and curse myself for not just using the
>    qualified import in the first place)
>    - Do I get monoid functions from Prelude or from Data.Monoid? Same w/
>    Applicative, Foldable, Word. I don't know where anything is supposed to
>    live anymore, or which sequence of imports will shut up spurious warnings
>    on all four versions of GHC I support, so the lowest-friction fix is: break
>    out the #ifdef spackle
>    - ==# and friends return Int# instead of Bool after GHC 7.8.1
>    - To use functions like "tryReadMVar", "unsafeShiftR", and
>    "atomicModifyIORef'" that are in recent base versions but not older ones
>    (this is a place where CPP use is actually justified)

In fact I think all of these apart from the FFI one could be solved with a
-compat package, could they not?

From mark.lentczner at gmail.com  Tue Oct  6 21:14:31 2015
From: mark.lentczner at gmail.com (Mark Lentczner)
Date: Tue, 6 Oct 2015 14:14:31 -0700
Subject: Monad of no `return` Proposal (MRP): Moving `return` out of
 `Monad`
In-Reply-To: <87io6zmr2x.fsf@gnu.org>
References: <87io6zmr2x.fsf@gnu.org>
Message-ID: <CAAOoiFZj2pW=bHXmvw4zXMW+hNfUSBbeOPgY9ZPk+vJ7ypN+AQ@mail.gmail.com>

On Thu, Sep 24, 2015 at 2:43 PM, Herbert Valerio Riedel <hvr at gnu.org> wrote:

> TLDR: To complete the AMP, turn `Monad(return)` method into a
>       top-level binding aliasing `Applicative(pure)`.
>

Sure... if we had a language that no one uses and could keep reforming like
putty until it is perfect. But we don't.

A modest proposal:

We can't keep tinkering with a language and it's libraries like this AND
have a growing ecosystem that serves an ever widening base, including the
range from newcomer to commercial deployment. SO - Why let's do all the
language tinkering in GHC 8 there can be as many prereleases of that as
needed until it is just right. ...and leave GHC 7 (7.10? roll back to
7.8.4?) for all of us doing essential and dependable libraries, commercial
work, projects on Haskell that we don't want to have to go back and #ifdefs
to twice a year just to keep running, educators, people writing books. We
can keep improving GHC 7 as needed, and focus on bugs, security issues,
patches, cross compatibility, etc.

Think of it as Perl 6 or Python 3 for Haskell.

- Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151006/838875c7/attachment.html>

From mark.lentczner at gmail.com  Tue Oct  6 21:15:10 2015
From: mark.lentczner at gmail.com (Mark Lentczner)
Date: Tue, 6 Oct 2015 14:15:10 -0700
Subject: MRP, 3-year-support-window, and the non-requirement of CPP (was:
 [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return`
 out of `Monad`)
In-Reply-To: <CAK-tuPYxNM9uoywucSOT6O3RFhw2AGhCvBTKjOruKQK2V5dY3Q@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 <CAK-tuPYxNM9uoywucSOT6O3RFhw2AGhCvBTKjOruKQK2V5dY3Q@mail.gmail.com>
Message-ID: <CAAOoiFauRYsFLa_4LfuRq=s7+LhoAqFwEBEEzcuYv2pdesgdCQ@mail.gmail.com>

On Thu, Sep 24, 2015 at 2:43 PM, Herbert Valerio Riedel <hvr at gnu.org> wrote:

> TLDR: To complete the AMP, turn `Monad(return)` method into a
>       top-level binding aliasing `Applicative(pure)`.
>

Sure... if we had a language that no one uses and could keep reforming like
putty until it is perfect. But we don't.

A modest proposal:

We can't keep tinkering with a language and it's libraries like this AND
have a growing ecosystem that serves an ever widening base, including the
range from newcomer to commercial deployment. SO - Why let's do all the
language tinkering in GHC 8 there can be as many prereleases of that as
needed until it is just right. ...and leave GHC 7 (7.10? roll back to
7.8.4?) for all of us doing essential and dependable libraries, commercial
work, projects on Haskell that we don't want to have to go back and #ifdefs
to twice a year just to keep running, educators, people writing books. We
can keep improving GHC 7 as needed, and focus on bugs, security issues,
patches, cross compatibility, etc.

Think of it as Perl 6 or Python 3 for Haskell.

- Mark

On Tue, Oct 6, 2015 at 1:12 AM, Johan Tibell <johan.tibell at gmail.com> wrote:

> (Resending with smaller recipient list to avoid getting stuck in the
> moderator queue.)
>
> On Tue, Oct 6, 2015 at 9:10 AM, Herbert Valerio Riedel <hvr at gnu.org>
>  wrote:
>
>> On 2015-10-05 at 21:01:16 +0200, Johan Tibell wrote:
>> > On the libraries I maintain and have a copy of on my computer right
>> now: 329
>>
>>
>> Although this was already pointed out to you in a response to a Tweet of
>> yours, I'd like to expand on this here to clarify:
>>
>>
>> You say that you stick to the 3-major-ghc-release support-window
>> convention for your libraries. This is good, because then you don't need
>> any CPP at all! Here's why:
>>
>> [...]
>>
>
> So what do I have to write today to have my Monad instances be:
>
>  * Warning free - Warnings are useful. Turning them off or having spurious
> warnings both contribute to bugs.
>  * Use imports that either are qualified or have explicit import lists -
> Unqualified imports makes code more likely to break when dependencies add
> exports.
>  * Don't use CPP.
>
> Neither AMP or MRP includes a recipe for this in their proposal. AMP got
> one post-facto on the Wiki. It turns out that the workaround there didn't
> work (we tried it in Cabal and it conflicted with one of the above
> requirements.)
>
> PS: I'm a bit disappointed you seem to dismiss this proposal right away
>>     categorically without giving us a chance to address your
>>     concerns. The proposal is not a rigid all-or-nothing thing that
>>     can't be tweaked and revised.  That's why we're having these
>>     proposal-discussions in the first place (rather than doing blind
>>     +1/-1 polls), so we can hear everyone out and try to maximise the
>>     agreement (even if we will never reach 100% consensus on any
>>     proposal).
>>
>>     So please, keep on discussing!
>>
>
> The problem by discussions is that they are done between two groups with
> quite a difference in experience. On one hand you have people like Bryan,
> who have considerable contributions to the Haskell ecosystem and much
> experience in large scale software development (e.g. from Facebook). On the
> other hand you have people who don't. That's okay. We've all been at the
> latter group at some point of our career.
>
> What's frustrating is that people don't take a step bad and realize that
> they might be in the latter group and should perhaps listen to those in the
> former. This doesn't happen, instead we get lots of "C++ and Java so bad
> and we don't want to be like them." Haskell is not at risk of becoming C++
> or Java (which are a large improvement compared to the languages came
> before them). We're at risk of missing our window of opportunity. I think
> that would be a shame, as I think Haskell is a step forward compared to
> those languages and I would like to see more software that used be written
> in Haskell.
>
> We've been through this many times before on the libraries list. I'm not
> going to win an argument on this mailing list. Between maintaining
> libraries you all use and managing a largish team at Google, I don't have
> much time for a discussion which approaches a hundred emails and is won by
> virtue of having lots of time to write emails.
>
> -- Johan
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151006/98025ec9/attachment-0001.html>

From greg at gregorycollins.net  Tue Oct  6 21:29:53 2015
From: greg at gregorycollins.net (Gregory Collins)
Date: Tue, 6 Oct 2015 14:29:53 -0700
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <20151006203900.GT11050@weber>
References: <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca>
 <CAGcFDtjuOAd0M2AVRK8Cx3kG0AEAHZ_D7WR9Z9yOmZ6Lo7uYEw@mail.gmail.com>
 <CAHZrzdqPbv5OHzE8UEnxQ0_TXcmQbatJZC6g2mg9eBz1-SP_Dw@mail.gmail.com>
 <20151006203900.GT11050@weber>
Message-ID: <CAHZrzdrkOs5oRwMEKcHKtiDtFk8is+x5ALuoeBvy8NTnRJU0_Q@mail.gmail.com>

On Tue, Oct 6, 2015 at 1:39 PM, Tom Ellis <
tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote:

> In fact I think all of these apart from the FFI one could be solved with a
> -compat package, could they not?
>

Who cares? In practice, the programs break and I have to fix them. Most of
the time, CPP is the lowest-friction solution -- if I rely on a -compat
package, first I have to know it exists and that I should use it to fix my
compile error, and then I've added an additional non-platform dependency
that I'm going to have to go back and clean up in 18 months. Usually, to be
honest, *actually* the procedure is that the new RC comes out and I get
github pull requests from hvr@ :-) :-)

In response to the other person who asked "why do you want to support so
many GHC versions anyways?" --- because I don't hate my users, and don't
want to force them to run on the upgrade treadmill if they don't have to?
Our policy is to support the last 4 major GHC versions (or 2 years,
whichever is shorter). And if we support a version of GHC, I want our
libraries to compile on it without warnings, I don't think that should
mystify anyone.

-- 
Gregory Collins <greg at gregorycollins.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151006/d0ab3c30/attachment.html>

From johnw at newartisans.com  Tue Oct  6 18:31:33 2015
From: johnw at newartisans.com (John Wiegley)
Date: Tue, 06 Oct 2015 11:31:33 -0700
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <5613B14F.9070107@nottingham.ac.uk> <mv0s3b$c2a$1@ger.gmane.org>
 <561405F1.80805@nottingham.ac.uk>
Message-ID: <m2612jsw1l.fsf@newartisans.com>

>>>>> Henrik Nilsson <Henrik.Nilsson at nottingham.ac.uk> writes:

> Of course 25 years+ of legacy is there. Quantifiable or not. And of course
> it must count if we wish Haskell to be taken seriously and be increasingly
> successful. That is at least the view of a significant part of the Haskell
> community. And the way to account for it, both that which is quantifiable
> and that which is not, is to make sure that fundamental language changes are
> given due consideration in a forum where all stakeholders are adequately
> represented.

Henrik,

I do appreciate this point of view. It must be stated, however, that some have
become frustrated by the frozen state the Haskell language has entered. No
substantial changes have occurred since 1998. A new Prime committee is being
nominated, it is true, but that has happened before.

Arguments for stability might be seen by some as arguments to never change,
since the same pain we must endure now, will also have to be endured later.
Books and code will still be broken, teaching will still be made harder, etc.
A willingness to accept that pain shows concretely that a brighter future is
coming.

I'm very much against frivolous change, but I strongly want improvement. If it
means a progressive delivery of changes, or grouping them a bit more, that is
fine. I just worry when I see the "caution" argument used to put a break on
daring changes time and again, because otherwise, why should we change at all?

By comparison, the C++ language -- significantly more complex and affecting a
much larger community of users -- has released 4 separate standards in the
timeframe between Haskell 98 and now, each of them introducing significant
functionality that created work for compiler and tools vendors, users,
authors, teachers, and learners. If they can do it, I'm confident we can as
well.

John

From jmct at jmct.cc  Tue Oct  6 22:56:47 2015
From: jmct at jmct.cc (=?UTF-8?Q?Jos=C3=A9_Manuel_Calder=C3=B3n_Trilla?=)
Date: Tue, 6 Oct 2015 15:56:47 -0700
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <CAHZrzdrkOs5oRwMEKcHKtiDtFk8is+x5ALuoeBvy8NTnRJU0_Q@mail.gmail.com>
References: <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca>
 <CAGcFDtjuOAd0M2AVRK8Cx3kG0AEAHZ_D7WR9Z9yOmZ6Lo7uYEw@mail.gmail.com>
 <CAHZrzdqPbv5OHzE8UEnxQ0_TXcmQbatJZC6g2mg9eBz1-SP_Dw@mail.gmail.com>
 <20151006203900.GT11050@weber>
 <CAHZrzdrkOs5oRwMEKcHKtiDtFk8is+x5ALuoeBvy8NTnRJU0_Q@mail.gmail.com>
Message-ID: <CAK+ijdvbxW50-Q3-Vk5PaKyrCrsu7qLVvUzZ3K0iCSFR7h900g@mail.gmail.com>

Hello all,

I agree with Henrik, I'm very keen on giving the new Haskell committee a
shot.

While some may not think that Haskell2010 was a success, I think it would
be difficult to argue that Haskell98 was anything but a resounding success
(even if you don't think the language was what it could have been!).
Haskell98 stabilized the constant changes of the proceeding 7 years. The
stability brought with it books and courses, and the agreed-upon base of
the language allowed _research_ to flourish as well. Having an agreed base
allowed the multiple implementations to experiment with different methods
of implementing what the standard laid out.

Many of us here learned from those texts or those courses. It's easy online
to say that materials being out of date isn't a big deal, but it can turn
people off the language when the code they paste into ghci doesn't work. We
use Haskell for the compilers course at York; Haskell is the means, not the
end, so having to update the materials frequently is a significant cost. It
can be difficult to defend the choice of using Haskell when so much time is
spent on something that 'isn't the point' of the course.

Does that mean that we should never change the language? Of course not, but
this constant flux within Haskell is very frustrating. Maybe Haskell2010
wasn't what everyone wanted it to be, but that does not mean the _idea_ of
a committee is without merit. Having controlled, periodic changes that are
grouped together and thought through as a coherent whole is a very useful
thing. One of the insights of the original committee was that there would
always be one chair at any point in time. The chair of the committee had
final say on any issue. This helped keep the revisions coherent and ensured
that Haskell made sense as a whole.

Lastly, I'd like to quote Prof. Runciman from almost exactly 22 years ago
when the issue of incompatible changes
came up. His thoughts were similar to Johan's:

On 1993-10-19 at 14:12:30 +0100, Colin Runciman wrote:

> As a practical suggestion, if any changes for version 1.3 could make
> some revision of a 1.2 programs necessary, let's have a precise
> stand-alone specification of these revisions and how to make them.
> It had better be short and simple.  Many would prefer it to be empty.
> Perhaps it should be implemented in Haskell compilers?


Overall I don't see the rush for these changes, let's try putting our faith
in a new Haskell committee, whomever it is comprised of.

Best wishes,

Jos? Manuel

P.S. A year ago Prof. Hinze sent me some Miranda code of his from 1995 as I
was studying his thesis. I was able to run the code without issue, allowing
me to be more productive in my research ;-)

On Tue, Oct 6, 2015 at 2:29 PM, Gregory Collins <greg at gregorycollins.net>
wrote:

>
> On Tue, Oct 6, 2015 at 1:39 PM, Tom Ellis <
> tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote:
>
>> In fact I think all of these apart from the FFI one could be solved with a
>> -compat package, could they not?
>>
>
> Who cares? In practice, the programs break and I have to fix them. Most of
> the time, CPP is the lowest-friction solution -- if I rely on a -compat
> package, first I have to know it exists and that I should use it to fix my
> compile error, and then I've added an additional non-platform dependency
> that I'm going to have to go back and clean up in 18 months. Usually, to be
> honest, *actually* the procedure is that the new RC comes out and I get
> github pull requests from hvr@ :-) :-)
>
> In response to the other person who asked "why do you want to support so
> many GHC versions anyways?" --- because I don't hate my users, and don't
> want to force them to run on the upgrade treadmill if they don't have to?
> Our policy is to support the last 4 major GHC versions (or 2 years,
> whichever is shorter). And if we support a version of GHC, I want our
> libraries to compile on it without warnings, I don't think that should
> mystify anyone.
>
> --
> Gregory Collins <greg at gregorycollins.net>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151006/52cc5d32/attachment.html>

From mwm at mired.org  Tue Oct  6 23:24:15 2015
From: mwm at mired.org (Mike Meyer)
Date: Tue, 06 Oct 2015 23:24:15 +0000
Subject: MRP, 3-year-support-window, and the non-requirement of CPP (was:
 [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return`
 out of `Monad`)
In-Reply-To: <CAAOoiFauRYsFLa_4LfuRq=s7+LhoAqFwEBEEzcuYv2pdesgdCQ@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 <CAK-tuPYxNM9uoywucSOT6O3RFhw2AGhCvBTKjOruKQK2V5dY3Q@mail.gmail.com>
 <CAAOoiFauRYsFLa_4LfuRq=s7+LhoAqFwEBEEzcuYv2pdesgdCQ@mail.gmail.com>
Message-ID: <CAD=7U2C0a9US=mSeko44ThXD2=xXqA5GqQgweF3wq3X98SYsYw@mail.gmail.com>

On Tue, Oct 6, 2015 at 4:15 PM Mark Lentczner <mark.lentczner at gmail.com>
wrote:

>
> On Thu, Sep 24, 2015 at 2:43 PM, Herbert Valerio Riedel <hvr at gnu.org>
>  wrote:
>
>> TLDR: To complete the AMP, turn `Monad(return)` method into a
>>       top-level binding aliasing `Applicative(pure)`.
>>
>
> Sure... if we had a language that no one uses and could keep reforming
> like putty until it is perfect. But we don't.
>
> A modest proposal:
>
> We can't keep tinkering with a language and it's libraries like this AND
> have a growing ecosystem that serves an ever widening base, including the
> range from newcomer to commercial deployment. SO - Why let's do all the
> language tinkering in GHC 8 there can be as many prereleases of that as
> needed until it is just right. ...and leave GHC 7 (7.10? roll back to
> 7.8.4?) for all of us doing essential and dependable libraries, commercial
> work, projects on Haskell that we don't want to have to go back and #ifdefs
> to twice a year just to keep running, educators, people writing books. We
> can keep improving GHC 7 as needed, and focus on bugs, security issues,
> patches, cross compatibility, etc.
>

I'm just curious how much you think this would help, assuming that your
solution would imply not upgrading to 8 until you're ready to. After all,
you can already simply not upgrade now, and create (and distribute) fixes
for bugs, security issues, cross-compatibility for 7 as you see fit.

While that's a popular thing to do in lots of systems (but if we don't it.
for gnus sake let's not adopt the inane parity implies stability numbering
convention), it leaves two major issues unaddressed.

#1, developer time. You need to get the people doing the work now to divide
their efforts into the two branches.I don't know what percentage of that
work is volunteer time, but I expect the answer is "most of it". If they
aren't interested doing that now, what do you expect to change their mind?

#2, everything else in the ecosystem. If you need updates to a library that
require the branch you're not using, where does that leave you?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151006/cf187cc3/attachment-0001.html>

From rf at rufflewind.com  Wed Oct  7 00:21:13 2015
From: rf at rufflewind.com (Phil Ruffwind)
Date: Tue, 6 Oct 2015 20:21:13 -0400
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <m2612jsw1l.fsf@newartisans.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <5613B14F.9070107@nottingham.ac.uk> <mv0s3b$c2a$1@ger.gmane.org>
 <561405F1.80805@nottingham.ac.uk> <m2612jsw1l.fsf@newartisans.com>
Message-ID: <CADb8sTMVSuR8so=h6pYKvEXnC=HyGJFyQn-NsvfVf3CVGU=8+Q@mail.gmail.com>

> By comparison, the C++ language -- significantly more complex and affecting a
> much larger community of users -- has released 4 separate standards in the
> timeframe between Haskell 98 and now, each of them introducing significant
> functionality that created work for compiler and tools vendors, users,
> authors, teachers, and learners. If they can do it, I'm confident we can as
> well.

C++ never makes any breaking changes.* It has only added things (with
the undesirable effect of making the newer and more useful things more
verbose than the legacy cruft).

[*]: ? minus a few rare cases where the features had 0% usage, like
'export templates', so their removal wasn't at all controversial.

From gershomb at gmail.com  Wed Oct  7 01:18:03 2015
From: gershomb at gmail.com (Gershom B)
Date: Tue, 6 Oct 2015 21:18:03 -0400
Subject: [Haskell-cafe] MRP, 3-year-support-window, and the
 non-requirement of CPP
In-Reply-To: <87612k6j1v.fsf@gnu.org>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 <87612k6j1v.fsf@gnu.org>
Message-ID: <etPan.56147308.2268a666.7b73@mbp.local>

Dear all,

I think this discussion has gotten quite heated for reasons not related to the concrete MRP proposal, which, to be honest, I considered quite modest in terms of both scope and impact.

Instead, I think it is a proxy for lots of remaining frustration and anxiety over the poor handling over the Foldable Traversable Proposal. I would like to remind everyone that due to the broad discussions and concerns over the proposal, a very rare, careful poll of Haskell users was taken, announced broadly in many channels. [1] The poll, overwhelmingly, revealed a mandate for the FTP. The breakdown of that mandate was 87% in favor among hobbyists and 79% in favor among non-hobbyists (who constituted a majority of those polled).?

I. Generalities

That said, even the _best_ poll was not a substitute for a better earlier discussion. The handling of the AMP and FTP, which I think was heroic in terms of minimizing breakage while accomplishing long-desired change also still could have been better. As a whole, the work accomplished the mandate of allowing code to be written backwards-compatible without requiring CPP. However, it did not also seek to prevent warnings. This in itself was an enormous step forward from changes in the past which have _not_ even managed to prevent the need for CPP. At the time, I think it was not recognized how much desire there would be for things that were _both_ CPP free and _also_ warning-free for 3 releases.

I think one of the great elements of progress in the current discussion is that there is now a proposal on the table which recognizes this, and seeks to accomplish this change in accordance with this desire. It is not the world?s most important change, but the recognition that change should seek to be both CPP _and_ warning free is a good recognition, and I?m sure it will be taken into account in future proposals as well.

I don?t think it is useful to continue to have abstract discussions on the conflict between desire for incremental improvement versus the need to minimize pain on maintainers. We might as well continue to argue about the need for purely functional programming versus the need to print ?hello world? to the console. Rather, we should put our collective minds together as collaborators and colleagues to accomplish _both_, and to come up with solutions that should work for everyone. To the extent this discussion has been about that, I think it has been useful and positive. However, to the extent this discussion insists, on either side, on the shallow idea that we must treat ?improvement? versus ?stability? as irreconcilable factions in necessary conflict, then I fear it will be a missed opportunity.

II. Particulars

With that in mind, I think the _concrete_ voices of concern have been the most useful. Gregory Collins? list of issues requiring CPP should be very sobering. Of note, I think they point to areas where the core libraries committee has not paid _enough_ attention (or perhaps has not been sufficiently empowered: recall that not all core libraries fall under its maintenance [2]). Things like the newtype FFI issue, the changes to prim functions, the splitup of old-time and the changes to exception code were _not_ vetted as closely as the AMP and FTP were, or as the MRP is currently being. I don?t know all the reasons for this, but I suspect they just somewhat slipped under the radar. In any case, if all those changes were as carefully engineered as the MRP proposal has been, then imho things would have been much smoother. So, while this discussion may be frustrating, it nonetheless in some ways provides a model of how people have sought to do better and be more proactive with careful discussion of changes. This is much appreciated.

Personally, since the big switch to extensible exceptions back prior in 6.10, and since the split-base nonsense prior to that, very few changes to the core libraries have really caused too much disruption in my code. Since then, the old-time cleanup was the worst, and the big sin there was that time-locale-compat was only written some time after the fact by a helpful third-party contributor and not engineered from the start. (I will note that the time library is one of the core libraries that is _not_ maintained by the core libraries committee).?

Outside of that, the most disruptive changes to my code that I can recall have been from changes to the aeson library over the years ? particularly but not only regarding its handling of doubles. I don?t begrudge these changes ? they iteratively arrived at a _much_ better library than had they not been made. [3] After than, I made a few changes regarding Happstack and Snap API changes if I recall. Additionally, the addition of ?die? to System.Exit caused a few name clashes. My point is simply that there are many packages outside of base that also move, and ?real? users with ?real? code will these days often have quite a chain of dependencies, and will encounter movement and change from across many of them. So if we say ?base never changes? that does not mean ?packages will never break? ? it just means that base will not have the same opportunity to improve that other packages do, which will eventually lead to frustration, just as it did in the past and in the leadup to the BBP.

III. Discussions

Further, since there has been much discussion of a window of opportunity, I would like to offer a counterpoint to the (sound) advice that we take into consideration voices with long experience in Haskell. The window of opportunity is, by definition, regarding takeup of Haskell by new users. And so if newer users favor certain changes, then it is good evidence that those changes will help with uptake among other new users. So, if they are good changes on their own, then the fact that they are appealing to newer users should be seen as a point in their favor, rather than a reason to dismiss those opinions. But if we are in a situation where we see generations of adopters pitted against one another, then we already have deeper problems that need to be sorted out.

Regarding where and how to have these discussions ? the decision was made some time ago (I believe at the start of the initial Haskell Prime process if not sooner, so circa 2009?) that the prime committee would focus on language extensions and not library changes, and that those changes would be delegated to the libraries@ list. The lack of structure to the libraries@ list is what prompted the creation of the libraries committee, whose ultimately responsibility it is to decide on and shepherd through these changes, in consultation with others and ideally driven by broad consensus. Prior to this structure, things broke even more, imho, and simultaneously the things that were widely desired were still not implemented. So I thank the libraries committee for their good work so far.

So, it may be that the process of community discussion on core libraries changes is not best suited for the libraries@ list. But if not there, Where? I worry that the proliferation of lists will not improve things here. Those involved with Haskell have multiplied (this is good). The voices to take into account have multiplied (this is good). Necessarily, this means that there will just be _more_ stuff, and making sure that everyone can filter to just that part they want to is difficult. Here, perhaps, occasional libraries-related summary addenda to the ghc newsletter could be appropriate? Or is there another venue we should look towards???Chair?s reports? to the Haskell Weekly News maybe?

IV. Summing up

We should bear in mind after all that this is just about cleaning up a redundant typeclass method (albeit one in a very prominent place) and hardly the hill anyone would want to die on [4]. Nonetheless,?I think it would be?a good sign of progress and collaboration if we can find a way to implement a modest change like this in a way that everyone finds acceptable vis a vis a sufficiently slow pace, the lack of a need for CPP and the lack of any induced warnings. On the other hand, other opportunities will doubtless present themselves in the future.

Best,
Gershom

[1] https://mail.haskell.org/pipermail/libraries/2015-February/025009.html
[2]?https://wiki.haskell.org/Library_submissions#The_Core_Libraries
[3] and in any case I am sure Bryan would be the last to want us to treat him as some sort of ?guru? on these matters.?
[4] for those in search of better hills to die on, this is a list of some good ones: http://www.theawl.com/2015/07/hills-to-die-on-ranked?

P.S. In case there is any question, this email, as all emails I write that do not state otherwise, is not being written in any particular capacity regarding the various infra-related hats I wear, but is just an expression of my own personal views.



From mwm at mired.org  Wed Oct  7 02:24:58 2015
From: mwm at mired.org (Mike Meyer)
Date: Wed, 07 Oct 2015 02:24:58 +0000
Subject: Haskell ecosystem improvements meta-propsal
In-Reply-To: <etPan.56147308.2268a666.7b73@mbp.local>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 <87612k6j1v.fsf@gnu.org> <etPan.56147308.2268a666.7b73@mbp.local>
Message-ID: <CAD=7U2BASVF+cmnf+Ue=zXdZL26Od7n63wEL7jtZ7ZPAUgYW1A@mail.gmail.com>

There's been a lot of complaints about the way things have worked in the
past, with things going to fast, or to slow, or the right people not being
heard, or notices not going to the right places, etc.

As far as I can tell, the current process is that someone make a proposal
on some mailing list, that gets debated by those who find out about it,
maybe a wiki page gets set up and announced to those who already know about
the proposal, and then it either happens or not.

There's actually quite a bit of experience with dealing with such. I've
dealt with the IETF RFC process and the Python PEP process, and both of
them worked better than that. So I think we can do better.

I'd like to suggest we adapt something a bit more formal that any process
that changes a developer-visible API should have to go through. Note that
bug fixes, most security fixes, and other things that don't change the API
wouldn't be subject to this requirement. However, any change in an API,
even one that's 100% backward compatible, not possibly breaking any code,
would be. Initial thoughts on scope are anything in the Haskell Platform,
as that seems to be a minimal definition of "Haskell ecosystem". Further,
anything on hackage should be able to avail itself of the process.

My concrete, though very broad proposal, with lots of details to be filled
in yet, is that we need:

1) A wiki page that lists all proposals being considered, along with their
current status and other relevant information.

2) A set of requirements a proposal must meet in order to be listed on that
page.

3) An announcements list that only has announcements of things being added
to the list. Anybody who has time to vote on a proposal should have time to
be on this list.

4) An editorial group responsible for maintaining the list and providing
guidance on meeting the requirements to get on it.

The first three are easy. The fourth one is the killer. Somebody to do the
work is the stumbling block for most proposals. This doesn't require deep
technical knowledge of Haskell or the current ecosystem, but the ability to
implement a process and judge things based on form and not content, Since
it's my proposal, I'll volunteer as the first editor. Hopefully, others
with better reputation will alsob e available.

If adopted, the first two things on the list need to be a description of
the process, followed shortly by a description of the requirements to be
met.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151007/4a22263b/attachment.html>

From mark.lentczner at gmail.com  Wed Oct  7 06:36:39 2015
From: mark.lentczner at gmail.com (Mark Lentczner)
Date: Tue, 6 Oct 2015 23:36:39 -0700
Subject: MRP, 3-year-support-window, and the non-requirement of CPP (was:
 [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return`
 out of `Monad`)
In-Reply-To: <CAD=7U2C0a9US=mSeko44ThXD2=xXqA5GqQgweF3wq3X98SYsYw@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 <CAK-tuPYxNM9uoywucSOT6O3RFhw2AGhCvBTKjOruKQK2V5dY3Q@mail.gmail.com>
 <CAAOoiFauRYsFLa_4LfuRq=s7+LhoAqFwEBEEzcuYv2pdesgdCQ@mail.gmail.com>
 <CAD=7U2C0a9US=mSeko44ThXD2=xXqA5GqQgweF3wq3X98SYsYw@mail.gmail.com>
Message-ID: <CAAOoiFYUXaVJ5KX0nzGbzzS4ePDDhHK12X5bhC4zZNA+eUhM+w@mail.gmail.com>

Mike -

You might look up the phrase "A modest proposal".

... for gnus sake let's not adopt the inane parity implies stability
> numbering convention ...
>

6.10 .. 6.12 .. 7.0 .. 7.2 .. 7.4 .. 7.8 .. 7.10

- Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151006/f671a0f7/attachment.html>

From mark.lentczner at gmail.com  Wed Oct  7 06:45:15 2015
From: mark.lentczner at gmail.com (Mark Lentczner)
Date: Tue, 6 Oct 2015 23:45:15 -0700
Subject: Haskell ecosystem improvements meta-propsal
In-Reply-To: <CAD=7U2BASVF+cmnf+Ue=zXdZL26Od7n63wEL7jtZ7ZPAUgYW1A@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 <87612k6j1v.fsf@gnu.org> <etPan.56147308.2268a666.7b73@mbp.local>
 <CAD=7U2BASVF+cmnf+Ue=zXdZL26Od7n63wEL7jtZ7ZPAUgYW1A@mail.gmail.com>
Message-ID: <CAAOoiFYnmVWhB1Etq=7e67b2hshn396waAFXJn0x0thD7wcB6Q@mail.gmail.com>

On Tue, Oct 6, 2015 at 7:24 PM, Mike Meyer <mwm at mired.org> wrote:

> I've dealt with the IETF RFC process and the Python PEP process, and both
> of them worked better than that.


While both those are good examples of mostly working organizations
shepherding foundational technical standard(s) along... there is one thing
more important than their processes: Their stance. Both organizations have
a very strong engineering discipline of keeping deployed things working
without change. I don't think it is enough to simply model their process.

Until about three years ago, the Haskell community also had such a
discipline. It has been steadily eroding over the last few years.

- Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151006/92505822/attachment-0001.html>

From mwm at mired.org  Wed Oct  7 07:21:54 2015
From: mwm at mired.org (Mike Meyer)
Date: Wed, 07 Oct 2015 07:21:54 +0000
Subject: Haskell ecosystem improvements meta-propsal
In-Reply-To: <CAAOoiFYnmVWhB1Etq=7e67b2hshn396waAFXJn0x0thD7wcB6Q@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 <87612k6j1v.fsf@gnu.org> <etPan.56147308.2268a666.7b73@mbp.local>
 <CAD=7U2BASVF+cmnf+Ue=zXdZL26Od7n63wEL7jtZ7ZPAUgYW1A@mail.gmail.com>
 <CAAOoiFYnmVWhB1Etq=7e67b2hshn396waAFXJn0x0thD7wcB6Q@mail.gmail.com>
Message-ID: <CAD=7U2BFbDKzkrNdRXxKKeKyCmM1AGJdJyPm0p8Ymaa2n05N6Q@mail.gmail.com>

On Wed, Oct 7, 2015 at 1:45 AM Mark Lentczner <mark.lentczner at gmail.com>
wrote:

> On Tue, Oct 6, 2015 at 7:24 PM, Mike Meyer <mwm at mired.org> wrote:
>
>> I've dealt with the IETF RFC process and the Python PEP process, and both
>> of them worked better than that.
>
>
> While both those are good examples of mostly working organizations
> shepherding foundational technical standard(s) along... there is one thing
> more important than their processes: Their stance. Both organizations have
> a very strong engineering discipline of keeping deployed things working
> without change. I don't think it is enough to simply model their process.
>

Well, until Python 3, anyway.

My goal wasn't to recreate the engineering discipline that deployed things
keep working without change as you upgrade the ecosystem, it's to provide a
mechanism so the community can more easily engage with the evolution of the
ecosystem. Hopefully this will make it easier for the community to move
things forward in a desirable manner. But it's a process, and leaves the
question of whether the desire is for more stability or a less stagnant
language up to the users of the process.

I don't necessarily want to model the IETF or PEP processes. Those are a
starting point. I tried to abstract the initial points out enough that the
final result could be either one of them, or something totally unrelated
that's a better fit for the Haskell community.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151007/757437bd/attachment.html>

From hvr at gnu.org  Wed Oct  7 07:35:21 2015
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Wed, 07 Oct 2015 09:35:21 +0200
Subject: [Haskell-cafe] MRP, 3-year-support-window,
 and the non-requirement of CPP
In-Reply-To: <CANBN=mu_un8bJR3eCSMmpoXpL3_Mu-wsgdnZ+ZOiUGP-j4RWmw@mail.gmail.com>
 (Sven Panne's message of "Tue, 6 Oct 2015 19:41:51 +0200")
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 <87612k6j1v.fsf@gnu.org>
 <CANBN=mu_un8bJR3eCSMmpoXpL3_Mu-wsgdnZ+ZOiUGP-j4RWmw@mail.gmail.com>
Message-ID: <87lhbfm8qu.fsf@gnu.org>

On 2015-10-06 at 19:41:51 +0200, Sven Panne wrote:
> 2015-10-06 18:47 GMT+02:00 Herbert Valerio Riedel <hvr at gnu.org>:
>
>> [...] That being said, as how to write your Monad instances today with GHC
>> 7.10 w/o CPP, while supporting at least GHC 7.4/7.6/7.8/7.10: This
>> *does* work (admittedly for an easy example, but this can be
>> generalised):
>>
>>
>> --8<---------------cut here---------------start------------->8---
>> module MyMaybe where
>>
>> import Control.Applicative (Applicative(..))
>> import Prelude (Functor(..), Monad(..), (.))
>> -- or alternatively: `import qualified Prelude as P`
>> [...]
>> --8<---------------cut here---------------end--------------->8---
>>
>> This example above compiles -Wall-clean and satisfies all your 3 stated
>> requirements afaics. I do admit this probably not what you had in mind.
>>
>
> OK, so the trick is that you're effectively hiding Applicative from the
> Prelude (which might be a no-op). This "works" somehow, but is not
> satisfactory IMHO for several reasons:

[...]

Btw, I've also seen the trick below, in which you use the aliased `A.`
prefix just once so GHC considers the import non-redundant, and don't
have to suffer from prefixed operators in the style of `A.<*>`.

Is this any better?

--8<---------------cut here---------------start------------->8---
import Control.Applicative as A (Applicative(..))

data Maybe' a = Nothing' | Just' a

instance Functor Maybe' where
    fmap f (Just' v) = Just' (f v)
    fmap _ Nothing'  = Nothing'

instance A.Applicative Maybe' where
    pure = Just'
    f1 <*> f2   = f1 >>= \v1 -> f2 >>= (pure . v1)

instance Monad Maybe' where
    Nothing' >>= _  = Nothing'
    Just' x  >>= f  = f x

    return = pure -- "deprecated" since GHC 7.10
--8<---------------cut here---------------end--------------->8---

-- hvr  

From svenpanne at gmail.com  Wed Oct  7 08:07:38 2015
From: svenpanne at gmail.com (Sven Panne)
Date: Wed, 7 Oct 2015 10:07:38 +0200
Subject: [Haskell-cafe] MRP, 3-year-support-window, and the
 non-requirement of CPP
In-Reply-To: <87lhbfm8qu.fsf@gnu.org>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 <87612k6j1v.fsf@gnu.org>
 <CANBN=mu_un8bJR3eCSMmpoXpL3_Mu-wsgdnZ+ZOiUGP-j4RWmw@mail.gmail.com>
 <87lhbfm8qu.fsf@gnu.org>
Message-ID: <CANBN=msSgkP0eS9bim9A9B10kHyMm2=100Y1TsbmbfGpYy1LXA@mail.gmail.com>

2015-10-07 9:35 GMT+02:00 Herbert Valerio Riedel <hvr at gnu.org>:

> Btw, I've also seen the trick below, in which you use the aliased `A.`
> prefix just once so GHC considers the import non-redundant, and don't
> have to suffer from prefixed operators in the style of `A.<*>`.
>
> Is this any better? [...]
>

While not perfect, it's much better than having to fiddle around with
Prelude imports. Although there's the slight danger that somebody else (or
the author 1 year later) looks at the code and has a WTF-moment... ;-) To
be honest, while it's somehow obvious how it works when you read it, I've
never seen that trick. Perhaps stuff like this belongs into some general
"Porting Guide", along with its alternatives. It's general enough that it
should not be buried in some AMP/FTP/return/... transitioning guide.

Cheers,
   S.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151007/e669b6a2/attachment.html>

From malcolm.wallace at me.com  Wed Oct  7 08:12:57 2015
From: malcolm.wallace at me.com (Malcolm Wallace)
Date: Wed, 07 Oct 2015 09:12:57 +0100
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <m2612jsw1l.fsf@newartisans.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <5613B14F.9070107@nottingham.ac.uk> <mv0s3b$c2a$1@ger.gmane.org>
 <561405F1.80805@nottingham.ac.uk> <m2612jsw1l.fsf@newartisans.com>
Message-ID: <4B6D3599-C998-4DCC-A2FC-E5779E4CBA5D@me.com>


On 6 Oct 2015, at 19:31, John Wiegley wrote:

> It must be stated, however, that some have
> become frustrated by the frozen state the Haskell language has entered. No
> substantial changes have occurred since 1998.

Haskell has de-facto undergone huge changes and additions since 1998.  The official language standard may not have kept pace, but a huge amount has happened in the last 17 years:  FFI, Cabal&Hackage, type families, just to pick the first three that come to mind.

No-one objects to these improvements.  The language and its ecosystem are not frozen.  What many people do object to is unnecessary and under-motivated breakage of existing code.  The "monad of no return" proposal promises no new semantic benefits, just a small conceptual tidy-up, but at a huge cost to the community at large.  It is of a completely different category to the substantial and useful changes that we are used to.

Regards,
   Malcolm

From simonpj at microsoft.com  Wed Oct  7 15:36:41 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 7 Oct 2015 15:36:41 +0000
Subject: [Haskell-cafe] MRP, 3-year-support-window, and the
 non-requirement of CPP (was: Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`)
In-Reply-To: <CAD=7U2C0a9US=mSeko44ThXD2=xXqA5GqQgweF3wq3X98SYsYw@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 <CAK-tuPYxNM9uoywucSOT6O3RFhw2AGhCvBTKjOruKQK2V5dY3Q@mail.gmail.com>
 <CAAOoiFauRYsFLa_4LfuRq=s7+LhoAqFwEBEEzcuYv2pdesgdCQ@mail.gmail.com>
 <CAD=7U2C0a9US=mSeko44ThXD2=xXqA5GqQgweF3wq3X98SYsYw@mail.gmail.com>
Message-ID: <3d672fd5db1546b189f16d2a890a953d@DB4PR30MB030.064d.mgd.msft.net>

I think there are several different conversations going on at once in this thread.  I think it?s worth keeping them separate.


?         Haskell Prime.  The intention there is to take a set of language features that are already in wide use in GHC (i.e. have demonstrably proved valuable), work out any dark corners, formalise them, and embody the result in a new Haskell Report.   That puts a useful stake in the ground, empowers alternative implementations of Haskell, gives confidence all round.

I think it?d be unusual for the Haskell Prime committee to specify a new feature of the language, one that had not been field tested.


?         Libraries.  AMP, BBP, and Monad(return) are small but fundamental changes to the core libraries.  I think there was a consensus (not universal in the case of BBP) that the change was good.  Yet AMP and BBP (esp) were controversial.  The issues were mostly around how to make the transition; and, given that the transition is expensive, whether the cost/benefit tradeoff justifies the change.  The question of moving ?return? out of Monad is in this category.


The Core Libraries Committee was formed explicitly to handle this stuff. So my prior assumption was that the CLC would handle the Monad(return) question, not Haskell Prime.



Mark?s suggestion of a ?stable? GHC 7.10 and a new GHC 8.0 is a reasonable one. But I for one would find it hard to promise to back-port every bug fix, especially as the two code bases diverge (which they will).



Here is another idea.  GHC knows very little about Monad.  It would take work, but it probably wouldn?t be impossible to make the same GHC work with two different ?base? libraries, each with a different definitions of the Monad class.  That would not solve the problem: you still could not use one library that used old Monad with another library that used new Monad.   But at least it?d decouple it from which version of GHC you were using.  I stress: it would take some work to make this go, and I?d prefer not to do this.

Returning to ?return?, my instinct is that when these pervasive breaking library changes come up, we should batch them into larger clumps.  The ?treadmill? complaint is real: small change A made me re-release my library; then small change B came along; and so on.  Perhaps if we saved them up this would be less of an issue, for two reasons.  First, the work happens once rather than many times.  Second, the benefits of the change is the sum of the benefits of the little component changes, and so is more attractive to library authors and library clients.

That line of thinking would suggest that the Core Libraries Committee might want to maintain a list of well-worked out agreed changes that are being ?saved up? for execution at some later date.

Simon



From: Haskell-Cafe [mailto:haskell-cafe-bounces at haskell.org] On Behalf Of Mike Meyer
Sent: 07 October 2015 00:24
To: Mark Lentczner; Johan Tibell
Cc: Haskell Libraries; haskell cafe; haskell-prime at haskell.org List
Subject: Re: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP (was: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`)

On Tue, Oct 6, 2015 at 4:15 PM Mark Lentczner <mark.lentczner at gmail.com<mailto:mark.lentczner at gmail.com>> wrote:

On Thu, Sep 24, 2015 at 2:43 PM, Herbert Valerio Riedel <hvr at gnu.org<mailto:hvr at gnu.org>> wrote:
TLDR: To complete the AMP, turn `Monad(return)` method into a
      top-level binding aliasing `Applicative(pure)`.

Sure... if we had a language that no one uses and could keep reforming like putty until it is perfect. But we don't.

A modest proposal:

We can't keep tinkering with a language and it's libraries like this AND have a growing ecosystem that serves an ever widening base, including the range from newcomer to commercial deployment. SO - Why let's do all the language tinkering in GHC 8 there can be as many prereleases of that as needed until it is just right. ...and leave GHC 7 (7.10? roll back to 7.8.4?) for all of us doing essential and dependable libraries, commercial work, projects on Haskell that we don't want to have to go back and #ifdefs to twice a year just to keep running, educators, people writing books. We can keep improving GHC 7 as needed, and focus on bugs, security issues, patches, cross compatibility, etc.

I'm just curious how much you think this would help, assuming that your solution would imply not upgrading to 8 until you're ready to. After all, you can already simply not upgrade now, and create (and distribute) fixes for bugs, security issues, cross-compatibility for 7 as you see fit.

While that's a popular thing to do in lots of systems (but if we don't it. for gnus sake let's not adopt the inane parity implies stability numbering convention), it leaves two major issues unaddressed.

#1, developer time. You need to get the people doing the work now to divide their efforts into the two branches.I don't know what percentage of that work is volunteer time, but I expect the answer is "most of it". If they aren't interested doing that now, what do you expect to change their mind?

#2, everything else in the ecosystem. If you need updates to a library that require the branch you're not using, where does that leave you?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151007/ea94d6a7/attachment-0001.html>

From greg at gregorycollins.net  Wed Oct  7 16:09:06 2015
From: greg at gregorycollins.net (Gregory Collins)
Date: Wed, 7 Oct 2015 09:09:06 -0700
Subject: [Haskell-cafe] MRP, 3-year-support-window, and the
 non-requirement of CPP
In-Reply-To: <etPan.56147308.2268a666.7b73@mbp.local>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 <87612k6j1v.fsf@gnu.org> <etPan.56147308.2268a666.7b73@mbp.local>
Message-ID: <CAHZrzdpig8R=W5T4SBRYwqCD_3W+wquYajOr-9qqcEd4f8gf1w@mail.gmail.com>

On Tue, Oct 6, 2015 at 6:18 PM, Gershom B <gershomb at gmail.com> wrote:


>
> With that in mind, I think the _concrete_ voices of concern have been the
> most useful. Gregory Collins? list of issues requiring CPP should be very
> sobering. Of note, I think they point to areas where the core libraries
> committee has not paid _enough_ attention (or perhaps has not been
> sufficiently empowered: recall that not all core libraries fall under its
> maintenance [2]). Things like the newtype FFI issue, the changes to prim
> functions, the splitup of old-time and the changes to exception code were
> _not_ vetted as closely as the AMP and FTP were, or as the MRP is currently
> being. I don?t know all the reasons for this, but I suspect they just
> somewhat slipped under the radar.


In fact, more often than I would like, I can recall arguing against a
particular change
<https://www.mail-archive.com/ghc-devs at haskell.org/msg02133.html> on the
grounds that it would break user code, and in Haskell land this is a battle
I usually lose. Usually the argument on the other side boils down to
expediency or hygiene/aesthetics -- it's *difficult* to engineer a change
to some core infra in a way that minimizes impact on people downstream, and
it takes a long time. Often "this change is going to cause a small amount
of work for all of my users" is something that seems to not be taken into
consideration at all.

For this particular proposal, every user will have some small amount of
work *w* to do (to read the change notes, understand why 'return' is going
away, train yourself to use "pure" now instead of "return" like you've been
using for 15 years, etc). It might feel like *w* is small and so the change
isn't burdensome, but *n* is literally everyone who uses the language, so
the total work *w***n* is going to amount to quite a few person-hours. I
just want to make sure that everyone is keeping that in mind and weighing
that effort against the benefits.

Outside of that, the most disruptive changes to my code that I can recall
> have been from changes to the aeson library over the years ? particularly
> but not only regarding its handling of doubles. I don?t begrudge these
> changes ? they iteratively arrived at a _much_ better library than had they
> not been made. [3] After than, I made a few changes regarding Happstack and
> Snap API changes if I recall. Additionally, the addition of ?die? to
> System.Exit caused a few name clashes. My point is simply that there are
> many packages outside of base that also move, and ?real? users with ?real?
> code will these days often have quite a chain of dependencies, and will
> encounter movement and change from across many of them. So if we say ?base
> never changes? that does not mean ?packages will never break? ? it just
> means that base will not have the same opportunity to improve that other
> packages do, which will eventually lead to frustration, just as it did in
> the past and in the leadup to the BBP.
>

Culturally, we have a problem with library authors of all stripes being too
cavalier about breaking user programs: we definitely lean towards "move
fast and break things" vs "stay stable and don't make work for users". As
you write more and more Haskell code, you depend on more and more of these
libraries, and this means that once you go beyond a certain threshold you
will be spending a significant amount of your time just running to keep up
with the treadmill. Personally I just don't have enough time for writing
Haskell code as I used to (or I would like), so I would say for me that the
treadmill tax is now probably exceeding 50% of my total hours invested.

Greg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151007/9f1c0f7c/attachment.html>

From hesselink at gmail.com  Wed Oct  7 16:38:01 2015
From: hesselink at gmail.com (Erik Hesselink)
Date: Wed, 7 Oct 2015 18:38:01 +0200
Subject: [Haskell-cafe] MRP, 3-year-support-window, and the
 non-requirement of CPP
In-Reply-To: <CAHZrzdpig8R=W5T4SBRYwqCD_3W+wquYajOr-9qqcEd4f8gf1w@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 <87612k6j1v.fsf@gnu.org> <etPan.56147308.2268a666.7b73@mbp.local>
 <CAHZrzdpig8R=W5T4SBRYwqCD_3W+wquYajOr-9qqcEd4f8gf1w@mail.gmail.com>
Message-ID: <CAPeieQG0-6AmNGEZLBg_Lqh5VJKwTtPFC3=iGV42ciJ=zO5xpg@mail.gmail.com>

On 7 October 2015 at 18:09, Gregory Collins <greg at gregorycollins.net> wrote:
> For this particular proposal, every user will have some small amount of work
> w to do (to read the change notes, understand why 'return' is going away,
> train yourself to use "pure" now instead of "return" like you've been using
> for 15 years, etc).

While I don't think it detracts from your argument, it seems you
misread the original proposal. At no point will it remove `return`
completely. It would be moved out of the `Monad` class and be made
into a top-level definition instead, so you would still be able to use
it.

Erik

From mark.lentczner at gmail.com  Wed Oct  7 21:13:02 2015
From: mark.lentczner at gmail.com (Mark Lentczner)
Date: Wed, 7 Oct 2015 22:13:02 +0100
Subject: [Haskell-cafe] MRP, 3-year-support-window, and the
 non-requirement of CPP
In-Reply-To: <CAPeieQG0-6AmNGEZLBg_Lqh5VJKwTtPFC3=iGV42ciJ=zO5xpg@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 <87612k6j1v.fsf@gnu.org> <etPan.56147308.2268a666.7b73@mbp.local>
 <CAHZrzdpig8R=W5T4SBRYwqCD_3W+wquYajOr-9qqcEd4f8gf1w@mail.gmail.com>
 <CAPeieQG0-6AmNGEZLBg_Lqh5VJKwTtPFC3=iGV42ciJ=zO5xpg@mail.gmail.com>
Message-ID: <CAAOoiFb3rqAzG4eH4jrwdors8OqDcTaQaZq7TJhBA5-VAsW8JQ@mail.gmail.com>

On Wed, Oct 7, 2015 at 9:38 AM, Erik Hesselink <hesselink at gmail.com> wrote:

> While I don't think it detracts from your argument, it seems you
> misread the original proposal. At no point will it remove `return`
> completely. It would be moved out of the `Monad` class and be made
> into a top-level definition instead, so you would still be able to use
> it.
>

Then why bother?
If you don't intend to regard code that uses "return" as old, out-dated, in
need of updating, etc....
If you don't intend to correct people on #haskell to use pure instead of
return...
If you don't tsk tsk all mentions of it in books....
If you don't intend to actually deprecate it.
Why bother?

But seriously, why do you think that "you would still be able to use it"?
That is true for only the simplest of code - and untrue for anyone who has
a library that defines a Monad - or anyone who has a library that they want
to keep "up to date". Do you really want to have a library where all your
"how to use this" code has return in the examples? Shouldn't now be pure?
Do I now need -XCPP just for Haddock? and my wiki page? And what gets shown
in Hackage? This is just a nightmare for a huge number of libraries, and
especially many commonly used ones.

Why bother!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151007/82a9d937/attachment.html>

From mark.lentczner at gmail.com  Wed Oct  7 21:24:58 2015
From: mark.lentczner at gmail.com (Mark Lentczner)
Date: Wed, 7 Oct 2015 22:24:58 +0100
Subject: Proposal: pare down traversable
In-Reply-To: <CAMgWh9tj=ohctbZg9-QwULZ8+69BzTeiO81oVnB9NMer9Eqiog@mail.gmail.com>
References: <CAMgWh9uAm-KXoJWOBYt5y6YT_v26iN7tD=3b8Qx+kSBy3L9LOQ@mail.gmail.com>
 <CAMgWh9sJ20Q8yures+PDLdGB1OAYn8icOEmDkg+kren-_hyLww@mail.gmail.com>
 <CAJumaK-PiLx6XNsqjMJ9XG9uSGGnV0m-SnBLhA=zprrV8zS3Xg@mail.gmail.com>
 <CAMgWh9t5Me1CLP3LvS-fvYJoQcHV2suirLGYmbWSckJwNoaB_w@mail.gmail.com>
 <5608E1DB.6030309@ro-che.info>
 <CAMgWh9tj=ohctbZg9-QwULZ8+69BzTeiO81oVnB9NMer9Eqiog@mail.gmail.com>
Message-ID: <CAAOoiFbRSTxzjD4uNKu9-yWuFkPV9VfWzKx7feVX2Gxma8ZEfg@mail.gmail.com>

On Mon, Sep 28, 2015 at 1:12 AM, David Feuer <david.feuer at gmail.com> wrote:

> Once the decision is made that something should go away, it seems generally
> best to get rid of it sooner rather than later.
>

This stance is what has so many of us upset with how things are going. It
is antithetical to maintenance of libraries and code bases.

The whole shebang, from FTP through MRP and whatever else you have up your
sleeves should NEVER have been foist piecemeal onto the current system. If
you really want those things - package them as a cohesive whole - find a
way to use them in your code bases for two years (alternate Prelude) -
prove they work, iron out the mistakes - THEN make a single large wholesale
change - probably along with a Haskell report.

Then existing code and libraries would then have to go through the burden -
but just once. One set of #ifdefs, perhaps one set of compatibility
packages, etc.

The current trickled out stream makes code maintenance - having to handle
all the intermediate steps - a real burden.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151007/a174e65f/attachment.html>

From targen at gmail.com  Wed Oct  7 22:42:09 2015
From: targen at gmail.com (=?UTF-8?Q?Manuel_G=C3=B3mez?=)
Date: Wed, 7 Oct 2015 18:12:09 -0430
Subject: [Haskell-cafe] MRP, 3-year-support-window, and the
 non-requirement of CPP
In-Reply-To: <CAAOoiFb3rqAzG4eH4jrwdors8OqDcTaQaZq7TJhBA5-VAsW8JQ@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 <87612k6j1v.fsf@gnu.org> <etPan.56147308.2268a666.7b73@mbp.local>
 <CAHZrzdpig8R=W5T4SBRYwqCD_3W+wquYajOr-9qqcEd4f8gf1w@mail.gmail.com>
 <CAPeieQG0-6AmNGEZLBg_Lqh5VJKwTtPFC3=iGV42ciJ=zO5xpg@mail.gmail.com>
 <CAAOoiFb3rqAzG4eH4jrwdors8OqDcTaQaZq7TJhBA5-VAsW8JQ@mail.gmail.com>
Message-ID: <CAJWnFaPvHOV4f_aUasg187ffBC=rZBdXMkBoXb5LewAckQuAzA@mail.gmail.com>

On Wed, Oct 7, 2015 at 4:43 PM, Mark Lentczner <mark.lentczner at gmail.com> wrote:
> If you don't intend to actually deprecate it.
> Why bother?
>
> But seriously, why do you think that "you would still be able to use it"?
> That is true for only the simplest of code - and untrue for anyone who has a
> library that defines a Monad - or anyone who has a library that they want to
> keep "up to date". Do you really want to have a library where all your "how
> to use this" code has return in the examples? Shouldn't now be pure? Do I
> now need -XCPP just for Haddock? and my wiki page? And what gets shown in
> Hackage? This is just a nightmare for a huge number of libraries, and
> especially many commonly used ones.
>
> Why bother!

This is explained in the original proposal.  In particular, it
eliminates opportunities for errors and simplifies ApplicativeDo.  I
don?t believe anyone has proposed removing return from base.  The only
proposed change is turning return into a stand-alone function instead
of a method in Monad.  There is no proposal for removing return.

From allbery.b at gmail.com  Wed Oct  7 23:05:44 2015
From: allbery.b at gmail.com (Brandon Allbery)
Date: Wed, 7 Oct 2015 19:05:44 -0400
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <mv40qe$qaa$1@ger.gmane.org>
References: <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca>
 <CAGcFDtjuOAd0M2AVRK8Cx3kG0AEAHZ_D7WR9Z9yOmZ6Lo7uYEw@mail.gmail.com>
 <CAHZrzdqPbv5OHzE8UEnxQ0_TXcmQbatJZC6g2mg9eBz1-SP_Dw@mail.gmail.com>
 <20151006203900.GT11050@weber>
 <CAHZrzdrkOs5oRwMEKcHKtiDtFk8is+x5ALuoeBvy8NTnRJU0_Q@mail.gmail.com>
 <CAK+ijdvbxW50-Q3-Vk5PaKyrCrsu7qLVvUzZ3K0iCSFR7h900g@mail.gmail.com>
 <mv40qe$qaa$1@ger.gmane.org>
Message-ID: <CAKFCL4UXSjPz+1prDG6hvrHFo_o-auV=M=f6=xVi0n_2p46fdw@mail.gmail.com>

On Wed, Oct 7, 2015 at 4:54 PM, Bardur Arantsson <spam at scientician.net>
wrote:

> Please consider that the the way practical development really happens[2]


...among web developers, who of course are the only real developers?

Have you considered that there are developers who are not web developers?
The past day has convinced me that the web devs have relegated everyone
else to fake-non-programmer status and actively want them out of the
community because fake programmers don't benefit you real programmers.

I had heard that the financial users generally refused to have anything to
do with the Haskell community.
Now I know why.

I wonder how many of them, if any indeed are left after past breaking
changes, are in the process of switching to OCaml. I'm sure you consider
that a good thing, because they're obviously just holding back "real
programmers".

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151007/ab960da1/attachment.html>

From mwm at mired.org  Wed Oct  7 23:39:19 2015
From: mwm at mired.org (Mike Meyer)
Date: Wed, 07 Oct 2015 23:39:19 +0000
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <CAKFCL4UXSjPz+1prDG6hvrHFo_o-auV=M=f6=xVi0n_2p46fdw@mail.gmail.com>
References: <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca>
 <CAGcFDtjuOAd0M2AVRK8Cx3kG0AEAHZ_D7WR9Z9yOmZ6Lo7uYEw@mail.gmail.com>
 <CAHZrzdqPbv5OHzE8UEnxQ0_TXcmQbatJZC6g2mg9eBz1-SP_Dw@mail.gmail.com>
 <20151006203900.GT11050@weber>
 <CAHZrzdrkOs5oRwMEKcHKtiDtFk8is+x5ALuoeBvy8NTnRJU0_Q@mail.gmail.com>
 <CAK+ijdvbxW50-Q3-Vk5PaKyrCrsu7qLVvUzZ3K0iCSFR7h900g@mail.gmail.com>
 <mv40qe$qaa$1@ger.gmane.org>
 <CAKFCL4UXSjPz+1prDG6hvrHFo_o-auV=M=f6=xVi0n_2p46fdw@mail.gmail.com>
Message-ID: <CAD=7U2CnbZHGmErQs7c34mEky4gP7E81YVyASE2Zk1HeNv8OQw@mail.gmail.com>

On Wed, Oct 7, 2015 at 6:05 PM Brandon Allbery <allbery.b at gmail.com> wrote:

> On Wed, Oct 7, 2015 at 4:54 PM, Bardur Arantsson <spam at scientician.net>
> wrote:
>
>> Please consider that the the way practical development really happens[2]
>
> ...among web developers, who of course are the only real developers?
> [...]
> I had heard that the financial users generally refused to have anything to
> do with the Haskell community.
> Now I know why.
>

I'm curious - do "practical" developers really feel like they have to rush
out and update their tool chain whenever a new version of part of it comes
out? Most of the projects I've worked on considered the language version as
a fixed part of the technology stack, and almost never updated it. Even
when using Python, which valued not breaking working code more than it's
own zen. But changing anything that potentially affected all the code in a
working project was pretty much never done, and always involved a lot of
effort.

So the worst headache I got from language evolution was from trying to
remember which set of features I had available for each project. No, that's
second - the biggest one was from arguments about when we should adopt a
new version. But breaking working code pretty much didn't happen.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151007/7e48b8c3/attachment.html>

From spam at scientician.net  Thu Oct  8 00:02:58 2015
From: spam at scientician.net (Bardur Arantsson)
Date: Thu, 8 Oct 2015 02:02:58 +0200
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <CAD=7U2CnbZHGmErQs7c34mEky4gP7E81YVyASE2Zk1HeNv8OQw@mail.gmail.com>
References: <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca>
 <CAGcFDtjuOAd0M2AVRK8Cx3kG0AEAHZ_D7WR9Z9yOmZ6Lo7uYEw@mail.gmail.com>
 <CAHZrzdqPbv5OHzE8UEnxQ0_TXcmQbatJZC6g2mg9eBz1-SP_Dw@mail.gmail.com>
 <20151006203900.GT11050@weber>
 <CAHZrzdrkOs5oRwMEKcHKtiDtFk8is+x5ALuoeBvy8NTnRJU0_Q@mail.gmail.com>
 <CAK+ijdvbxW50-Q3-Vk5PaKyrCrsu7qLVvUzZ3K0iCSFR7h900g@mail.gmail.com>
 <mv40qe$qaa$1@ger.gmane.org>
 <CAKFCL4UXSjPz+1prDG6hvrHFo_o-auV=M=f6=xVi0n_2p46fdw@mail.gmail.com>
 <CAD=7U2CnbZHGmErQs7c34mEky4gP7E81YVyASE2Zk1HeNv8OQw@mail.gmail.com>
Message-ID: <mv4bri$ke0$1@ger.gmane.org>

On 10/08/2015 01:39 AM, Mike Meyer wrote:
> On Wed, Oct 7, 2015 at 6:05 PM Brandon Allbery <allbery.b at gmail.com> wrote:
> 
>> On Wed, Oct 7, 2015 at 4:54 PM, Bardur Arantsson <spam at scientician.net>
>> wrote:
>>
>>> Please consider that the the way practical development really happens[2]
>>
>> ...among web developers, who of course are the only real developers?
>> [...]
>> I had heard that the financial users generally refused to have anything to
>> do with the Haskell community.
>> Now I know why.
>>
> 
> I'm curious - do "practical" developers really feel like they have to rush
> out and update their tool chain whenever a new version of part of it comes
> out? Most of the projects I've worked on considered the language version as
> a fixed part of the technology stack, and almost never updated it. Even
> when using Python, which valued not breaking working code more than it's
> own zen. But changing anything that potentially affected all the code in a
> working project was pretty much never done, and always involved a lot of
> effort.
> 
> So the worst headache I got from language evolution was from trying to
> remember which set of features I had available for each project. No, that's
> second - the biggest one was from arguments about when we should adopt a
> new version. But breaking working code pretty much didn't happen.
> 

+1, that's an excellent point well made.

I have been in this situation and it was certainly frustrating *as a
developer*, but it pretty much works for most businesses.

Regards,


From ky3 at atamo.com  Thu Oct  8 03:04:14 2015
From: ky3 at atamo.com (Kim-Ee Yeoh)
Date: Thu, 8 Oct 2015 10:04:14 +0700
Subject: Proposal: pare down traversable
In-Reply-To: <CAAOoiFbRSTxzjD4uNKu9-yWuFkPV9VfWzKx7feVX2Gxma8ZEfg@mail.gmail.com>
References: <CAMgWh9uAm-KXoJWOBYt5y6YT_v26iN7tD=3b8Qx+kSBy3L9LOQ@mail.gmail.com>
 <CAMgWh9sJ20Q8yures+PDLdGB1OAYn8icOEmDkg+kren-_hyLww@mail.gmail.com>
 <CAJumaK-PiLx6XNsqjMJ9XG9uSGGnV0m-SnBLhA=zprrV8zS3Xg@mail.gmail.com>
 <CAMgWh9t5Me1CLP3LvS-fvYJoQcHV2suirLGYmbWSckJwNoaB_w@mail.gmail.com>
 <5608E1DB.6030309@ro-che.info>
 <CAMgWh9tj=ohctbZg9-QwULZ8+69BzTeiO81oVnB9NMer9Eqiog@mail.gmail.com>
 <CAAOoiFbRSTxzjD4uNKu9-yWuFkPV9VfWzKx7feVX2Gxma8ZEfg@mail.gmail.com>
Message-ID: <CAPY+ZdS=_L7U0m_ZTwcqX30CU008MZ4OO0hOsR0NpCfeWSrZ4A@mail.gmail.com>

On Thu, Oct 8, 2015 at 4:24 AM, Mark Lentczner <mark.lentczner at gmail.com>
wrote:

> The whole shebang, from FTP through MRP and whatever else you have up your
> sleeves should NEVER have been foist piecemeal onto the current system. If
> you really want those things - package them as a cohesive whole - find a
> way to use them in your code bases for two years (alternate Prelude) -
> prove they work, iron out the mistakes - THEN make a single large wholesale
> change - probably along with a Haskell report.


I agree with Mark that FTP (seen in the light of MRP) is incomplete and
piecemeal. The half-baked nature already causes productivity losses, see

https://ghc.haskell.org/trac/ghc/ticket/10830

Otoh, I doubt that David is singularly to blame for this ("whatever else
you have up your sleeves") nor are his intentions, like many a derring-do
haskeller's, any less than sincere in wanting to improve things.

Thing is, a new Haskell report sounds terribly onerous and folks make it
easy on themselves to make the changes they want to see. A new Haskell
report seems to require tremendous ounces of foresight, focus, and
conviviality among stakeholders to pull it off.

-- Kim-Ee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151008/cf694a85/attachment.html>

From hvr at gnu.org  Thu Oct  8 12:24:16 2015
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Thu, 08 Oct 2015 14:24:16 +0200
Subject: status and future of haskell98 and haskell2010 packages
In-Reply-To: <561597EB.8020906@gmail.com> (Andrey Chudnov's message of "Wed, 7
 Oct 2015 18:08:43 -0400")
References: <561597EB.8020906@gmail.com>
Message-ID: <87egh57dlb.fsf@gnu.org>

On 2015-10-08 at 00:08:43 +0200, Andrey Chudnov wrote:
> My e-mail was rejected from libraries at haskell.org (the official
> maintenance contact of the two packages in question), so I'm trying my
> luck here instead. Hoping I can get some answers on the following
> questions:
>
> 1. What is the status of `haskell2010` and `haskell98` packages? Are
> they supported? Deprecated? In need of new maintainers?

Short answer: with GHC 7.10 it is not possible anymore to implement a
proper[1] `haskell98` or `haskell2010` package anymore.

More details can be found at https://ghc.haskell.org/ticket/9590

> 2. Assuming the answer to the previous question is "alive and well",
> are there any plans to release new versions of those for GHC 7.10 and
> beyond?

In order to be able to recover support for a `haskell2010` package in
newer GHCs, GHC will need to be extended in some way. I can think of two
different paths to pursue to accomplish this, depending on whether
type(classes) need to be shared with `base` or not. Moreover, it wasn't
clear how much actual demand there really is to have the recent GHCs
support a legacy `haskell2010` mode.

So if there's somebody interested in resuscitating a
`haskell98`/`haskell2010` package, please tell us what your use-case is
(to help understand whether type(class) sharing w/ `base` is essential
or not -- it's *much* more easier to get this working w/o the typeclass
sharing requirement, whereas the typeclass-sharing variant might not
even be possible at all)


Cheers,
   hvr

 [1]: I.e. with the requirement that all code written conforming to the
      respective Haskell Report will be compileable via e.g.

      ghc -XHaskell2010 -hide-all-packages -package haskell2010 -c *.hs

      (to some degree, this was already broken before GHC 7.10
      due to the superclass-removal on `Num`, but with AMP this was
      broken beyond tolerance)

From jules at jellybean.co.uk  Fri Oct  9 07:37:14 2015
From: jules at jellybean.co.uk (Julian Bean)
Date: Fri, 9 Oct 2015 08:37:14 +0100
Subject: [containers] Proposal: Change to the Data.Map Monoid
In-Reply-To: <CAFXb89DUKqSGSd3M1guo3WxedwSpJTJPKX_uP=P3Yt1EzmrvqQ@mail.gmail.com>
References: <CAFXb89DUKqSGSd3M1guo3WxedwSpJTJPKX_uP=P3Yt1EzmrvqQ@mail.gmail.com>
Message-ID: <9A29E611-B2AA-4A04-8AE7-C4B44B7645E1@jellybean.co.uk>

Apologies for digging out an 18 month old post, but it shows some context.

In fact this proposal was made in 2012, resurrected in 2013, and re-made in 2014. Each time it has been defeated because it would break too much code to change it now.

Would there be any downside to providing a package with a newtyped Map with all operations ported over? The newtype already exists in semigroups as UnionWith (Map k) v; what is missing is the entire Map API.

Now that we have Data.Coerce (which we didn?t have at least the first time this was discussed) I believe I?m right in saying that you can basically patch the API over as:

module Data.MonoidMap.Strict where {
import qualified Data.Map.Strict as MS
import Data.Semigroup.Union

type Map k v = UnionWith (MS.Map k) v

? I don?t know if we need to use {-# INLINE #-} here or fully saturate singleton to get inlining to work
singleton :: k -> a -> Map k a
singleton = coerce MS.singleton

insert :: Ord k => k -> a -> Map k a -> Map k a
insert = coerce MS.insert
?.
}

which is entirely mechanical (and can presumably be automated). Do the same for Lazy of course. And also for HashMap.

Add the correct Monoid instance (presumably using Semigroup since we have that as a dependency anyway). We can export also

fromMap :: Data.Map.Strict.Map k v -> Data.MonoidMap.Strict.Map k v
fromMap = coerce

and the reverse.

then legacy code is entirely unharmed, but new code which wishes to use the ?correct? instance of Monoid has a package to import to use it, and it is relatively easy to co-exist with existing code using the old type, with an O(1) conversion function.

To be clear - this isn?t a library proposal, because it?s a proposal for a new package which will depend on containers and semigroups. However it is a suggestion of how we can solve the problem of Map having the wrong Monoid instance and not have to live with the problems forever. Who knows, one day in the future semigroups might be in base.

Jules


On 19 May 2014, at 01:05, Nick Partridge <nkpart at gmail.com> wrote:

> Hi, 
> 
> Currently the Monoid instance for Data.Map is implemented using union/unions, which are left biased. On key collision, it discards values from the right hand side of `mappend` - https://github.com/ghc/packages-containers/blob/bae098fb0a3994bc2b0ec3313004b40cd097ed8d/Data/Map/Base.hs#L341-L344
> 
> If you compare this with the Monoid for Maybe, it's like we're defaulting to First as the monoid instance for maps.
> 
> A more useful instance, however very much a breaking change, would be to make the instance depend on a Monoid (or better yet, a Semigroup) for the values in the map:
> 
> instance Monoid v => Monoid (Map k v) where
>     mappend = unionWith mappend
> 
> This lets us build up maps with values in a useful Monoid, and mappend them with gusto. 
> 
> Thoughts?
> 
> - Nick Partridge
> 
> Discussion period: 2 weeks.
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151009/018b73af/attachment.html>

From jules at jellybean.co.uk  Fri Oct  9 07:40:36 2015
From: jules at jellybean.co.uk (Julian Bean)
Date: Fri, 9 Oct 2015 08:40:36 +0100
Subject: [containers] Proposal: Change to the Data.Map Monoid
In-Reply-To: <9A29E611-B2AA-4A04-8AE7-C4B44B7645E1@jellybean.co.uk>
References: <CAFXb89DUKqSGSd3M1guo3WxedwSpJTJPKX_uP=P3Yt1EzmrvqQ@mail.gmail.com>
 <9A29E611-B2AA-4A04-8AE7-C4B44B7645E1@jellybean.co.uk>
Message-ID: <689D6FD7-835E-4ACF-824B-4A96801D505B@jellybean.co.uk>


On 9 Oct 2015, at 08:37, Julian Bean <jules at jellybean.co.uk> wrote:

> 
> Would there be any downside to providing a package with a newtyped Map with all operations ported over? The newtype already exists in semigroups as UnionWith (Map k) v; what is missing is the entire Map API.
> 

Correction. The newtype exists in the package ?reducers? not ?semigroups?.




From ivan.miljenovic at gmail.com  Sat Oct 10 00:58:46 2015
From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic)
Date: Sat, 10 Oct 2015 11:58:46 +1100
Subject: ANNOUNCE: unordered-graphs
Message-ID: <CA+u6gbyp2A0sXBPADqzWtJDsiiEoekrX8HHdhY+cyjVkgViQ4g@mail.gmail.com>

I have a relatively hacked-together graph library that uses
unordered-containers as a backend available if anyone finds it
interesting/useful:
http://hackage.haskell.org/package/unordered-graphs

It's primarily developed just for my own needs and thus I'm not sure
how much future work I'll be doing on it, but I'm willing to accept
pull requests.

This library was semi-experimental in that I also tried a few things
out with it:

* Polymorphic node type

* Fixed auto-generated edge type: this is because (node,node, label)
triples (ala fgl) do not provide sufficient information to be able to
distinguish between multiple edges, etc.

* Type parameter to determine whether the graph is directed or undirected.

* Typeclass to allow you to determine the type/output of a a match (I
didn't end up actually using this, as the one time I needed to do a
match I found the extra polymorphism caused problems; it also isn't
comprehensive as I didn't write all that many instances.)

-- 
Ivan Lazar Miljenovic
Ivan.Miljenovic at gmail.com
http://IvanMiljenovic.wordpress.com

From ekmett at gmail.com  Sat Oct 10 19:13:26 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Sat, 10 Oct 2015 15:13:26 -0400
Subject: [Haskell-cafe] MRP, 3-year-support-window, and the
 non-requirement of CPP
In-Reply-To: <F351956E-517E-4387-A3E5-29968ADB5ACA@me.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 <87612k6j1v.fsf@gnu.org>
 <F351956E-517E-4387-A3E5-29968ADB5ACA@me.com>
Message-ID: <CAJumaK_ayJ=Xpj_pzKv5sk_G3MncAB9FQEjL4=-9ieMC6LfwDA@mail.gmail.com>

On Tue, Oct 6, 2015 at 3:02 PM, Malcolm Wallace <malcolm.wallace at me.com>
wrote:

>
> On 6 Oct 2015, at 17:47, Herbert Valerio Riedel wrote:
> > At the risk of stating the obvious: I don't think it matters from which
> > group a given argument comes from as its validity doesn't depend on the
> > messenger.
>
> In that case, I think you are misunderstanding the relevance of Johan's
> argument here.  Let me try to phrase it differently.  Some people who can
> reasonably claim to have experience with million-line plus codebases are
> warning that this change is too disruptive, and makes maintenance harder
> than it ought to be.  On the other hand, of the people who say the change
> is not really disruptive, none of them have (yet?) made claims to have
> experience of the maintenance of extremely large-scale codebases.


Very well. Let me offer a view from the "other side of the fence."

I personally maintain about 1.3 million lines of Haskell, and over 120
packages on hackage. It took me less than a half a day to get everything
running with 7.10, and about two days to build -Wall clean. In that first
day I actually had to spend vastly more time fixing things related to
changes in Typeable, template-haskell and a tweaked corner case in the
typechecker than anything AMP/FTP related. In the end I had to add two type
signatures.

Most of the patches to go -Wall clean looked like

+#if __GLASGOW_HASKELL__ < 710
import Control.Applicative
import Data.Monoid
+#endif

Maybe 10% were more complicated.

-Edward
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151010/1ac84541/attachment.html>

From ekmett at gmail.com  Sat Oct 10 19:16:10 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Sat, 10 Oct 2015 15:16:10 -0400
Subject: [Haskell-cafe] MRP, 3-year-support-window, and the
 non-requirement of CPP
In-Reply-To: <87lhbfm8qu.fsf@gnu.org>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 <87612k6j1v.fsf@gnu.org>
 <CANBN=mu_un8bJR3eCSMmpoXpL3_Mu-wsgdnZ+ZOiUGP-j4RWmw@mail.gmail.com>
 <87lhbfm8qu.fsf@gnu.org>
Message-ID: <CAJumaK-d-uJP6BEmpZTiNmnAtzB=Vaz7nUX6S_5qNT-B02DYLQ@mail.gmail.com>

On Wed, Oct 7, 2015 at 3:35 AM, Herbert Valerio Riedel <hvr at gnu.org> wrote:

> --8<---------------cut here---------------start------------->8---
> import Control.Applicative as A (Applicative(..))
>
> data Maybe' a = Nothing' | Just' a
>
> instance Functor Maybe' where
>     fmap f (Just' v) = Just' (f v)
>     fmap _ Nothing'  = Nothing'
>
> instance A.Applicative Maybe' where
>     pure = Just'
>     f1 <*> f2   = f1 >>= \v1 -> f2 >>= (pure . v1)
>
> instance Monad Maybe' where
>     Nothing' >>= _  = Nothing'
>     Just' x  >>= f  = f x
>
>     return = pure -- "deprecated" since GHC 7.10
> --8<---------------cut here---------------end--------------->8---
>
>
Alternately,

import Control.Applicative
import Prelude

data Maybe' a = Nothing' | Just' a

instance Functor Maybe' where
    fmap f (Just' v) = Just' (f v)
    fmap _ Nothing'  = Nothing'

instance Applicative Maybe' where



> -- hvr
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151010/14bf5791/attachment.html>

From ekmett at gmail.com  Sat Oct 10 19:25:37 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Sat, 10 Oct 2015 15:25:37 -0400
Subject: [Haskell-cafe] MRP, 3-year-support-window, and the
 non-requirement of CPP
In-Reply-To: <CAAOoiFb3rqAzG4eH4jrwdors8OqDcTaQaZq7TJhBA5-VAsW8JQ@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 <87612k6j1v.fsf@gnu.org> <etPan.56147308.2268a666.7b73@mbp.local>
 <CAHZrzdpig8R=W5T4SBRYwqCD_3W+wquYajOr-9qqcEd4f8gf1w@mail.gmail.com>
 <CAPeieQG0-6AmNGEZLBg_Lqh5VJKwTtPFC3=iGV42ciJ=zO5xpg@mail.gmail.com>
 <CAAOoiFb3rqAzG4eH4jrwdors8OqDcTaQaZq7TJhBA5-VAsW8JQ@mail.gmail.com>
Message-ID: <CAJumaK8WDbNfkFOKZPv9dDZqEiyB6ms2wJC9KK0sVv-CWPjqmQ@mail.gmail.com>

The part of the MRP proposal that I actively care about because it fixes a
situation that *actually causes harm* is moving (>>) to the top level.

Why?

Right now (*>) and (>>) have different default definitions. This means that
code runs often with different asymptotics depending on which one you pick.
Folks often define one but not the other.

This means that the performance of mapM_ and traverse_ needlessly differ.
It means that we can't simply weaken the type constraint on mapM_ and
sequence_ to Applicative, it as a knock-on consequence it means we can't
migrate mapM and sequence out of Traversable to top level definitions and
thereby simply provide folks with more efficient parallelizable mapping
when they reach for the 'obvious tool'.

return itself lurking in the class doesn't matter to me all that much as it
doesn't break anybody's asymptotics and it already has a sensible
definition in terms of pure as a default, so effectively you can write code
as if MRP was already in effect today. It is a wart, but one that could be
burned off on however long a time table we want if we choose to proceed.

-Edward

On Wed, Oct 7, 2015 at 5:13 PM, Mark Lentczner <mark.lentczner at gmail.com>
wrote:

>
> On Wed, Oct 7, 2015 at 9:38 AM, Erik Hesselink <hesselink at gmail.com>
> wrote:
>
>> While I don't think it detracts from your argument, it seems you
>> misread the original proposal. At no point will it remove `return`
>> completely. It would be moved out of the `Monad` class and be made
>> into a top-level definition instead, so you would still be able to use
>> it.
>>
>
> Then why bother?
> If you don't intend to regard code that uses "return" as old, out-dated,
> in need of updating, etc....
> If you don't intend to correct people on #haskell to use pure instead of
> return...
> If you don't tsk tsk all mentions of it in books....
> If you don't intend to actually deprecate it.
> Why bother?
>
> But seriously, why do you think that "you would still be able to use it"?
> That is true for only the simplest of code - and untrue for anyone who has
> a library that defines a Monad - or anyone who has a library that they want
> to keep "up to date". Do you really want to have a library where all your
> "how to use this" code has return in the examples? Shouldn't now be pure?
> Do I now need -XCPP just for Haddock? and my wiki page? And what gets shown
> in Hackage? This is just a nightmare for a huge number of libraries, and
> especially many commonly used ones.
>
> Why bother!
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151010/298019f3/attachment.html>

From ekmett at gmail.com  Sat Oct 10 19:33:37 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Sat, 10 Oct 2015 15:33:37 -0400
Subject: [Haskell-cafe] MRP, 3-year-support-window, and the
 non-requirement of CPP
In-Reply-To: <CANBN=mu_un8bJR3eCSMmpoXpL3_Mu-wsgdnZ+ZOiUGP-j4RWmw@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 <87612k6j1v.fsf@gnu.org>
 <CANBN=mu_un8bJR3eCSMmpoXpL3_Mu-wsgdnZ+ZOiUGP-j4RWmw@mail.gmail.com>
Message-ID: <CAJumaK8E7-76L6Pd59uv=JnjsjrJOP=yTAYojtdZV3X3jgO55g@mail.gmail.com>

On Tue, Oct 6, 2015 at 1:41 PM, Sven Panne <svenpanne at gmail.com> wrote:

> 2015-10-06 18:47 GMT+02:00 Herbert Valerio Riedel <hvr at gnu.org>:
>
>> [...] That's because -Wall-hygiene (w/o opting out of harmless) warnings
>>
> across multiple GHC versions is not considered a show-stopper.
>>
>
> That's your personal POV, I'm more leaning towards "-Wall -Werror". I've
> seen too many projects where neglecting warning over an extended period of
> time made fixing them basically impossible at the end. Anyway, I think that
> a sane ecosystem should allow *both* POVs, the sloppy one and the strict
> one.
>

Note: You haven't been able to upload a package that has -Werror turned on
in the cabal file for a couple of years now -- even if it is only turned on
on the test suite, so any -Werror discipline you choose to enforce is
purely local.

-Edward
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151010/33007ac3/attachment-0001.html>

From ekmett at gmail.com  Sat Oct 10 19:36:44 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Sat, 10 Oct 2015 15:36:44 -0400
Subject: [containers] Proposal: Change to the Data.Map Monoid
In-Reply-To: <9A29E611-B2AA-4A04-8AE7-C4B44B7645E1@jellybean.co.uk>
References: <CAFXb89DUKqSGSd3M1guo3WxedwSpJTJPKX_uP=P3Yt1EzmrvqQ@mail.gmail.com>
 <9A29E611-B2AA-4A04-8AE7-C4B44B7645E1@jellybean.co.uk>
Message-ID: <CAJumaK-AqSiT3h=q4JtmwsL2rxyafLPFrGvAcxYr6bBhhXLCKw@mail.gmail.com>

On Fri, Oct 9, 2015 at 3:37 AM, Julian Bean <jules at jellybean.co.uk> wrote:

> Apologies for digging out an 18 month old post, but it shows some context.
>
> In fact this proposal was made in 2012, resurrected in 2013, and re-made
> in 2014. Each time it has been defeated because it would break too much
> code to change it now.
>
> Would there be any downside to providing a package with a newtyped Map
> with all operations ported over? The newtype already exists in semigroups
> as UnionWith (Map k) v; what is missing is the entire Map API.
>

No downside at all. This is a package you could write and use today.

To be clear - this isn?t a library proposal, because it?s a proposal for a
> new package which will depend on containers and semigroups. However it is a
> suggestion of how we can solve the problem of Map having the wrong Monoid
> instance and not have to live with the problems forever. Who knows, one day
> in the future semigroups might be in base.
>

https://ghc.haskell.org/trac/ghc/ticket/10365

-Edward
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151010/45f9fc70/attachment.html>

From shumovichy at gmail.com  Sat Oct 10 20:12:11 2015
From: shumovichy at gmail.com (Yuras Shumovich)
Date: Sat, 10 Oct 2015 23:12:11 +0300
Subject: [Haskell-cafe] MRP, 3-year-support-window, and the
 non-requirement of CPP
In-Reply-To: <CAJumaK8WDbNfkFOKZPv9dDZqEiyB6ms2wJC9KK0sVv-CWPjqmQ@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 <87612k6j1v.fsf@gnu.org> <etPan.56147308.2268a666.7b73@mbp.local>
 <CAHZrzdpig8R=W5T4SBRYwqCD_3W+wquYajOr-9qqcEd4f8gf1w@mail.gmail.com>
 <CAPeieQG0-6AmNGEZLBg_Lqh5VJKwTtPFC3=iGV42ciJ=zO5xpg@mail.gmail.com>
 <CAAOoiFb3rqAzG4eH4jrwdors8OqDcTaQaZq7TJhBA5-VAsW8JQ@mail.gmail.com>
 <CAJumaK8WDbNfkFOKZPv9dDZqEiyB6ms2wJC9KK0sVv-CWPjqmQ@mail.gmail.com>
Message-ID: <1444507931.2047.14.camel@gmail.com>

On Sat, 2015-10-10 at 15:25 -0400, Edward Kmett wrote:
> The part of the MRP proposal that I actively care about because it
> fixes a
> situation that *actually causes harm* is moving (>>) to the top
> level.

Sorry if I'm missing something, but moving (>>) is not part of the
proposal. At least it is not mentioned on the wiki page:

https://ghc.haskell.org/trac/ghc/wiki/Proposal/MonadOfNoReturn

Is the wiki outdated?

> return itself lurking in the class doesn't matter to me all that much
> as it
> doesn't break anybody's asymptotics and it already has a sensible
> definition in terms of pure as a default, so effectively you can
> write code
> as if MRP was already in effect today. It is a wart, but one that
> could be
> burned off on however long a time table we want if we choose to
> proceed.

So the cost of not moving `return` to the top level is zero?

For me the cost of moving it is pretty small, just an hour or two.
Probably recompiling all the dependencies when switching to newer
version of GHC will take longer. (Actually I'm still using 7.8 at
work.) But the cost is definitely nonzero.

The proposal (as written on the wiki page) provides two arguments for
the change:

There is no reason to include `return` into the next standard. That is
true. But we can leave `return` is `GHC` as a compiler specific
extension for backward compatibility, can't we?

The second argument is `ApplicativeDo`, but I don't see the point.
Breaking existing code "in order to benefit existing code" looks a bit
strange.

Could someone please clarify what is the cost of not moving `return`
out of `Monad`?

Sorry if it is already answered somewhere else, it is hard to find
anything in such the huge email thread.

Thanks,
Yuras.


From ekmett at gmail.com  Sat Oct 10 20:39:10 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Sat, 10 Oct 2015 16:39:10 -0400
Subject: [Haskell-cafe] MRP, 3-year-support-window, and the
 non-requirement of CPP
In-Reply-To: <1444507931.2047.14.camel@gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 <87612k6j1v.fsf@gnu.org> <etPan.56147308.2268a666.7b73@mbp.local>
 <CAHZrzdpig8R=W5T4SBRYwqCD_3W+wquYajOr-9qqcEd4f8gf1w@mail.gmail.com>
 <CAPeieQG0-6AmNGEZLBg_Lqh5VJKwTtPFC3=iGV42ciJ=zO5xpg@mail.gmail.com>
 <CAAOoiFb3rqAzG4eH4jrwdors8OqDcTaQaZq7TJhBA5-VAsW8JQ@mail.gmail.com>
 <CAJumaK8WDbNfkFOKZPv9dDZqEiyB6ms2wJC9KK0sVv-CWPjqmQ@mail.gmail.com>
 <1444507931.2047.14.camel@gmail.com>
Message-ID: <CAJumaK_8k0jzTKprOSAoj8xQPvGRMNSSCsabKgowOo5+cFu97A@mail.gmail.com>

On Sat, Oct 10, 2015 at 4:12 PM, Yuras Shumovich <shumovichy at gmail.com>
wrote:

> On Sat, 2015-10-10 at 15:25 -0400, Edward Kmett wrote:
> > The part of the MRP proposal that I actively care about because it
> > fixes a
> > situation that *actually causes harm* is moving (>>) to the top
> > level.
>
> Sorry if I'm missing something, but moving (>>) is not part of the
> proposal. At least it is not mentioned on the wiki page:
>
> https://ghc.haskell.org/trac/ghc/wiki/Proposal/MonadOfNoReturn
>
> Is the wiki outdated?
>

It arose during the original thread discussing the MRP but wasn't included
in the 'proposal as written' that was sent out.

https://mail.haskell.org/pipermail/libraries/2015-September/026129.html

In many ways that proposal would do better 'on its own' than as part of the
MRP.

> return itself lurking in the class doesn't matter to me all that much
> > as it
> > doesn't break anybody's asymptotics and it already has a sensible
> > definition in terms of pure as a default, so effectively you can
> > write code
> > as if MRP was already in effect today. It is a wart, but one that
> > could be
> > burned off on however long a time table we want if we choose to
> > proceed.
>
> So the cost of not moving `return` to the top level is zero?
>
> For me the cost of moving it is pretty small, just an hour or two.
> Probably recompiling all the dependencies when switching to newer
> version of GHC will take longer. (Actually I'm still using 7.8 at
> work.) But the cost is definitely nonzero.
>
> The proposal (as written on the wiki page) provides two arguments for
> the change:
>
> There is no reason to include `return` into the next standard. That is
> true.


Nobody is saying that we should remove return from the language. The
proposal was to move it out of the class -- eventually. Potentially on a
very very long time line.

But we can leave `return` is `GHC` as a compiler specific extension for
> backward compatibility, can't we?
>

This is effectively the status quo. There is a default definition of return
in terms of pure today. The longer we wait the more tenable this proposal
gets in many ways as fewer and fewer people start trying to support
compilers versions below 7.10. Today isn't that day.

There are some niggling corner cases around viewing its continued existence
as a compiler "extension" though, even just around the behavior when you
import the class with Monad(..) you get more or less than you'd expect.

Could someone please clarify what is the cost of not moving `return` out of
> `Monad`?
>

The cost of doing nothing is maintaining a completely redundant member
inside the class for all time and an ever-so-slightly more expensive
dictionaries for Monad, so retaining return in the class does no real harm
operationally.

While I'm personally somewhat in favor of its eventual migration on
correctness grounds and believe it'd be nice to be able to justify the
state of the world as more than a series of historical accidents when I put
on my libraries committee hat I have concerns.

I'm inclined to say at the least that IF we do decide to proceed on this,
at least the return component should be on a long time horizon, with a
clock tied to the release of a standard, say a Haskell2020. I stress IF,
because I haven't had a chance to go through and do any sort of detailed
tally or poll to get a sense of if there is a sufficient mandate. There is
enough of a ruckus being raised that it is worth proceeding cautiously if
we proceed at all.

-Edward
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151010/90bc7458/attachment.html>

From shumovichy at gmail.com  Sun Oct 11 09:49:39 2015
From: shumovichy at gmail.com (Yuras Shumovich)
Date: Sun, 11 Oct 2015 12:49:39 +0300
Subject: [Haskell-cafe] MRP, 3-year-support-window, and the
 non-requirement of CPP
In-Reply-To: <CAJumaK_8k0jzTKprOSAoj8xQPvGRMNSSCsabKgowOo5+cFu97A@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <etPan.561292df.6eacb1b6.7b73@mbp.local>
 <CAHZrzdrcPVG8F4WNqwGYCaYTUCL2JPKCfdUGBEQz_REpm9DVZw@mail.gmail.com>
 <CAK-tuPaOjE-ZWj--DAEMA92Eo8aSWX2-VTy601L52UyKfqzY-A@mail.gmail.com>
 <87zizw8obv.fsf_-_@gnu.org>
 <CAK-tuPao5Y2BYP=4Q95okrbxGzX55mBc=eADndELm98kqJ9b9w@mail.gmail.com>
 <87612k6j1v.fsf@gnu.org> <etPan.56147308.2268a666.7b73@mbp.local>
 <CAHZrzdpig8R=W5T4SBRYwqCD_3W+wquYajOr-9qqcEd4f8gf1w@mail.gmail.com>
 <CAPeieQG0-6AmNGEZLBg_Lqh5VJKwTtPFC3=iGV42ciJ=zO5xpg@mail.gmail.com>
 <CAAOoiFb3rqAzG4eH4jrwdors8OqDcTaQaZq7TJhBA5-VAsW8JQ@mail.gmail.com>
 <CAJumaK8WDbNfkFOKZPv9dDZqEiyB6ms2wJC9KK0sVv-CWPjqmQ@mail.gmail.com>
 <1444507931.2047.14.camel@gmail.com>
 <CAJumaK_8k0jzTKprOSAoj8xQPvGRMNSSCsabKgowOo5+cFu97A@mail.gmail.com>
Message-ID: <1444556979.2047.27.camel@gmail.com>

On Sat, 2015-10-10 at 16:39 -0400, Edward Kmett wrote:
> On Sat, Oct 10, 2015 at 4:12 PM, Yuras Shumovich <
> shumovichy at gmail.com>
> wrote:
> 
> > There is no reason to include `return` into the next standard. That
> > is
> > true.
> 
> 
> Nobody is saying that we should remove return from the language. The
> proposal was to move it out of the class -- eventually. Potentially
> on a
> very very long time line.

Yes, I meant there were no reason to include `return` into `Monad`
class in the next standard.


> There are some niggling corner cases around viewing its continued
> existence
> as a compiler "extension" though, even just around the behavior when
> you
> import the class with Monad(..) you get more or less than you'd
> expect.

Indeed that is a good argument.


> The cost of doing nothing is maintaining a completely redundant
> member
> inside the class for all time 

Well, it is just a single line of code. Of course, as any other
technical dept, it can beat you later, e.g. it can make some other
modification harder. But in the worst case it will cost one more
deprecation circle.


> and an ever-so-slightly more expensive
> dictionaries for Monad

Do you mean that moving `return` to the top level will give us
noticeable performance improvement?


> so retaining return in the class does no real harm
> operationally.

IMO that is the reason for the "ruckus".


Thank you for the detailed answer.

Yuras


> 
> While I'm personally somewhat in favor of its eventual migration on
> correctness grounds and believe it'd be nice to be able to justify
> the
> state of the world as more than a series of historical accidents when
> I put
> on my libraries committee hat I have concerns.
> 
> I'm inclined to say at the least that IF we do decide to proceed on
> this,
> at least the return component should be on a long time horizon, with
> a
> clock tied to the release of a standard, say a Haskell2020. I stress
> IF,
> because I haven't had a chance to go through and do any sort of
> detailed
> tally or poll to get a sense of if there is a sufficient mandate.
> There is
> enough of a ruckus being raised that it is worth proceeding
> cautiously if
> we proceed at all.
> 
> -Edward

From hvr at gnu.org  Sun Oct 11 21:24:34 2015
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Sun, 11 Oct 2015 23:24:34 +0200
Subject: Final Call for Haskell Prime language committee Nominations!
In-Reply-To: <87wpvh8ksg.fsf@gmail.com> (Herbert Valerio Riedel's message of
 "Wed, 23 Sep 2015 12:58:07 +0200")
References: <87wpvh8ksg.fsf@gmail.com>
Message-ID: <87y4f9jdyl.fsf@gmail.com>


The submission deadline (Wed, Oct 14 23:59:59 UTC 2015) for Haskell
Prime self-nominations (see also original CfN at [1]) is near!


If you have already submitted a self-nomination, please make sure (if it
was sent to the haskell-prime list) that it shows up in the mailing list
archives at

 - https://mail.haskell.org/pipermail/haskell-prime/2015-September/ or
 - https://mail.haskell.org/pipermail/haskell-prime/2015-October/

or (if you have only sent it to me directly) that I acknowledged
receiving your submission by an email reply.


Regards,
  Herbert Valerio Riedel

 [1]: https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html

From mark.lentczner at gmail.com  Tue Oct 13 03:08:44 2015
From: mark.lentczner at gmail.com (Mark Lentczner)
Date: Mon, 12 Oct 2015 20:08:44 -0700
Subject: "Excuse me, I think this i my stop..." - Resigning from the Platform
Message-ID: <CAAOoiFbK+-X0WxTiA-LAoCpU2btRv68G+G-Syvat_GHKgc7EXw@mail.gmail.com>

I think this is the right time for me to exit:

The truth is, I still can't bring myself to use a version of Haskell post
the Foldable-Traversable-aPocalypse, let alone some future Haskell after
the changes now in the works. My personal machines are all still 7.8. My
personal projects are all pre-FTP. The Haskell I love to code in, the
Haskell I'm passionate about, the Haskell I've advocated for real world
use, and the Haskell I like to teach, is 7.8, pre-FTP.

It's not that I'm dead set against change and evolution in a language, or
even breaking changes. But FTP and beyond are changes that have lost the
balance that Haskell had between abstraction and clarity, between elaborate
and practical engineering. I don't see any restraint going forward, so I'm
getting off the train.

This puts me in an odd position with respect to Haskell Platform: I find
myself building the Platform for a version of Haskell that I don't use.
This isn't healthy for either the Platform or me. Hence, I'm resigning as
release manager.

I am sad because I believed that Haskell's path to much wider adoption was
within reach. Now, especially with the ramping up of the Haskell Prime
committee, which seems preordained to codify FTP and beyond into standard,
we are approaching our Algol 68 moment: Building a major language revision
with less opportunity than it's predecessor.

I'll still see you 'round at meet-ups and conferences. I'll just be coding
with an older accent.

- Mark "mzero" Lentczner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151012/73b7a47d/attachment.html>

From gershomb at gmail.com  Tue Oct 13 03:43:14 2015
From: gershomb at gmail.com (Gershom B)
Date: Mon, 12 Oct 2015 23:43:14 -0400
Subject: "Excuse me, I think this i my stop..." - Resigning from the
 Platform
In-Reply-To: <CAAOoiFbK+-X0WxTiA-LAoCpU2btRv68G+G-Syvat_GHKgc7EXw@mail.gmail.com>
References: <CAAOoiFbK+-X0WxTiA-LAoCpU2btRv68G+G-Syvat_GHKgc7EXw@mail.gmail.com>
Message-ID: <etPan.561c7e0e.f02f44c.124a6@mbp.local>

Thanks Mark for all your work over the years! Haskell has the adoption it does today in no small part because of your work in making sure it has been consistently easy to install over a range of systems. You?ve put many years and long hours into the work you?ve done as release manager, and we all appreciate it.

I certainly suspect the applicatipocalypse is less around-the-bend than you perhaps prophesy (sorry, couldn?t resist). But as they say, horses for courses. I look forward to catching up with you at those meetups and conferences.

Everyone else: I?m happy to step in for the immediate time being as release manager to bring to completion the minimal-platform-with-cabal-and-stack plans (aka ?Improving the Get Haskell Experience? proposal). I?ve already started to do so a very tiny bit, helping with a new OS X release to help with compatibility with El Capitan. I also want to note that lots of contributions lately have been coming courtesy of ?Randy Polen and Erik?Rantapaa in particular, so we have some great resources to build on.

Especially medium term and long term more volunteers will be very welcome (I certainly can?t imagine remaining ?Mr. Platform? for as many tireless years as Mark has). A fair amount of the work I plan to spend on platform stuff in the immediate future will be to take the good work Mark has done in making easier the platform build and release process and further document it. The end goal should be that, at least for the foreseeable future, the release manager job should become straightforward and demystified enough that passing the baton becomes easier yet.

If you have experience with installers in either the Windows or Mac world and would like to get involved (maybe just as a voice of experience and wisdom) please reach out to me and let me know. Alternately, if you have a friend with such experience, and you think you could convince them to lend a hand, perhaps suggest to them that they reach out to me :-P. Also, if you have either a range of boxes (or hardware with images of different flavors of systems) and some time to act as a tester ? please reach out as well. A designated team of installer-testers would be a good thing as well.

Best,
Gershom




On October 12, 2015 at 11:09:12 PM, Mark Lentczner (mark.lentczner at gmail.com) wrote:
> I think this is the right time for me to exit:
>  
> The truth is, I still can't bring myself to use a version of Haskell post
> the Foldable-Traversable-aPocalypse, let alone some future Haskell after
> the changes now in the works. My personal machines are all still 7.8. My
> personal projects are all pre-FTP. The Haskell I love to code in, the
> Haskell I'm passionate about, the Haskell I've advocated for real world
> use, and the Haskell I like to teach, is 7.8, pre-FTP.
>  
> It's not that I'm dead set against change and evolution in a language, or
> even breaking changes. But FTP and beyond are changes that have lost the
> balance that Haskell had between abstraction and clarity, between elaborate
> and practical engineering. I don't see any restraint going forward, so I'm
> getting off the train.
>  
> This puts me in an odd position with respect to Haskell Platform: I find
> myself building the Platform for a version of Haskell that I don't use.
> This isn't healthy for either the Platform or me. Hence, I'm resigning as
> release manager.
>  
> I am sad because I believed that Haskell's path to much wider adoption was
> within reach. Now, especially with the ramping up of the Haskell Prime
> committee, which seems preordained to codify FTP and beyond into standard,
> we are approaching our Algol 68 moment: Building a major language revision
> with less opportunity than it's predecessor.
>  
> I'll still see you 'round at meet-ups and conferences. I'll just be coding
> with an older accent.
>  
> - Mark "mzero" Lentczner
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>  


From Lennart.Augustsson at sc.com  Tue Oct 13 08:57:52 2015
From: Lennart.Augustsson at sc.com (Augustsson, Lennart)
Date: Tue, 13 Oct 2015 08:57:52 +0000
Subject: "Excuse me, I think this i my stop..." - Resigning from the
 Platform
In-Reply-To: <CAAOoiFbK+-X0WxTiA-LAoCpU2btRv68G+G-Syvat_GHKgc7EXw@mail.gmail.com>
References: <CAAOoiFbK+-X0WxTiA-LAoCpU2btRv68G+G-Syvat_GHKgc7EXw@mail.gmail.com>
Message-ID: <22B950C955F8AB4196E72698FBD00002D02A0A8E@UKWPISXMB01B.zone1.scb.net>

Mark,

Thanks for your tireless and thankless work on the Platform.
I can?t blame you for stepping down, since I feel the same as you about FTP.

 -- Lennart

From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of Mark Lentczner
Sent: 13 October 2015 04:09
To: haskell-platform at projects.haskell.org; Haskell Libraries; ghc-devs at haskell.org
Subject: "Excuse me, I think this i my stop..." - Resigning from the Platform

I think this is the right time for me to exit:

The truth is, I still can't bring myself to use a version of Haskell post the Foldable-Traversable-aPocalypse, let alone some future Haskell after the changes now in the works. My personal machines are all still 7.8. My personal projects are all pre-FTP. The Haskell I love to code in, the Haskell I'm passionate about, the Haskell I've advocated for real world use, and the Haskell I like to teach, is 7.8, pre-FTP.

It's not that I'm dead set against change and evolution in a language, or even breaking changes. But FTP and beyond are changes that have lost the balance that Haskell had between abstraction and clarity, between elaborate and practical engineering. I don't see any restraint going forward, so I'm getting off the train.

This puts me in an odd position with respect to Haskell Platform: I find myself building the Platform for a version of Haskell that I don't use. This isn't healthy for either the Platform or me. Hence, I'm resigning as release manager.

I am sad because I believed that Haskell's path to much wider adoption was within reach. Now, especially with the ramping up of the Haskell Prime committee, which seems preordained to codify FTP and beyond into standard, we are approaching our Algol 68 moment: Building a major language revision with less opportunity than it's predecessor.

I'll still see you 'round at meet-ups and conferences. I'll just be coding with an older accent.

- Mark "mzero" Lentczner


This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at http://www.standardchartered.com/en/incorporation-details.html

Insofar as this communication contains any market commentary, the market commentary has been prepared by sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied for any other purpose, and is subject to the relevant disclaimers available at http://wholesalebanking.standardchartered.com/en/utility/Pages/d-mkt.aspx

Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign on the term sheet to acknowledge in respect of the same.

Please visit http://wholesalebanking.standardchartered.com/en/capabilities/financialmarkets/Pages/doddfrankdisclosures.aspx for important information with respect to derivative products.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151013/53f3c27c/attachment-0001.html>

From simonpj at microsoft.com  Tue Oct 13 09:39:58 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 13 Oct 2015 09:39:58 +0000
Subject: "Excuse me, I think this i my stop..." - Resigning from the
 Platform
In-Reply-To: <CAAOoiFbK+-X0WxTiA-LAoCpU2btRv68G+G-Syvat_GHKgc7EXw@mail.gmail.com>
References: <CAAOoiFbK+-X0WxTiA-LAoCpU2btRv68G+G-Syvat_GHKgc7EXw@mail.gmail.com>
Message-ID: <6a9c4156788d43e1a5a0f55fa046ab32@DB4PR30MB030.064d.mgd.msft.net>

Mark

You have given a lot to the Haskell community through your steady leadership of the Haskell Platform, and I want to add my personal thank-you for that.  The Haskell community flourishes only because volunteers step up to the (not always comfortable) tasks of developing consensus and then actually getting the job done.  You have done this brilliantly ? thank you.

I know that your concerns reflect those of many.   In the olden days when Haskell was a university research language, we could change it whenever we wanted and no one minded. But now it is used for lots of things, and people rightly complain about changes.  Moreover, thoughtful and intelligent people differ in their judgement about what is and is not a good change.

These are nice problems to have: they reflect a large, passionate, committed community of people who care about the language, its ecosystem, and its users.

But of course they are still challenging problems!  There is a genuine tension between innovation and change (which make Haskell so dynamic), and dependability and stability (which make it useful).

I?m sure we will not always get it right.  But it is my earnest hope that by respecting genuine differences of judgement, by being willing to see the world through others? eyes, by being willing to accept a choice that is not our own ? in short, by expressing true respect in our dealings with each other ? we will be able to work together on a journey in which none of us knows the True Path.

So I?m very sorry to lose you as the driver of the HP train, but do hope you won?t get off the train altogether!

With true thanks

Simon

From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Mark Lentczner
Sent: 13 October 2015 04:09
To: haskell-platform at projects.haskell.org; Haskell Libraries; ghc-devs at haskell.org
Subject: "Excuse me, I think this i my stop..." - Resigning from the Platform

I think this is the right time for me to exit:

The truth is, I still can't bring myself to use a version of Haskell post the Foldable-Traversable-aPocalypse, let alone some future Haskell after the changes now in the works. My personal machines are all still 7.8. My personal projects are all pre-FTP. The Haskell I love to code in, the Haskell I'm passionate about, the Haskell I've advocated for real world use, and the Haskell I like to teach, is 7.8, pre-FTP.

It's not that I'm dead set against change and evolution in a language, or even breaking changes. But FTP and beyond are changes that have lost the balance that Haskell had between abstraction and clarity, between elaborate and practical engineering. I don't see any restraint going forward, so I'm getting off the train.

This puts me in an odd position with respect to Haskell Platform: I find myself building the Platform for a version of Haskell that I don't use. This isn't healthy for either the Platform or me. Hence, I'm resigning as release manager.

I am sad because I believed that Haskell's path to much wider adoption was within reach. Now, especially with the ramping up of the Haskell Prime committee, which seems preordained to codify FTP and beyond into standard, we are approaching our Algol 68 moment: Building a major language revision with less opportunity than it's predecessor.

I'll still see you 'round at meet-ups and conferences. I'll just be coding with an older accent.

- Mark "mzero" Lentczner

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151013/f66f268d/attachment.html>

From takenobu.hs at gmail.com  Tue Oct 13 13:36:17 2015
From: takenobu.hs at gmail.com (Takenobu Tani)
Date: Tue, 13 Oct 2015 22:36:17 +0900
Subject: "Excuse me,
 I think this i my stop..." - Resigning from the Platform
In-Reply-To: <CAAOoiFbK+-X0WxTiA-LAoCpU2btRv68G+G-Syvat_GHKgc7EXw@mail.gmail.com>
References: <CAAOoiFbK+-X0WxTiA-LAoCpU2btRv68G+G-Syvat_GHKgc7EXw@mail.gmail.com>
Message-ID: <CAPB_Nvwm3nT=-WTkNUW4zNjaZXc250gid6yX488_OJ1s37xj+Q@mail.gmail.com>

Dear Mark,

Thank you for your efforts.

You've gave us a lot of opportunity to meet haskell.
There are many people on the back side of the firewall.
They can't access over the firewall.
HP, all-in-one and web downloadable package, is very useful for them.

Thanks to you, we were able to enjoy the haskell.

Thank you very much,
Takenobu


2015-10-13 12:08 GMT+09:00 Mark Lentczner <mark.lentczner at gmail.com>:

> I think this is the right time for me to exit:
>
> The truth is, I still can't bring myself to use a version of Haskell post
> the Foldable-Traversable-aPocalypse, let alone some future Haskell after
> the changes now in the works. My personal machines are all still 7.8. My
> personal projects are all pre-FTP. The Haskell I love to code in, the
> Haskell I'm passionate about, the Haskell I've advocated for real world
> use, and the Haskell I like to teach, is 7.8, pre-FTP.
>
> It's not that I'm dead set against change and evolution in a language, or
> even breaking changes. But FTP and beyond are changes that have lost the
> balance that Haskell had between abstraction and clarity, between elaborate
> and practical engineering. I don't see any restraint going forward, so I'm
> getting off the train.
>
> This puts me in an odd position with respect to Haskell Platform: I find
> myself building the Platform for a version of Haskell that I don't use.
> This isn't healthy for either the Platform or me. Hence, I'm resigning as
> release manager.
>
> I am sad because I believed that Haskell's path to much wider adoption was
> within reach. Now, especially with the ramping up of the Haskell Prime
> committee, which seems preordained to codify FTP and beyond into standard,
> we are approaching our Algol 68 moment: Building a major language revision
> with less opportunity than it's predecessor.
>
> I'll still see you 'round at meet-ups and conferences. I'll just be coding
> with an older accent.
>
> - Mark "mzero" Lentczner
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151013/79a2f9d9/attachment.html>

From joe at haskell.monoid.al  Thu Oct 15 22:51:21 2015
From: joe at haskell.monoid.al (Joe Hermaszewski)
Date: Thu, 15 Oct 2015 23:51:21 +0100
Subject: Default definition for fromRational
Message-ID: <1444949481.2947094.411534713.6A06A1CD@webmail.messagingengine.com>

A suitable default definition for fromRational could be the following:

fromRational n = fromInteger (numerator n) / fromInteger (denominator n)

Changing the MINIMUM pragma to just {-# MINIMAL recip | (/) #-}

- Joe

From ekmett at gmail.com  Thu Oct 15 23:24:56 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Thu, 15 Oct 2015 19:24:56 -0400
Subject: Default definition for fromRational
In-Reply-To: <1444949481.2947094.411534713.6A06A1CD@webmail.messagingengine.com>
References: <1444949481.2947094.411534713.6A06A1CD@webmail.messagingengine.com>
Message-ID: <CAJumaK-JVJKq5KLfNPmS=GeQgUZ7k5xbHMbg0OXOU3rBs5rbEQ@mail.gmail.com>

True. I can't think of any issues off hand.

-Edward



On Thu, Oct 15, 2015 at 6:51 PM, Joe Hermaszewski <joe at haskell.monoid.al>
wrote:

> A suitable default definition for fromRational could be the following:
>
> fromRational n = fromInteger (numerator n) / fromInteger (denominator n)
>
> Changing the MINIMUM pragma to just {-# MINIMAL recip | (/) #-}
>
> - Joe
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151015/7293d037/attachment.html>

From lemming at henning-thielemann.de  Sun Oct 18 17:51:43 2015
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Sun, 18 Oct 2015 19:51:43 +0200 (CEST)
Subject: Arrow syntax vs. functional style (Was: Monad of no `return` Proposal
 (MRP): Moving `return` out of `Monad`)
In-Reply-To: <560F28D8.1070406@nottingham.ac.uk>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk> <mumqmr$r00$1@ger.gmane.org>
 <560F28D8.1070406@nottingham.ac.uk>
Message-ID: <alpine.DEB.2.02.1510181942550.19189@sputnik>


On Sat, 3 Oct 2015, Henrik Nilsson wrote:

> For example, I have written quite a bit of applicative code, way before 
> it was even called applicative, and I did not find the lack of syntactic 
> support particularly bothersome. On the other hand, I have also written 
> a lot of arrowized code, and there, while I do use the syntactic sugar 
> to allow me to name certain things, the fact that I then have to name 
> everything is rather annoying to say the least, and I have often found 
> myself wishing that I could write arrowized code that looked a lot more 
> like applicative code (without the sugar).

I was unhappy about arrow syntax for the same reasons and with Mr. 
Apfelmus I developed a technique that allows to apply Arrows in an 
Applicative style. However, because it relies on the Vault data structure 
it works efficiently only for EDSL things. Unfortunately we have not 
written up the method so far, I have only a complicated module that 
employs the method:
    https://hackage.haskell.org/package/synthesizer-llvm-0.7.0.1/src/src/Synthesizer/LLVM/CausalParameterized/Functional.hs

If I find time I could extract the according code to a new package.

From lemming at henning-thielemann.de  Sun Oct 18 18:15:40 2015
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Sun, 18 Oct 2015 20:15:40 +0200 (CEST)
Subject: Monad of no `return` Proposal (MRP): Moving `return` out of
 `Monad`
In-Reply-To: <CAJWnFaNy2GySZQjABwS4Z8AKqq3VLh4dOK1gAqHAgZ0EfE+f_w@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk> <mumqmr$r00$1@ger.gmane.org>
 <560F28D8.1070406@nottingham.ac.uk>
 <CAJWnFaNy2GySZQjABwS4Z8AKqq3VLh4dOK1gAqHAgZ0EfE+f_w@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1510181959220.19189@sputnik>


On Fri, 2 Oct 2015, Manuel G?mez wrote:

> In a post-AMP Haskell, however, retaining `return` in `Monad` does not 
> serve any purpose: any `Monad` instance requires an `Applicative` 
> instance, wherein `pure` must be defined, and it is a law required by 
> all instances that they behave identically.  The only expressive purpose 
> of `return` being in the `Monad` type class is providing an opportunity 
> to break the laws the community expects for all instances of `Monad`.

We will get constant breakage this way. You mentioned Pointed class. If it 
appears one day then your argument would translate to: We must acknowledge 
that 'pure' was always wrong in Applicative. Then we will have an APP 
(Applicative without 'pure' proposal) that again breaks lots of code 
without a way to code for multiple versions of base.

From lemming at henning-thielemann.de  Sun Oct 18 18:24:58 2015
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Sun, 18 Oct 2015 20:24:58 +0200 (CEST)
Subject: Monad of no `return` Proposal (MRP): Moving `return` out of
 `Monad`
In-Reply-To: <87io6zmr2x.fsf@gnu.org>
References: <87io6zmr2x.fsf@gnu.org>
Message-ID: <alpine.DEB.2.02.1510182015540.19189@sputnik>


On Thu, 24 Sep 2015, Herbert Valerio Riedel wrote:

> Concluding AMP and MFP, We (David and I) proudly present you the final
> installment of the Monad trilogy:
>
>
> Monad of no `return` Proposal
> =============================

Btw. there were proposals of GHC extensions that allow class hierarchy 
updates without much code breakage (class aliases) etc. Could we defer the 
MRP until such extensions are implemented?

From lemming at henning-thielemann.de  Sun Oct 18 18:49:58 2015
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Sun, 18 Oct 2015 20:49:58 +0200 (CEST)
Subject: How to avoid CPP (Was: [Haskell-cafe] Monad of no `return` Proposal
 (MRP): Moving `return` out of `Monad`)
In-Reply-To: <CAHZrzdqPbv5OHzE8UEnxQ0_TXcmQbatJZC6g2mg9eBz1-SP_Dw@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <CANBN=mscEocVQ-z+RMe_mF+6E=TU51U7ei8o_Hb74vL+fV9vZg@mail.gmail.com>
 <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca>
 <CAGcFDtjuOAd0M2AVRK8Cx3kG0AEAHZ_D7WR9Z9yOmZ6Lo7uYEw@mail.gmail.com>
 <CAHZrzdqPbv5OHzE8UEnxQ0_TXcmQbatJZC6g2mg9eBz1-SP_Dw@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1510182041000.19189@sputnik>


On Mon, 5 Oct 2015, Gregory Collins wrote:

> Um, no, it usually isn't anything like that. Here's a sampling of some of the things I've used CPP for in the past few
> years:
>  *  After GHC 7.4, when using a newtype in FFI imports you need to import the constructor, i.e. "import
>     Foreign.C.Types(CInt(..))" --- afaik CPP is the only way to shut up warnings everywhere

I import them qualified and then define

    type CInt = CTypes.CInt

sometimes.

>  *  defaultTimeLocale moved from System.Locale to Data.Time.Format in time-1.5 (no compat package for this, afaik)

I was advised to always import time-1.5.

>  *  one of many various changes to Typeable in the GHC 7.* series (deriving works better now, mkTyCon vs mkTyCon3, etc)

I have not used that. Like I have not used the ever changing Template 
Haskell stuff.

>  *  Do I have to hide "catch" from Prelude, or not? It got moved, and "hiding" gives an error if the symbol you're trying
>     to hide is missing. Time to break out the CPP (and curse myself for not just using the qualified import in the first
>     place)

I think System.IO.Error.catchIOError maintains the old behaviour.

>  *  Do I get monoid functions from Prelude or from Data.Monoid? Same w/ Applicative, Foldable, Word. I don't know where
>     anything is supposed to live anymore, or which sequence of imports will shut up spurious warnings on all four versions
>     of GHC I support, so the lowest-friction fix is: break out the #ifdef spackle

I always import them from the most specific module. Where GHC-7.10 Prelude 
causes conflicts I even started to import more basic Prelude stuff from 
modules like Data.Bool, Data.Eq and friends. Horrible, but works without 
CPP.

>  *  ==# and friends return Int# instead of Bool after GHC 7.8.1

I did not use it. I have also warned that the change might not be a good 
idea since LLVM knows that its 'i1' type can only have the values 0 and 1 
and it does not know that for 'i32' or 'i64'.

>  *  To use functions like "tryReadMVar", "unsafeShiftR", and "atomicModifyIORef'" that are in recent base versions but not
>     older ones (this is a place where CPP use is actually justified)

I have not used them so far.


I have solved more complicated cases with conditional Hs-Source-Dirs:
    http://wiki.haskell.org/Cabal/Developer-FAQ#Adapt_to_different_systems_without_CPP

It's cumbersome but so far I managed most transitions without CPP.

(Nonetheless, MRP would require the complicated Hs-Source-Dirs solution 
for far too many packages.)

From ekmett at gmail.com  Mon Oct 19 19:17:08 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Mon, 19 Oct 2015 15:17:08 -0400
Subject: Monad of no `return` Proposal (MRP): Moving `return` out of
 `Monad`
In-Reply-To: <alpine.DEB.2.02.1510182015540.19189@sputnik>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510182015540.19189@sputnik>
Message-ID: <CAJumaK_9GWhp5TBxwv0jHXbt5iTQHEQCXC_WumO6X_x-5bZ0JA@mail.gmail.com>

On Sun, Oct 18, 2015 at 2:24 PM, Henning Thielemann <
lemming at henning-thielemann.de> wrote:

> Btw. there were proposals of GHC extensions that allow class hierarchy
> updates without much code breakage (class aliases) etc. Could we defer the
> MRP until such extensions are implemented?


There are three things entangled in your request that I'd like to uncouple.

1.) None of those proposals would actually have any impact here: `pure` is
already a member of Applicative that people already define. `return`
already has a definition in terms of `pure` as its default.

2.) This proposal is definitely being deferred in one sense, nothing can
even happen on the warning front until 8.2 at the earliest under the "3
Release Policy" and in practice we'd probably push it back further still
given the scope. So you have a couple of years before you'd even hear a
peep from the compiler about this saying that hey maybe you might want to
consider doing something.

3.) Finally, it isn't clear to me that we're going to be able to achieve a
meaningful consensus on how to proceed with superclass defaults. We've been
tossing proposals for them around for years. There are at least 3 of them
in the wings, with both Richard Eisenberg and Conor McBride having
different proposals that yield different end states with varying degrees of
prescriptiveness about how they should be used, and some other folks who
disbelieve it can be implemented at all in a way that works well with
anything more complicated than a linear chain of instances.

So while they don't apply to this item, I'm hesitant to incur such a
proposal as a blocker on anything when there is no sign of termination in
sight and no indication of which way that feature will break in terms of
supplied functionality.

That is a broader statement as while here they bring nothing to the table
that would affect code written under this proposal, elsewhere they could
help. -- If we had them at most eventually people would be able to consider
(maybe) dropping the manual declaration of Functor, and possibly inline
some of their definitions from Applicative into the Monad declaration
(depending on which proposal wins favor if any, and if that version of the
proposal always complains when it is used like Richard's variant), but the
story of pure vs. return doesn't change meaningfully.

That said, if a version of the feature showed up over the next 2-3 years in
GHC, we'd likely modify the Monoid-Semigroup Proposal to incorporate it as
that proposal could benefit, but as above I'd hesitate to tie anything to
the fate of a superclass default proposal.

Again, none of the changes being proposed have any impacts before 8.2 (or
even 8.4 at last check.)

-Edward
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151019/637af781/attachment.html>

From lemming at henning-thielemann.de  Mon Oct 19 19:52:28 2015
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Mon, 19 Oct 2015 21:52:28 +0200 (CEST)
Subject: merits of ApplicativeDo (Was: Monad of no `return` Proposal (MRP):
 Moving `return` out of `Monad`)
In-Reply-To: <560EFD69.20006@stilo.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk> <mumqmr$r00$1@ger.gmane.org>
 <560EFD69.20006@stilo.com>
Message-ID: <alpine.DEB.2.02.1510181952060.19189@sputnik>


On Fri, 2 Oct 2015, Mario Bla?evi? wrote:

> 	The benefits of applicative do, if I understand the motivation 
> correctly, are not so much to help in writing new code intended to be 
> applicative. Instead it lets the programmer write in monadic style and at the 
> same time enables the compiler to convert the code to applicative style if 
> possible. This has the potential to automatically improve performance of 
> legacy Haskell codebase, as well as any new beginner-friendly code that 
> relies on syntactic sugar.

I see the benefit of ApplicativeDo in the short distance of the value 
producer and the value naming. E.g. compare

liftA3
    (\x y z -> complicatedFunc x y z)
    produceX produceY produceZ

and

do x <- produceX
    y <- produceY
    z <- produceZ
    pure $ complicatedFunc x y z


Using the first style you may easily introduce inconsistencies if you 
change the order of produceX, produceY, produceZ, whereas with the second 
style you will certainly change whole lines and stay consistent this way.

From jules at jellybean.co.uk  Tue Oct 20 08:18:25 2015
From: jules at jellybean.co.uk (Julian Bean)
Date: Tue, 20 Oct 2015 09:18:25 +0100
Subject: merits of ApplicativeDo (Was: Monad of no `return` Proposal
 (MRP): Moving `return` out of `Monad`)
In-Reply-To: <alpine.DEB.2.02.1510181952060.19189@sputnik>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk> <mumqmr$r00$1@ger.gmane.org>
 <560EFD69.20006@stilo.com> <alpine.DEB.2.02.1510181952060.19189@sputnik>
Message-ID: <FD293E71-A8A3-4A9E-A6A0-41CBB4599007@jellybean.co.uk>


On 19 Oct 2015, at 20:52, Henning Thielemann <lemming at henning-thielemann.de> wrote:
> I see the benefit of ApplicativeDo in the short distance of the value producer and the value naming. E.g. compare
> 
> liftA3
>   (\x y z -> complicatedFunc x y z)
>   produceX produceY produceZ
> 
> and
> 
> do x <- produceX
>   y <- produceY
>   z <- produceZ
>   pure $ complicatedFunc x y z


Agreed. Furthermore I quite like the way applicative comprehensions read:

[complicatedFunc x y z | x <- produceX, y <- produceY, z <- produceZ ]

Also, what this example doesn?t show is that sometimes complicatedFunc is actually a complicated *expression* which merely mentions x,y,z each 1 or more times:

[ . . . some long code mentioning x . . .
  . . . and y and x again and now z . . .
  | x <- produceX,
    y <- produceY, 
    z <- produceZ
 ]

As Henning says the tradeoffs here are all to do with drawing the eye correctly between the use of x,y,z and the binding of x y x.

There is also the fact that x y and z may not ?naturally? occur in the right order - the ordering of effects in the producers can easily be significant.

Jules



From johan.tibell at gmail.com  Tue Oct 20 13:59:29 2015
From: johan.tibell at gmail.com (Johan Tibell)
Date: Tue, 20 Oct 2015 15:59:29 +0200
Subject: Taking a step back
Message-ID: <CAK-tuPagavVPLLmGuU6015VkpQw9zLDtZRZPqxG8c4Uvsg6FVg@mail.gmail.com>

Friends,

I'm taking a step back from day-to-day library work.

There are two main reasons I use Haskell: on one hand I find writing
Haskell educational and fun. On the other I hope to make it a viable
alternative to existing mainstream languages. With recent changes to our
core libraries, and the general direction these are moving in, I believe
we're moving away from becoming a viable alternative to those mainstream
languages.

This has some practical implications for how I spend my Haskell hacking
time. Much of what I do is maintaining and working on libraries that are
needed for real world usage, but that aren't that interesting to work on.
I've lost the motivation to work on these.

I've decided to take a step back from the core maintenance work on cabal,
network, containers, and a few others* starting now. I've already found
replacement maintainers for these.

I still plan to hack on random side projects, including GHC, and to
continue coming to Haskell events and conference, just with a shorter bug
backlog to worry about. :)

-- Johan Tibell

* For now I will still hack on unordered-containers and ekg, as there are
some things I'd like to experiment with there.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151020/8f277471/attachment.html>

From Lennart.Augustsson at sc.com  Tue Oct 20 14:22:36 2015
From: Lennart.Augustsson at sc.com (Augustsson, Lennart)
Date: Tue, 20 Oct 2015 14:22:36 +0000
Subject: Taking a step back
In-Reply-To: <CAK-tuPagavVPLLmGuU6015VkpQw9zLDtZRZPqxG8c4Uvsg6FVg@mail.gmail.com>
References: <CAK-tuPagavVPLLmGuU6015VkpQw9zLDtZRZPqxG8c4Uvsg6FVg@mail.gmail.com>
Message-ID: <22B950C955F8AB4196E72698FBD00002D02A1F10@UKWPISXMB01B.zone1.scb.net>

Johan,

Thank you for your hard work maintaining several much used and very essential packages.
I?m sad to see you leave as the maintainer, but I understand your sentiment.

 -- Lennart

From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of Johan Tibell
Sent: 20 October 2015 14:59
To: ghc-devs at haskell.org; Haskell Libraries; cabal-devel at haskell.org
Subject: Taking a step back

Friends,

I'm taking a step back from day-to-day library work.

There are two main reasons I use Haskell: on one hand I find writing Haskell educational and fun. On the other I hope to make it a viable alternative to existing mainstream languages. With recent changes to our core libraries, and the general direction these are moving in, I believe we're moving away from becoming a viable alternative to those mainstream languages.

This has some practical implications for how I spend my Haskell hacking time. Much of what I do is maintaining and working on libraries that are needed for real world usage, but that aren't that interesting to work on. I've lost the motivation to work on these.

I've decided to take a step back from the core maintenance work on cabal, network, containers, and a few others* starting now. I've already found replacement maintainers for these.

I still plan to hack on random side projects, including GHC, and to continue coming to Haskell events and conference, just with a shorter bug backlog to worry about. :)

-- Johan Tibell

* For now I will still hack on unordered-containers and ekg, as there are some things I'd like to experiment with there.

This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at http://www.standardchartered.com/en/incorporation-details.html

Insofar as this communication contains any market commentary, the market commentary has been prepared by sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied for any other purpose, and is subject to the relevant disclaimers available at http://wholesalebanking.standardchartered.com/en/utility/Pages/d-mkt.aspx

Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign on the term sheet to acknowledge in respect of the same.

Please visit http://wholesalebanking.standardchartered.com/en/capabilities/financialmarkets/Pages/doddfrankdisclosures.aspx for important information with respect to derivative products.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151020/59fd3294/attachment.html>

From evan at evanrutledgeborden.dreamhosters.com  Tue Oct 20 14:23:26 2015
From: evan at evanrutledgeborden.dreamhosters.com (evan@evan-borden.com)
Date: Tue, 20 Oct 2015 10:23:26 -0400
Subject: Taking a step back
In-Reply-To: <CAK-tuPagavVPLLmGuU6015VkpQw9zLDtZRZPqxG8c4Uvsg6FVg@mail.gmail.com>
References: <CAK-tuPagavVPLLmGuU6015VkpQw9zLDtZRZPqxG8c4Uvsg6FVg@mail.gmail.com>
Message-ID: <CABmRwSD1jeV89zcZHfE+vNhPoqnJZ7KPsvi0bzz4p1XjWMY=uQ@mail.gmail.com>

Thank you for all the work you've done to evolve the Haskell ecosystem.
Your steady hand will be missed.

On Tue, Oct 20, 2015 at 9:59 AM, Johan Tibell <johan.tibell at gmail.com>
wrote:

> Friends,
>
> I'm taking a step back from day-to-day library work.
>
> There are two main reasons I use Haskell: on one hand I find writing
> Haskell educational and fun. On the other I hope to make it a viable
> alternative to existing mainstream languages. With recent changes to our
> core libraries, and the general direction these are moving in, I believe
> we're moving away from becoming a viable alternative to those mainstream
> languages.
>
> This has some practical implications for how I spend my Haskell hacking
> time. Much of what I do is maintaining and working on libraries that are
> needed for real world usage, but that aren't that interesting to work on.
> I've lost the motivation to work on these.
>
> I've decided to take a step back from the core maintenance work on cabal,
> network, containers, and a few others* starting now. I've already found
> replacement maintainers for these.
>
> I still plan to hack on random side projects, including GHC, and to
> continue coming to Haskell events and conference, just with a shorter bug
> backlog to worry about. :)
>
> -- Johan Tibell
>
> * For now I will still hack on unordered-containers and ekg, as there are
> some things I'd like to experiment with there.
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151020/4d310b2f/attachment-0001.html>

From carter.schonwald at gmail.com  Tue Oct 20 14:32:55 2015
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Tue, 20 Oct 2015 10:32:55 -0400
Subject: Taking a step back
In-Reply-To: <CAK-tuPagavVPLLmGuU6015VkpQw9zLDtZRZPqxG8c4Uvsg6FVg@mail.gmail.com>
References: <CAK-tuPagavVPLLmGuU6015VkpQw9zLDtZRZPqxG8c4Uvsg6FVg@mail.gmail.com>
Message-ID: <CAHYVw0ydtN26YQJF75MKAFx4dBZ7zsnYn-kc2E1w1aWvdnjF2Q@mail.gmail.com>

I look forward to seeing yah around at events, as always!

On Tuesday, October 20, 2015, Johan Tibell <johan.tibell at gmail.com> wrote:

> Friends,
>
> I'm taking a step back from day-to-day library work.
>
> There are two main reasons I use Haskell: on one hand I find writing
> Haskell educational and fun. On the other I hope to make it a viable
> alternative to existing mainstream languages. With recent changes to our
> core libraries, and the general direction these are moving in, I believe
> we're moving away from becoming a viable alternative to those mainstream
> languages.
>
> This has some practical implications for how I spend my Haskell hacking
> time. Much of what I do is maintaining and working on libraries that are
> needed for real world usage, but that aren't that interesting to work on.
> I've lost the motivation to work on these.
>
> I've decided to take a step back from the core maintenance work on cabal,
> network, containers, and a few others* starting now. I've already found
> replacement maintainers for these.
>
> I still plan to hack on random side projects, including GHC, and to
> continue coming to Haskell events and conference, just with a shorter bug
> backlog to worry about. :)
>
> -- Johan Tibell
>
> * For now I will still hack on unordered-containers and ekg, as there are
> some things I'd like to experiment with there.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151020/998dbbb0/attachment.html>

From voldermort at hotmail.com  Tue Oct 20 14:45:38 2015
From: voldermort at hotmail.com (Jeremy)
Date: Tue, 20 Oct 2015 07:45:38 -0700 (MST)
Subject: Taking a step back
In-Reply-To: <CAK-tuPagavVPLLmGuU6015VkpQw9zLDtZRZPqxG8c4Uvsg6FVg@mail.gmail.com>
References: <CAK-tuPagavVPLLmGuU6015VkpQw9zLDtZRZPqxG8c4Uvsg6FVg@mail.gmail.com>
Message-ID: <1445352338838-5820322.post@n5.nabble.com>

Sincere thanks for all the work that you've done for the Haskell ecosystem,
it's much appreciated and will be sorely missed.

I'm interested in why you think recent changes are making Haskell a less
viable alternative to mainstream languages. My experience is the opposite -
beginners frequently ask "why is x not a superclass of y?" and "why does
function a seem to be the same as b?", and are horrified to be told that
it's for historical reasons (y existed before x, a existed before the more
general b, etc.). This is a big anti-climax for someone coming from a
"mainstream" language, where type classes are all in the expected logical
hierarchy, and functions/types always have the most general constraints
possible.



--
View this message in context: http://haskell.1045720.n5.nabble.com/Taking-a-step-back-tp5820315p5820322.html
Sent from the Haskell - Libraries mailing list archive at Nabble.com.

From ollie at ocharles.org.uk  Tue Oct 20 16:15:06 2015
From: ollie at ocharles.org.uk (Oliver Charles)
Date: Tue, 20 Oct 2015 16:15:06 +0000
Subject: Taking a step back
In-Reply-To: <CAK-tuPagavVPLLmGuU6015VkpQw9zLDtZRZPqxG8c4Uvsg6FVg@mail.gmail.com>
References: <CAK-tuPagavVPLLmGuU6015VkpQw9zLDtZRZPqxG8c4Uvsg6FVg@mail.gmail.com>
Message-ID: <CAGRp5Rn27HeQHCWHBw4kuf8hDTMrXH9hQMLzfq_fEv4_JFpjxQ@mail.gmail.com>

Thank you for all the hard work you've put in over the years! I can
certainly say (at least from a sample size of one) that your have met your
goals, and your libraries have been paramount to letting me use Haskell as
an alternative to mainstream languages.

It's sad to see someone step away due to turbulence in the community and
future visions for Haskell, but I hope that when things settle (I truly
believe they will) that you will feel like joining us again.

All the best!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151020/53afd756/attachment.html>

From cma at bitemyapp.com  Tue Oct 20 16:26:04 2015
From: cma at bitemyapp.com (Christopher Allen)
Date: Tue, 20 Oct 2015 11:26:04 -0500
Subject: Taking a step back
In-Reply-To: <CAK-tuPagavVPLLmGuU6015VkpQw9zLDtZRZPqxG8c4Uvsg6FVg@mail.gmail.com>
References: <CAK-tuPagavVPLLmGuU6015VkpQw9zLDtZRZPqxG8c4Uvsg6FVg@mail.gmail.com>
Message-ID: <CADnndOoRwkdiOx6LW2j7vEDVGa-vt+R4KPGcdTDVLohcv6k_Yw@mail.gmail.com>

Thank you for your contributions to the Haskell community. Your work has
done a lot, especially for working Haskell programmers like myself and my
coworkers. I'm also grateful that you're willing to continue moving the
ball forward with unordered-containers and ekg.

You didn't mention it explicitly, but what about maintainership of Cassava?
I have a soft-spot for that library which I've explained in this Github
issue[1] and I'd like the library to get the love & attention I think it
deserves.

Hoping you'll reconsider your appraisal of Haskell in the future, but if
you're not having fun, no reason to suffer.

Cheers,

[1]: https://github.com/tibbe/cassava/issues/101

On Tue, Oct 20, 2015 at 8:59 AM, Johan Tibell <johan.tibell at gmail.com>
wrote:

> Friends,
>
> I'm taking a step back from day-to-day library work.
>
> There are two main reasons I use Haskell: on one hand I find writing
> Haskell educational and fun. On the other I hope to make it a viable
> alternative to existing mainstream languages. With recent changes to our
> core libraries, and the general direction these are moving in, I believe
> we're moving away from becoming a viable alternative to those mainstream
> languages.
>
> This has some practical implications for how I spend my Haskell hacking
> time. Much of what I do is maintaining and working on libraries that are
> needed for real world usage, but that aren't that interesting to work on.
> I've lost the motivation to work on these.
>
> I've decided to take a step back from the core maintenance work on cabal,
> network, containers, and a few others* starting now. I've already found
> replacement maintainers for these.
>
> I still plan to hack on random side projects, including GHC, and to
> continue coming to Haskell events and conference, just with a shorter bug
> backlog to worry about. :)
>
> -- Johan Tibell
>
> * For now I will still hack on unordered-containers and ekg, as there are
> some things I'd like to experiment with there.
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>


-- 
Chris Allen
Currently working on http://haskellbook.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151020/354d40a7/attachment.html>

From ekmett at gmail.com  Tue Oct 20 16:44:56 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Tue, 20 Oct 2015 12:44:56 -0400
Subject: Taking a step back
In-Reply-To: <CAK-tuPagavVPLLmGuU6015VkpQw9zLDtZRZPqxG8c4Uvsg6FVg@mail.gmail.com>
References: <CAK-tuPagavVPLLmGuU6015VkpQw9zLDtZRZPqxG8c4Uvsg6FVg@mail.gmail.com>
Message-ID: <CAJumaK_z8rARUg5w=MhAx1ArYW1epqpOBQ+c=cqi+o4_98qCRw@mail.gmail.com>

Johan,

Thank you so much for all of your contributions to the community.

I confess, there are days when I find myself lost in maintenance hell that
I feel a desire to throw in the towel as well. (If Eric Mertens and others
hadn't picked up so much of the slack on my own projects I'm afraid I
likely would have reached the point of gravitational collapse long ago.)

I'm terribly sorry to hear that recent attempts to mitigate the impact of
changes, the three release policy which as inspired by comments you made,
haven't been enough to assuage your fears and discontent about the current
direction things are heading.

We are all poorer for the loss of your guidance.

-Edward

On Tue, Oct 20, 2015 at 9:59 AM, Johan Tibell <johan.tibell at gmail.com>
wrote:

> Friends,
>
> I'm taking a step back from day-to-day library work.
>
> There are two main reasons I use Haskell: on one hand I find writing
> Haskell educational and fun. On the other I hope to make it a viable
> alternative to existing mainstream languages. With recent changes to our
> core libraries, and the general direction these are moving in, I believe
> we're moving away from becoming a viable alternative to those mainstream
> languages.
>
> This has some practical implications for how I spend my Haskell hacking
> time. Much of what I do is maintaining and working on libraries that are
> needed for real world usage, but that aren't that interesting to work on.
> I've lost the motivation to work on these.
>
> I've decided to take a step back from the core maintenance work on cabal,
> network, containers, and a few others* starting now. I've already found
> replacement maintainers for these.
>
> I still plan to hack on random side projects, including GHC, and to
> continue coming to Haskell events and conference, just with a shorter bug
> backlog to worry about. :)
>
> -- Johan Tibell
>
> * For now I will still hack on unordered-containers and ekg, as there are
> some things I'd like to experiment with there.
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151020/13223cc9/attachment.html>

From greg at gregorycollins.net  Tue Oct 20 18:35:20 2015
From: greg at gregorycollins.net (Gregory Collins)
Date: Tue, 20 Oct 2015 11:35:20 -0700
Subject: Taking a step back
In-Reply-To: <1445352338838-5820322.post@n5.nabble.com>
References: <CAK-tuPagavVPLLmGuU6015VkpQw9zLDtZRZPqxG8c4Uvsg6FVg@mail.gmail.com>
 <1445352338838-5820322.post@n5.nabble.com>
Message-ID: <CAHZrzdoUeypkhB_jqbsUwGU2qG-hnAkweY0aNeMUm228+mQSJw@mail.gmail.com>

On Tue, Oct 20, 2015 at 7:45 AM, Jeremy <voldermort at hotmail.com> wrote:

> I'm interested in why you think recent changes are making Haskell a less
> viable alternative to mainstream languages.
>

I don't want to put words in Johan's mouth, but we visited together last
week and discussed this very topic, and I think my feelings on the matter
are pretty similar.

For the sake of argument, let's assume I'm a potential commercial user who
needs to decide whether Haskell is a technology I can base my next product
on. I'm going to do a cost-benefit analysis before I make my decision. The
major "pro" arguments you hear for using Haskell is that you'll end up with
programs that are more likely to be correct, and that since the language is
more expressive, you'll work faster: in other words, your net productivity
will increase. Of course, these hypothetical productivity benefits are
extremely difficult to quantify (and Lord knows, we've tried), but that's
not at all true for the "con" arguments:

   - how many Haskell programmers are there in industry? If I lose my local
   expert who is trying to push us to use this thing, can I hire another?
   - how many lines of code are written in Haskell globally vs other
   languages?
   - how much tooling will I have available to help me if I choose Haskell
   vs. a "safer" technology like Java, Python, or Go?
   - how many open source libraries will I have available to me to handle
   common tasks, and what is their quality?
   - how likely am I to encounter bugs in the compiler or base libraries?

The point Johan is trying to make is this: if I'm thinking of using
Haskell, then I'm taking on a lot of project risk to get a (hypothetical,
difficult to quantify) X% productivity benefit. If choosing it actually
*costs* me a (real, obvious, easy to quantify) Y% tax because I have to
invest K hours every other quarter fixing all my programs to cope with
random/spurious changes in the ecosystem and base libraries, then unless we
can clearly convince people that X >> Y, the rationale for choosing to use
it is degraded or even nullified altogether.

G
-- 
Gregory Collins <greg at gregorycollins.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151020/19e33223/attachment-0001.html>

From mwm at mired.org  Tue Oct 20 18:47:09 2015
From: mwm at mired.org (Mike Meyer)
Date: Tue, 20 Oct 2015 18:47:09 +0000
Subject: Taking a step back
In-Reply-To: <CAHZrzdoUeypkhB_jqbsUwGU2qG-hnAkweY0aNeMUm228+mQSJw@mail.gmail.com>
References: <CAK-tuPagavVPLLmGuU6015VkpQw9zLDtZRZPqxG8c4Uvsg6FVg@mail.gmail.com>
 <1445352338838-5820322.post@n5.nabble.com>
 <CAHZrzdoUeypkhB_jqbsUwGU2qG-hnAkweY0aNeMUm228+mQSJw@mail.gmail.com>
Message-ID: <CAD=7U2BQwYegQ5C+oMYnmxbe-CJmTqcdgcLYTPo7e_Wr9S=yBA@mail.gmail.com>

On Tue, Oct 20, 2015 at 1:35 PM Gregory Collins <greg at gregorycollins.net>
wrote:

> The point Johan is trying to make is this: if I'm thinking of using
> Haskell, then I'm taking on a lot of project risk to get a (hypothetical,
> difficult to quantify) X% productivity benefit. If choosing it actually
> *costs* me a (real, obvious, easy to quantify) Y% tax because I have to
> invest K hours every other quarter fixing all my programs to cope with
> random/spurious changes in the ecosystem and base libraries, then unless we
> can clearly convince people that X >> Y, the rationale for choosing to use
> it is degraded or even nullified altogether.
>

So I'll rephrase a question I asked earlier that never got an answer: if
I'm developing a commercial project based on ghc and some ecosystem, what
would possibly cause me to change either the ghc version or any part of the
ecosystem every other quarter? Or ever, for that matter? I've never worked
on  a commercial project that changed anything major mid-project, no matter
what language it was using. As far as I'm concerned, one of the major
features of stack is that it handles project-specific ecostystems cleanly
and transparently.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151020/53d1e21a/attachment.html>

From ivan.perez at keera.co.uk  Tue Oct 20 19:24:50 2015
From: ivan.perez at keera.co.uk (Ivan Perez)
Date: Tue, 20 Oct 2015 20:24:50 +0100
Subject: Taking a step back
In-Reply-To: <CAD=7U2BQwYegQ5C+oMYnmxbe-CJmTqcdgcLYTPo7e_Wr9S=yBA@mail.gmail.com>
References: <CAK-tuPagavVPLLmGuU6015VkpQw9zLDtZRZPqxG8c4Uvsg6FVg@mail.gmail.com>
 <1445352338838-5820322.post@n5.nabble.com>
 <CAHZrzdoUeypkhB_jqbsUwGU2qG-hnAkweY0aNeMUm228+mQSJw@mail.gmail.com>
 <CAD=7U2BQwYegQ5C+oMYnmxbe-CJmTqcdgcLYTPo7e_Wr9S=yBA@mail.gmail.com>
Message-ID: <56269502.9090408@keera.co.uk>

On 20/10/15 19:47, Mike Meyer wrote:
> On Tue, Oct 20, 2015 at 1:35 PM Gregory Collins 
> <greg at gregorycollins.net <mailto:greg at gregorycollins.net>> wrote:
>
>     The point Johan is trying to make is this: if I'm thinking of
>     using Haskell, then I'm taking on a lot of project risk to get a
>     (hypothetical, difficult to quantify) X% productivity benefit. If
>     choosing it actually *costs* me a (real, obvious, easy to
>     quantify) Y% tax because I have to invest K hours every other
>     quarter fixing all my programs to cope with random/spurious
>     changes in the ecosystem and base libraries, then unless we can
>     clearly convince people that X >> Y, the rationale for choosing to
>     use it is degraded or even nullified altogether.
>
>
> So I'll rephrase a question I asked earlier that never got an answer: 
> if I'm developing a commercial project based on ghc and some 
> ecosystem, what would possibly cause me to change either the ghc 
> version or any part of the ecosystem every other quarter? Or ever, for 
> that matter?
I don't know about them, I can tell you my personal experience.

If GHC and all libraries were perfect and free from bugs and ultimately 
optimized, then you'd be right: there would be no reason to change.

But if you ever hit a bug in GHC or a library which was fixed in a 
future version, or if you want an improvement made to it, you may have 
to update the compiler.

Library creators/maintainers do not always maintain their libraries 
compatible with very old/very new versions of the compiler. In an 
ecosystem like ours, with 3 versions of the compiler in use 
simultaneously, each with different language features and base APIs 
changed, compatibility requires a lot of work.

This problem is transitive: if you depend on (a new version of a library 
that depends on)* a new version of base or a new language feature, 
you'll may have to update GHC. If you do not have the resources to 
backport those fixes and improvements, you'll be forced to update. In 
large projects you are likely to use hundreds of auxiliary libraries, so 
this is very likely to happen.

I recently had to do this for one library because I could only compile 
it with a newer version of GHC. This project had 30K lines of Haskell 
split in dozens of libraries and a few commercial projects in 
production. It meant fixing, recompiling, packaging and testing 
everything again, which takes days and it's not unattended work :( It 
could easily happen again if I depend on anything that stops compiling 
with this version of GHC because someone considers it "outdated" or does 
not have the resources to maintain two versions of his/her library.

Does that more or less answer your question?

Cheers

Ivan

PS. I do not use stack yet. So, I remain ignorant about that. I see how 
it could help in some cases, but not this one.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151020/8807454a/attachment.html>

From ivan.perez at keera.co.uk  Tue Oct 20 19:39:46 2015
From: ivan.perez at keera.co.uk (Ivan Perez)
Date: Tue, 20 Oct 2015 20:39:46 +0100
Subject: Taking a step back
In-Reply-To: <CAHZrzdoUeypkhB_jqbsUwGU2qG-hnAkweY0aNeMUm228+mQSJw@mail.gmail.com>
References: <CAK-tuPagavVPLLmGuU6015VkpQw9zLDtZRZPqxG8c4Uvsg6FVg@mail.gmail.com>
 <1445352338838-5820322.post@n5.nabble.com>
 <CAHZrzdoUeypkhB_jqbsUwGU2qG-hnAkweY0aNeMUm228+mQSJw@mail.gmail.com>
Message-ID: <56269882.508@keera.co.uk>

On 20/10/15 19:35, Gregory Collins wrote:
> On Tue, Oct 20, 2015 at 7:45 AM, Jeremy <voldermort at hotmail.com 
> <mailto:voldermort at hotmail.com>> wrote:
>
>     I'm interested in why you think recent changes are making Haskell
>     a less
>     viable alternative to mainstream languages.
>
>
> [...] Of course, these hypothetical productivity benefits are 
> extremely difficult to quantify (and Lord knows, we've tried), but 
> that's not at all true for the "con" arguments:
>
>   * how many Haskell programmers are there in industry? If I lose my
>     local expert who is trying to push us to use this thing, can I
>     hire another?
>   * how many lines of code are written in Haskell globally vs other
>     languages?
>   * how much tooling will I have available to help me if I choose
>     Haskell vs. a "safer" technology like Java, Python, or Go?
>   * how many open source libraries will I have available to me to
>     handle common tasks, and what is their quality?
>   * how likely am I to encounter bugs in the compiler or base libraries?
>
We actually get these questions from potential clients *all the time* 
(in particular, everyone asks 1 and 3). I don't always have a convincing 
answer.
> The point Johan is trying to make is this: if I'm thinking of using 
> Haskell, then I'm taking on a lot of project risk to get a 
> (hypothetical, difficult to quantify) X% productivity benefit. If 
> choosing it actually *costs* me a (real, obvious, easy to quantify) Y% 
> tax because I have to invest K hours every other quarter fixing all my 
> programs to cope with random/spurious changes in the ecosystem and 
> base libraries, then unless we can clearly convince people that X >> 
> Y, the rationale for choosing to use it is degraded or even nullified 
> altogether.
Not even that. Learning and some tooling costs can be amortized over 
time, but a regular and frequent cost tied to upgrades in the ecosystem 
may be really hard to estimate in advance. This makes profit, viability 
and deadlines, mid-term and long-term, really hard to estimate and 
fulfill. (I've also tried, and often failed.)

If clients (supervisors, project managers, <your company>) have *any* 
doubts that using the language may be cost-effective, they won't go for it.

Cheers

Ivan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151020/ba570c68/attachment.html>

From voldermort at hotmail.com  Tue Oct 20 19:55:06 2015
From: voldermort at hotmail.com (Jeremy)
Date: Tue, 20 Oct 2015 12:55:06 -0700 (MST)
Subject: 3 release policy
Message-ID: <1445370906741-5820363.post@n5.nabble.com>

A "3 release policy" has been recently mentioned several times, whereby it
should always be possible to write code that compiles with the last three
releases of GHC, without generating any -Wall warnings.

The no warning requirement seems excessively harsh. Will early warnings of
impending breakage really cause so much trouble that accepted proposals have
to be dragged out over several years to avoid them? If so, would a flag to
suppress the warnings suffice?

I should note that GHC has traditionally had no qualms about introducing new
warnings, on by default.



--
View this message in context: http://haskell.1045720.n5.nabble.com/3-release-policy-tp5820363.html
Sent from the Haskell - Libraries mailing list archive at Nabble.com.

From mwm at mired.org  Tue Oct 20 20:11:13 2015
From: mwm at mired.org (Mike Meyer)
Date: Tue, 20 Oct 2015 20:11:13 +0000
Subject: Taking a step back
In-Reply-To: <56269502.9090408@keera.co.uk>
References: <CAK-tuPagavVPLLmGuU6015VkpQw9zLDtZRZPqxG8c4Uvsg6FVg@mail.gmail.com>
 <1445352338838-5820322.post@n5.nabble.com>
 <CAHZrzdoUeypkhB_jqbsUwGU2qG-hnAkweY0aNeMUm228+mQSJw@mail.gmail.com>
 <CAD=7U2BQwYegQ5C+oMYnmxbe-CJmTqcdgcLYTPo7e_Wr9S=yBA@mail.gmail.com>
 <56269502.9090408@keera.co.uk>
Message-ID: <CAD=7U2ANC+7NQE072dMGc=XJ1ZYggBc8RejLQs7YK2GQfoxAyg@mail.gmail.com>

On Tue, Oct 20, 2015 at 2:24 PM Ivan Perez <ivan.perez at keera.co.uk> wrote:

> On 20/10/15 19:47, Mike Meyer wrote:
>
> On Tue, Oct 20, 2015 at 1:35 PM Gregory Collins <greg at gregorycollins.net>
> wrote:
>
>> The point Johan is trying to make is this: if I'm thinking of using
>> Haskell, then I'm taking on a lot of project risk to get a (hypothetical,
>> difficult to quantify) X% productivity benefit. If choosing it actually
>> *costs* me a (real, obvious, easy to quantify) Y% tax because I have to
>> invest K hours every other quarter fixing all my programs to cope with
>> random/spurious changes in the ecosystem and base libraries, then unless we
>> can clearly convince people that X >> Y, the rationale for choosing to use
>> it is degraded or even nullified altogether.
>>
>
> So I'll rephrase a question I asked earlier that never got an answer: if
> I'm developing a commercial project based on ghc and some ecosystem, what
> would possibly cause me to change either the ghc version or any part of the
> ecosystem every other quarter? Or ever, for that matter?
>
> I don't know about them, I can tell you my personal experience.
>
> If GHC and all libraries were perfect and free from bugs and ultimately
> optimized, then you'd be right: there would be no reason to change.
>
> But if you ever hit a bug in GHC or a library which was fixed in a future
> version, or if you want an improvement made to it, you may have to update
> the compiler.
>
> Library creators/maintainers do not always maintain their libraries
> compatible with very old/very new versions of the compiler. In an ecosystem
> like ours, with 3 versions of the compiler in use simultaneously, each with
> different language features and base APIs changed, compatibility requires a
> lot of work.
>
> This problem is transitive: if you depend on (a new version of a library
> that depends on)* a new version of base or a new language feature, you'll
> may have to update GHC. If you do not have the resources to backport those
> fixes and improvements, you'll be forced to update. In large projects you
> are likely to use hundreds of auxiliary libraries, so this is very likely
> to happen.
>
> I recently had to do this for one library because I could only compile it
> with a newer version of GHC. This project had 30K lines of Haskell split in
> dozens of libraries and a few commercial projects in production. It meant
> fixing, recompiling, packaging and testing everything again, which takes
> days and it's not unattended work :( It could easily happen again if I
> depend on anything that stops compiling with this version of GHC because
> someone considers it "outdated" or does not have the resources to maintain
> two versions of his/her library.
>
> Does that more or less answer your question?
>

Not really. IIUC, your fundamental complaint is that the cost of tracking
changes to the Haskell ecosystem outweighs any potential gains from using
Haskell. But the choices that lead you to needing to track those changes
don't make sense to me.

For instance, you talk about compatibility requiring a lot of work, which I
presume means between projects. Yes, having to swap out ecosystems and tool
sets when you change projects can be a PITA, but even maintaining the
environment by hand is less work than trying to keep all your projects
compatible across multiple environments. So why do that? Especially when
you have tools like virtual environments and stack to take away the pain of
multiple environments?

And yes, if some part of the ecosystem has a bug you have to get fixed and
an update will get the fix, that's one option. But it also comes with a
cost, in that you need to verify that it didn't introduce any new bugs
while fixing the old one. Plus, dealing with possible changes in the API.
And as you note, if that forces you to update some other part of the
ecosystem, all that work is transitive to those other parts. It indeed adds
up to a lot of work. Enough that I have to question that it's less work
than backporting a fix, or even developing a new one from scratch.

Over a couple of decades of building commercial projects in the P
languages,  when faced with the alternatives you outlined here, updating
anything major was never the choice if more than one  person was actively
writing code. Even with a language that put a priority on not breaking old
code in order to minimize the cost of doing that update.

Maybe there's something I'm missing about Haskell that makes fixing
somebody else's code take a lot more resources than it does in other
languages. In which case that, not the changing ecosystem, is the argument
against Haskell.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151020/9a5bf384/attachment-0001.html>

From greg at gregweber.info  Tue Oct 20 21:01:00 2015
From: greg at gregweber.info (Greg Weber)
Date: Tue, 20 Oct 2015 14:01:00 -0700
Subject: Taking a step back
In-Reply-To: <56269502.9090408@keera.co.uk>
References: <CAK-tuPagavVPLLmGuU6015VkpQw9zLDtZRZPqxG8c4Uvsg6FVg@mail.gmail.com>
 <1445352338838-5820322.post@n5.nabble.com>
 <CAHZrzdoUeypkhB_jqbsUwGU2qG-hnAkweY0aNeMUm228+mQSJw@mail.gmail.com>
 <CAD=7U2BQwYegQ5C+oMYnmxbe-CJmTqcdgcLYTPo7e_Wr9S=yBA@mail.gmail.com>
 <56269502.9090408@keera.co.uk>
Message-ID: <CAKRanNDg21Pxb-=57+DY=WSE59LCY0hvyXi1PnWhCmeL2DUhmg@mail.gmail.com>

stack and Travis CI make it easy for library authors to make sure their
libraries work across multiple versions of GHC. For users, it makes it
easier to install the newest version of GHC.

I have to say that I think very few people are choosing not to use Haskell
because there are breaking changes to the language.

In fact, this problem didn't register as a major concern in FPComplete's
survey
https://www.fpcomplete.com/blog/2015/05/thousand-user-haskell-survey

If anything new releases with improvements (breaking or not) get people
excited about using Haskell.
When people talk about stability, they are generally thinking about whether
the platform is buggy, and whether they can get a stack trace when there is
a bug, not about upgrade cycles. For new users, upgrade cycles tend to be
an afterthought.

The burden is placed on open-source library authors like Johan and myself.
In general we would like to spend our time on things that produce new value
and minimize spending time keeping things working how they are now. If you
don't even believe the change prompting this work tax is a useful one, I
can definitely see how it would be demoralizing. In my case I can say that
for the last GHC release, members of the community that started using the
pre-release contributed a lot of patches for the upgrades, so it actually
did not bother me too much. On the other hand, aeson's latest release with
unnecessary and undocumented breaking changes created hours of work for me
for absolutely no reason.
https://github.com/bos/aeson/pull/288

On Tue, Oct 20, 2015 at 12:24 PM, Ivan Perez <ivan.perez at keera.co.uk> wrote:

> On 20/10/15 19:47, Mike Meyer wrote:
>
> On Tue, Oct 20, 2015 at 1:35 PM Gregory Collins <greg at gregorycollins.net>
> wrote:
>
>> The point Johan is trying to make is this: if I'm thinking of using
>> Haskell, then I'm taking on a lot of project risk to get a (hypothetical,
>> difficult to quantify) X% productivity benefit. If choosing it actually
>> *costs* me a (real, obvious, easy to quantify) Y% tax because I have to
>> invest K hours every other quarter fixing all my programs to cope with
>> random/spurious changes in the ecosystem and base libraries, then unless we
>> can clearly convince people that X >> Y, the rationale for choosing to use
>> it is degraded or even nullified altogether.
>>
>
> So I'll rephrase a question I asked earlier that never got an answer: if
> I'm developing a commercial project based on ghc and some ecosystem, what
> would possibly cause me to change either the ghc version or any part of the
> ecosystem every other quarter? Or ever, for that matter?
>
> I don't know about them, I can tell you my personal experience.
>
> If GHC and all libraries were perfect and free from bugs and ultimately
> optimized, then you'd be right: there would be no reason to change.
>
> But if you ever hit a bug in GHC or a library which was fixed in a future
> version, or if you want an improvement made to it, you may have to update
> the compiler.
>
> Library creators/maintainers do not always maintain their libraries
> compatible with very old/very new versions of the compiler. In an ecosystem
> like ours, with 3 versions of the compiler in use simultaneously, each with
> different language features and base APIs changed, compatibility requires a
> lot of work.
>
> This problem is transitive: if you depend on (a new version of a library
> that depends on)* a new version of base or a new language feature, you'll
> may have to update GHC. If you do not have the resources to backport those
> fixes and improvements, you'll be forced to update. In large projects you
> are likely to use hundreds of auxiliary libraries, so this is very likely
> to happen.
>
> I recently had to do this for one library because I could only compile it
> with a newer version of GHC. This project had 30K lines of Haskell split in
> dozens of libraries and a few commercial projects in production. It meant
> fixing, recompiling, packaging and testing everything again, which takes
> days and it's not unattended work :( It could easily happen again if I
> depend on anything that stops compiling with this version of GHC because
> someone considers it "outdated" or does not have the resources to maintain
> two versions of his/her library.
>
> Does that more or less answer your question?
>
> Cheers
>
> Ivan
>
> PS. I do not use stack yet. So, I remain ignorant about that. I see how it
> could help in some cases, but not this one.
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151020/d24cf196/attachment.html>

From eir at cis.upenn.edu  Tue Oct 20 21:02:39 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Tue, 20 Oct 2015 17:02:39 -0400
Subject: 3 release policy
In-Reply-To: <1445370906741-5820363.post@n5.nabble.com>
References: <1445370906741-5820363.post@n5.nabble.com>
Message-ID: <C8A34CAA-7C55-4657-8286-16C46B3A6E27@cis.upenn.edu>

I share this concern. I think one way to keep folks happy is to have multiple tiers of warnings. Then library authors can aim to have their libraries warning-free up to some tier.

I wonder if part of the problem is that Haskell is optimized for programmers who prize beauty and cleanliness. Warnings are ugly! So our community avoids them at all cost... and that cost seems to have gotten too high. Engineering is sometimes dirty, and we shouldn't be ashamed of that.

Richard

On Oct 20, 2015, at 3:55 PM, Jeremy <voldermort at hotmail.com> wrote:

> A "3 release policy" has been recently mentioned several times, whereby it
> should always be possible to write code that compiles with the last three
> releases of GHC, without generating any -Wall warnings.
> 
> The no warning requirement seems excessively harsh. Will early warnings of
> impending breakage really cause so much trouble that accepted proposals have
> to be dragged out over several years to avoid them? If so, would a flag to
> suppress the warnings suffice?
> 
> I should note that GHC has traditionally had no qualms about introducing new
> warnings, on by default.
> 
> 
> 
> --
> View this message in context: http://haskell.1045720.n5.nabble.com/3-release-policy-tp5820363.html
> Sent from the Haskell - Libraries mailing list archive at Nabble.com.
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


From cma at bitemyapp.com  Tue Oct 20 21:06:34 2015
From: cma at bitemyapp.com (Christopher Allen)
Date: Tue, 20 Oct 2015 16:06:34 -0500
Subject: Taking a step back
In-Reply-To: <CAKRanNDg21Pxb-=57+DY=WSE59LCY0hvyXi1PnWhCmeL2DUhmg@mail.gmail.com>
References: <CAK-tuPagavVPLLmGuU6015VkpQw9zLDtZRZPqxG8c4Uvsg6FVg@mail.gmail.com>
 <1445352338838-5820322.post@n5.nabble.com>
 <CAHZrzdoUeypkhB_jqbsUwGU2qG-hnAkweY0aNeMUm228+mQSJw@mail.gmail.com>
 <CAD=7U2BQwYegQ5C+oMYnmxbe-CJmTqcdgcLYTPo7e_Wr9S=yBA@mail.gmail.com>
 <56269502.9090408@keera.co.uk>
 <CAKRanNDg21Pxb-=57+DY=WSE59LCY0hvyXi1PnWhCmeL2DUhmg@mail.gmail.com>
Message-ID: <CADnndOrw9wEGvJvHJsgXz6KK0RM7FksOVo3+Y1tQigr4+nm6oA@mail.gmail.com>

7.10 cost me an hour on a 60k loc project.

Aeson 0.10 (<3 you Bryan, but this was brutal) cost me a couple days on a
2k loc project and I'm still not totally satisfied with how things have
settled yet.

Going to concur with Greg here.


On Tue, Oct 20, 2015 at 4:01 PM, Greg Weber <greg at gregweber.info> wrote:

> stack and Travis CI make it easy for library authors to make sure their
> libraries work across multiple versions of GHC. For users, it makes it
> easier to install the newest version of GHC.
>
> I have to say that I think very few people are choosing not to use Haskell
> because there are breaking changes to the language.
>
> In fact, this problem didn't register as a major concern in FPComplete's
> survey
> https://www.fpcomplete.com/blog/2015/05/thousand-user-haskell-survey
>
> If anything new releases with improvements (breaking or not) get people
> excited about using Haskell.
> When people talk about stability, they are generally thinking about
> whether the platform is buggy, and whether they can get a stack trace when
> there is a bug, not about upgrade cycles. For new users, upgrade cycles
> tend to be an afterthought.
>
> The burden is placed on open-source library authors like Johan and myself.
> In general we would like to spend our time on things that produce new value
> and minimize spending time keeping things working how they are now. If you
> don't even believe the change prompting this work tax is a useful one, I
> can definitely see how it would be demoralizing. In my case I can say that
> for the last GHC release, members of the community that started using the
> pre-release contributed a lot of patches for the upgrades, so it actually
> did not bother me too much. On the other hand, aeson's latest release with
> unnecessary and undocumented breaking changes created hours of work for me
> for absolutely no reason.
> https://github.com/bos/aeson/pull/288
>
> On Tue, Oct 20, 2015 at 12:24 PM, Ivan Perez <ivan.perez at keera.co.uk>
> wrote:
>
>> On 20/10/15 19:47, Mike Meyer wrote:
>>
>> On Tue, Oct 20, 2015 at 1:35 PM Gregory Collins <greg at gregorycollins.net>
>> wrote:
>>
>>> The point Johan is trying to make is this: if I'm thinking of using
>>> Haskell, then I'm taking on a lot of project risk to get a (hypothetical,
>>> difficult to quantify) X% productivity benefit. If choosing it actually
>>> *costs* me a (real, obvious, easy to quantify) Y% tax because I have to
>>> invest K hours every other quarter fixing all my programs to cope with
>>> random/spurious changes in the ecosystem and base libraries, then unless we
>>> can clearly convince people that X >> Y, the rationale for choosing to use
>>> it is degraded or even nullified altogether.
>>>
>>
>> So I'll rephrase a question I asked earlier that never got an answer: if
>> I'm developing a commercial project based on ghc and some ecosystem, what
>> would possibly cause me to change either the ghc version or any part of the
>> ecosystem every other quarter? Or ever, for that matter?
>>
>> I don't know about them, I can tell you my personal experience.
>>
>> If GHC and all libraries were perfect and free from bugs and ultimately
>> optimized, then you'd be right: there would be no reason to change.
>>
>> But if you ever hit a bug in GHC or a library which was fixed in a future
>> version, or if you want an improvement made to it, you may have to update
>> the compiler.
>>
>> Library creators/maintainers do not always maintain their libraries
>> compatible with very old/very new versions of the compiler. In an ecosystem
>> like ours, with 3 versions of the compiler in use simultaneously, each with
>> different language features and base APIs changed, compatibility requires a
>> lot of work.
>>
>> This problem is transitive: if you depend on (a new version of a library
>> that depends on)* a new version of base or a new language feature, you'll
>> may have to update GHC. If you do not have the resources to backport those
>> fixes and improvements, you'll be forced to update. In large projects you
>> are likely to use hundreds of auxiliary libraries, so this is very likely
>> to happen.
>>
>> I recently had to do this for one library because I could only compile it
>> with a newer version of GHC. This project had 30K lines of Haskell split in
>> dozens of libraries and a few commercial projects in production. It meant
>> fixing, recompiling, packaging and testing everything again, which takes
>> days and it's not unattended work :( It could easily happen again if I
>> depend on anything that stops compiling with this version of GHC because
>> someone considers it "outdated" or does not have the resources to maintain
>> two versions of his/her library.
>>
>> Does that more or less answer your question?
>>
>> Cheers
>>
>> Ivan
>>
>> PS. I do not use stack yet. So, I remain ignorant about that. I see how
>> it could help in some cases, but not this one.
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>


-- 
Chris Allen
Currently working on http://haskellbook.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151020/0a92d249/attachment-0001.html>

From ekmett at gmail.com  Tue Oct 20 21:12:58 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Tue, 20 Oct 2015 17:12:58 -0400
Subject: 3 release policy
In-Reply-To: <C8A34CAA-7C55-4657-8286-16C46B3A6E27@cis.upenn.edu>
References: <1445370906741-5820363.post@n5.nabble.com>
 <C8A34CAA-7C55-4657-8286-16C46B3A6E27@cis.upenn.edu>
Message-ID: <CAJumaK8O7CiZt0+n1oKXzE6D35ZN-G3i-cLOo4ERi3sUbY45XQ@mail.gmail.com>

I think Herbert was proposing adding a -Wcompat flag to use to get all
warnings of known pending changes, even ones where action now can't be
taken without CPP.

e.g. for 8.0 this would include the warnings for the MonadFail proposal,
etc.

-Edward



On Tue, Oct 20, 2015 at 5:02 PM, Richard Eisenberg <eir at cis.upenn.edu>
wrote:

> I share this concern. I think one way to keep folks happy is to have
> multiple tiers of warnings. Then library authors can aim to have their
> libraries warning-free up to some tier.
>
> I wonder if part of the problem is that Haskell is optimized for
> programmers who prize beauty and cleanliness. Warnings are ugly! So our
> community avoids them at all cost... and that cost seems to have gotten too
> high. Engineering is sometimes dirty, and we shouldn't be ashamed of that.
>
> Richard
>
> On Oct 20, 2015, at 3:55 PM, Jeremy <voldermort at hotmail.com> wrote:
>
> > A "3 release policy" has been recently mentioned several times, whereby
> it
> > should always be possible to write code that compiles with the last three
> > releases of GHC, without generating any -Wall warnings.
> >
> > The no warning requirement seems excessively harsh. Will early warnings
> of
> > impending breakage really cause so much trouble that accepted proposals
> have
> > to be dragged out over several years to avoid them? If so, would a flag
> to
> > suppress the warnings suffice?
> >
> > I should note that GHC has traditionally had no qualms about introducing
> new
> > warnings, on by default.
> >
> >
> >
> > --
> > View this message in context:
> http://haskell.1045720.n5.nabble.com/3-release-policy-tp5820363.html
> > Sent from the Haskell - Libraries mailing list archive at Nabble.com.
> > _______________________________________________
> > Libraries mailing list
> > Libraries at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151020/19f3b874/attachment.html>

From tab at snarc.org  Tue Oct 20 21:23:28 2015
From: tab at snarc.org (Vincent Hanquez)
Date: Tue, 20 Oct 2015 22:23:28 +0100
Subject: 3 release policy
In-Reply-To: <CAJumaK8O7CiZt0+n1oKXzE6D35ZN-G3i-cLOo4ERi3sUbY45XQ@mail.gmail.com>
References: <1445370906741-5820363.post@n5.nabble.com>
 <C8A34CAA-7C55-4657-8286-16C46B3A6E27@cis.upenn.edu>
 <CAJumaK8O7CiZt0+n1oKXzE6D35ZN-G3i-cLOo4ERi3sUbY45XQ@mail.gmail.com>
Message-ID: <5626B0D0.9000909@snarc.org>



On 20/10/2015 22:12, Edward Kmett wrote:
> I think Herbert was proposing adding a -Wcompat flag to use to get all 
> warnings of known pending changes, even ones where action now can't be 
> taken without CPP.
>
> e.g. for 8.0 this would include the warnings for the MonadFail 
> proposal, etc.
Some other warnings like 'unused-imports' don't make much sense on by 
default with -Wall.
This warning is only useful for linting purpose, and clearly doesn't 
fall in the same category as other useful ones.

That would remove the need for a lot of CPP that got added in the 7.10 
era, like:

#if ...
import Control.Applicative
#end

-- 
Vincent

From johnw at newartisans.com  Tue Oct 20 22:42:07 2015
From: johnw at newartisans.com (John Wiegley)
Date: Tue, 20 Oct 2015 15:42:07 -0700
Subject: Taking a step back
In-Reply-To: <CAHZrzdoUeypkhB_jqbsUwGU2qG-hnAkweY0aNeMUm228+mQSJw@mail.gmail.com>
 (Gregory Collins's message of "Tue, 20 Oct 2015 11:35:20 -0700")
References: <CAK-tuPagavVPLLmGuU6015VkpQw9zLDtZRZPqxG8c4Uvsg6FVg@mail.gmail.com>
 <1445352338838-5820322.post@n5.nabble.com>
 <CAHZrzdoUeypkhB_jqbsUwGU2qG-hnAkweY0aNeMUm228+mQSJw@mail.gmail.com>
Message-ID: <m2io61tb5s.fsf@newartisans.com>

>>>>> Gregory Collins <greg at gregorycollins.net> writes:

> I have to invest K hours every other quarter fixing all my programs to cope
> with random/spurious changes in the ecosystem and base libraries

Doesn't this relate directly to which features you're using? I'd be interested
to know: since 1998, how many programs using only Haskell 98 have broken due
to recent changes?

John

From mainland at apeiron.net  Wed Oct 21 00:39:57 2015
From: mainland at apeiron.net (Geoffrey Mainland)
Date: Tue, 20 Oct 2015 20:39:57 -0400
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
Message-ID: <5626DEDD.8040202@apeiron.net>

I am also a -1, and I share Bryan's concerns.

What worries me most is that we have started to see very valuable
members of our community publicly state that they are reducing their
community involvement. While technical disagreement has something to do
with their decisions, I suspect that it is the /process/ by which these
decisions have been made that is pushing them away. Whatever our
individual stances on AMP/FTP/MRP, I hope we can all agree that any
process that has this effect needs a hard look.

I consider myself a member of the Haskell community, but like Henrik and
Graham, I have not actively followed the libraries list. I was take by
surprise by AMP. When FTP appeared, I didn't speak up because I felt the
outcome was inevitable. I should have spoken up nonetheless; I am
speaking up now.

In effect, only those who actively follow the libraries list have had a
voice in these decisions. Maybe that is what the community wants. I hope
not. How then can people like me (and Henrik and Graham) have a say
without committing to actively following the libraries list?

We have a method to solve this: elected representatives. Right now the
Core Libraries Committee elects its own members; perhaps it is time for
that to change.

Let me throw out a few straw man proposals.

Proposal 1: Move to community election of the members of the Core
Libraries Committee. Yes, I know this would have its own issues.

Proposal 2: After a suitable period of discussion on the libraries list,
the Core Libraries Committee will summarize the arguments for and
against a proposal and post it, along with a (justified) preliminary
decision, to a low-traffic, announce-only email list. After another
suitable period of discussion, they will issue a final decision. What is
a suitable period of time? Perhaps that depends on the properties of the
proposal, such as whether it breaks backwards compatibility.

Proposal 3: A decision regarding any proposal that significantly affects
backwards compatibility is within the purview of the Haskell Prime
Committee, not the Core Libraries Committee.

Now I am not saying I feel strongly that all (or any) of these proposals
should be enacted (in fleshed out form), but I do think they are all
worth discussing.

Cheers,
Geoff

On 10/05/2015 10:59 AM, Bryan O'Sullivan wrote:
> I would like to suggest that the bar for breaking all existing libraries, books, papers, and lecture notes should be very high; and that the benefit associated with such a breaking change should be correspondingly huge.
>
> This proposal falls far short of both bars, to the extent that I am astonished and disappointed it is being seriously discussed ? and to general approval, no less ? on a date other than April 1. Surely some design flaws have consequences so small that they are not worth fixing.
>
> I'll survive if it goes through, obviously, but it will commit me to a bunch of pointless make-work and compatibility ifdefs. I've previously expressed my sense that cross-version compatibility is a big tax on library maintainers. This proposal does not give me confidence that this cost is being taken seriously.
>
> Thanks,
> Bryan.
>
>> On Oct 5, 2015, at 7:32 AM, Gershom B <gershomb at gmail.com> wrote:
>>
>>> On October 5, 2015 at 6:00:00 AM, Simon Thompson (s.j.thompson at kent.ac.uk) wrote:
>>> Hello all. I write this to be a little provocative, but ?
>>>
>>> It?s really interesting to have this discussion, which pulls in all sorts of well-made  
>>> points about orthogonality, teaching, the evolution of the language and so on, but it  
>>> simply goes to show that the process of evolving Haskell is profoundly broken.
>>>
>>> Other languages do evolve, but in a managed and reflective way. Simply throwing in changes  
>>> that would have a profound impact on systems that are commercially and potentially safety  
>>> critical in an ? la carte, offhand, way seems like a breakdown of the collective responsibility  
>>> of the Haskell community to its users and, indirectly, to its future.
>> Hi Simon. I do in fact think this is provocative :-P
>>
>> I want to object here to your characterization of what has been going on as ?simply throwing in changes?. The proposal seems very well and carefully worked through to provide a good migration strategy, even planning to alter the source of GHC to ensure that adequate hints are given for the indefinite transition period.
>>
>> I also want to object to the idea that these changes would have ?a profound impact on systems?. As it stands, and I think this is an important criteria in any change, when ?phase 2? goes into affect, code that has compiled before may cease to compile until a minor change is made. However, code that continues to compile will continue to compile with the same behavior.
>>
>> Now as to process itself, this is a change to core libraries. It has been proposed on the libraries list, which seems appropriate, and a vigorous discussion has ensued. This seems like a pretty decent process to me thus far. Do you have a better one in mind?
>>
>> ?Gershom
>>
>> P.S. as a general point, I sympathize with concerns about breakage resulting from this, but I also think that the migration strategy proposed is good, and if people are concerned about breakage I think it would be useful if they could explain where they feel the migration strategy is insufficient to allay their concerns.


From mark.lentczner at gmail.com  Wed Oct 21 00:48:57 2015
From: mark.lentczner at gmail.com (Mark Lentczner)
Date: Tue, 20 Oct 2015 20:48:57 -0400
Subject: 3 release policy
In-Reply-To: <C8A34CAA-7C55-4657-8286-16C46B3A6E27@cis.upenn.edu>
References: <1445370906741-5820363.post@n5.nabble.com>
 <C8A34CAA-7C55-4657-8286-16C46B3A6E27@cis.upenn.edu>
Message-ID: <CAAOoiFZT6rpLYEhfEzGX3=VTyrn4XfnvqN7GZEq1SdMT7N6Rzg@mail.gmail.com>

On Tue, Oct 20, 2015 at 5:02 PM, Richard Eisenberg <eir at cis.upenn.edu>
wrote:

> I wonder if part of the problem is that Haskell is optimized for
> programmers who prize beauty and cleanliness. Warnings are ugly!


Pretty much every shop I've worked at for the last 30 years has had a "must
compile clean with no warnings" policy, no matter the language. The reason
is that as code bases get bigger and older, and gain engineers, it becomes
impossible to know which warnings are "oh yeah, just ignore that" and which
are "oh that's new, maybe we should look at it."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151020/1c77d4bd/attachment.html>

From qdunkan at gmail.com  Wed Oct 21 01:06:13 2015
From: qdunkan at gmail.com (Evan Laforge)
Date: Tue, 20 Oct 2015 18:06:13 -0700
Subject: 3 release policy
In-Reply-To: <CAAOoiFZT6rpLYEhfEzGX3=VTyrn4XfnvqN7GZEq1SdMT7N6Rzg@mail.gmail.com>
References: <1445370906741-5820363.post@n5.nabble.com>
 <C8A34CAA-7C55-4657-8286-16C46B3A6E27@cis.upenn.edu>
 <CAAOoiFZT6rpLYEhfEzGX3=VTyrn4XfnvqN7GZEq1SdMT7N6Rzg@mail.gmail.com>
Message-ID: <CACbaDy6UK235OnhpyV1=96cof5j6V2+tKEbv__DmsKsTpAD=bw@mail.gmail.com>

On Tue, Oct 20, 2015 at 5:48 PM, Mark Lentczner
<mark.lentczner at gmail.com> wrote:
> Pretty much every shop I've worked at for the last 30 years has had a "must
> compile clean with no warnings" policy, no matter the language. The reason

That's actually not true for java at google.  However, after warning
bankruptcy was declared, a small set were made into errors and the
rest suppressed.  So that supports the idea of categorizing warnings
into serious and advisory, and using -Werror only for serious ones.
Of course, choosing which ones are which is likely to be a wrangle.

In my personal code I do the same, that is try to make it warning free
but only enable warnings that I consider worthwhile.  It would also be
really nice to have pragmas to suppress warnings locally (e.g. ErrorT
deprecation warnings from transformers-4, which seem to be impossible
to fix without abandoning 7.8).

From simonpj at microsoft.com  Wed Oct 21 07:53:00 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 21 Oct 2015 07:53:00 +0000
Subject: 3 release policy
In-Reply-To: <CACbaDy6UK235OnhpyV1=96cof5j6V2+tKEbv__DmsKsTpAD=bw@mail.gmail.com>
References: <1445370906741-5820363.post@n5.nabble.com>
 <C8A34CAA-7C55-4657-8286-16C46B3A6E27@cis.upenn.edu>
 <CAAOoiFZT6rpLYEhfEzGX3=VTyrn4XfnvqN7GZEq1SdMT7N6Rzg@mail.gmail.com>
 <CACbaDy6UK235OnhpyV1=96cof5j6V2+tKEbv__DmsKsTpAD=bw@mail.gmail.com>
Message-ID: <cf09d114b9c64dab9ad73741d53941aa@DB4PR30MB030.064d.mgd.msft.net>

|  That's actually not true for java at google.  However, after warning
|  bankruptcy was declared, a small set were made into errors and the rest
|  suppressed.  So that supports the idea of categorizing warnings into serious
|  and advisory, and using -Werror only for serious ones.
|  Of course, choosing which ones are which is likely to be a wrangle.

Surely warning categorisation *must* be the way to go here.

Warnings vary a *lot* from things where I thought "something might be fishy here; I'd better tell the user", to "really something is almost certainly wrong, but it's legal Haskell so it can't be an error", to "this function is deprecated so at a convenient moment in the next year or two you'd better change it".

If all warnings are treated uniformly as errors that must be eliminated, the merit of having warnings, rather than outright errors, is greatly reduced.  And, speaking from the compiler-writer front, instead of thinking "someone might be interested, so I'll add an optional warning", I have to worry about whether I'm going to cause lots of busy-work for library authors.

Trouble is, any particular categorisation will be slightly wrong for almost everyone.  Would it help if any one organisation could list the warnings that it wanted to hear about (and then eliminate), put that in a .ghc file, OPTIONS pragma, or on the command line?  So, in effect, have a per-org warning categorisation.  (It would make for a very long command line.)

I'd love to find a way to make warnings more supple, less of a blunt instrument.  It hurts me that what is intended as a gentle hint actually ends up disrupting our entire ecosystem!

Simon

|  -----Original Message-----
|  From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of Evan
|  Laforge
|  Sent: 21 October 2015 02:06
|  To: Mark Lentczner
|  Cc: Haskell Libraries; Jeremy
|  Subject: Re: 3 release policy
|  
|  On Tue, Oct 20, 2015 at 5:48 PM, Mark Lentczner <mark.lentczner at gmail.com>
|  wrote:
|  > Pretty much every shop I've worked at for the last 30 years has had a
|  > "must compile clean with no warnings" policy, no matter the language.
|  > The reason
|  
|  That's actually not true for java at google.  However, after warning
|  bankruptcy was declared, a small set were made into errors and the rest
|  suppressed.  So that supports the idea of categorizing warnings into serious
|  and advisory, and using -Werror only for serious ones.
|  Of course, choosing which ones are which is likely to be a wrangle.
|  
|  In my personal code I do the same, that is try to make it warning free but
|  only enable warnings that I consider worthwhile.  It would also be really
|  nice to have pragmas to suppress warnings locally (e.g. ErrorT deprecation
|  warnings from transformers-4, which seem to be impossible to fix without
|  abandoning 7.8).
|  _______________________________________________
|  Libraries mailing list
|  Libraries at haskell.org
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell
|  .org%2fcgi-
|  bin%2fmailman%2flistinfo%2flibraries&data=01%7c01%7csimonpj%40064d.mgd.micro
|  soft.com%7cbb757c3c4d9740558e7e08d2d9b3dd3b%7c72f988bf86f141af91ab2d7cd011db
|  47%7c1&sdata=6n5N0v39UvgSakYhVRo92PKhtiSE2fK1kFF4fpkyzHs%3d

From lemming at henning-thielemann.de  Wed Oct 21 07:56:34 2015
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Wed, 21 Oct 2015 09:56:34 +0200 (CEST)
Subject: 3 release policy
In-Reply-To: <1445370906741-5820363.post@n5.nabble.com>
References: <1445370906741-5820363.post@n5.nabble.com>
Message-ID: <alpine.DEB.2.02.1510202210440.25133@sputnik>


On Tue, 20 Oct 2015, Jeremy wrote:

> A "3 release policy" has been recently mentioned several times, whereby it
> should always be possible to write code that compiles with the last three
> releases of GHC, without generating any -Wall warnings.
>
> The no warning requirement seems excessively harsh.

If you accept warnings in your code you always have to check which 
warnings are relevant and which ones you want to react on. Checking for no 
warnings is much simpler.

Actually, I don't pay attention to GHC-7.10 warnings anymore because there 
are so many irrelevant duplicate import warnings. I am not using GHC-7.10 
seriously, it has this intermediate flavour (also because of the type 
family problem I mentioned earlier). Thus the 3 release policy for me is 
already only a "2 usable releases policy".

Btw. I use every LTS version of Ubuntu full 4 years. 2 years is still too 
frequent change for me.

From michael at snoyman.com  Wed Oct 21 07:56:17 2015
From: michael at snoyman.com (Michael Snoyman)
Date: Wed, 21 Oct 2015 10:56:17 +0300
Subject: 3 release policy
In-Reply-To: <5626B0D0.9000909@snarc.org>
References: <1445370906741-5820363.post@n5.nabble.com>
 <C8A34CAA-7C55-4657-8286-16C46B3A6E27@cis.upenn.edu>
 <CAJumaK8O7CiZt0+n1oKXzE6D35ZN-G3i-cLOo4ERi3sUbY45XQ@mail.gmail.com>
 <5626B0D0.9000909@snarc.org>
Message-ID: <CAKA2JgJfdYfis3McYebMFXM9kZKzPnhLje3pWpjErWwBKtaqFQ@mail.gmail.com>

On Wed, Oct 21, 2015 at 12:23 AM, Vincent Hanquez <tab at snarc.org> wrote:

>
>
> On 20/10/2015 22:12, Edward Kmett wrote:
>
>> I think Herbert was proposing adding a -Wcompat flag to use to get all
>> warnings of known pending changes, even ones where action now can't be
>> taken without CPP.
>>
>> e.g. for 8.0 this would include the warnings for the MonadFail proposal,
>> etc.
>>
> Some other warnings like 'unused-imports' don't make much sense on by
> default with -Wall.
> This warning is only useful for linting purpose, and clearly doesn't fall
> in the same category as other useful ones.
>
> That would remove the need for a lot of CPP that got added in the 7.10
> era, like:
>
> #if ...
> import Control.Applicative
> #end
>
> --
> Vincent
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>


+1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151021/ff7e6809/attachment.html>

From lemming at henning-thielemann.de  Wed Oct 21 08:12:21 2015
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Wed, 21 Oct 2015 10:12:21 +0200 (CEST)
Subject: Taking a step back
In-Reply-To: <1445352338838-5820322.post@n5.nabble.com>
References: <CAK-tuPagavVPLLmGuU6015VkpQw9zLDtZRZPqxG8c4Uvsg6FVg@mail.gmail.com>
 <1445352338838-5820322.post@n5.nabble.com>
Message-ID: <alpine.DEB.2.02.1510211004250.25133@sputnik>


On Tue, 20 Oct 2015, Jeremy wrote:

> I'm interested in why you think recent changes are making Haskell a less
> viable alternative to mainstream languages. My experience is the opposite -
> beginners frequently ask "why is x not a superclass of y?" and "why does
> function a seem to be the same as b?", and are horrified to be told that
> it's for historical reasons (y existed before x, a existed before the more
> general b, etc.).

I would not explain it this way, not even to myself.

> This is a big anti-climax for someone coming from a "mainstream" 
> language, where type classes are all in the expected logical hierarchy, 
> and functions/types always have the most general constraints possible.

The most general type would be:
    f :: Anything a => a

and programs would read like f (f (f a) (f b)).

I don't think that the Traversable and Foldable functions in Prelude are 
the most general ones - what about using Arrow class instead of functions? 
If we always try to get the most general functions into Prelude we will 
get constant change but certainly not progress. The more general the types 
become the more type annotations you will need and the more mental type 
inference the reader of a program must perform. Prelude would tend to 
depend on the newest type extensions.

From Lennart.Augustsson at sc.com  Wed Oct 21 08:17:06 2015
From: Lennart.Augustsson at sc.com (Augustsson, Lennart)
Date: Wed, 21 Oct 2015 08:17:06 +0000
Subject: Taking a step back
In-Reply-To: <CAD=7U2BQwYegQ5C+oMYnmxbe-CJmTqcdgcLYTPo7e_Wr9S=yBA@mail.gmail.com>
References: <CAK-tuPagavVPLLmGuU6015VkpQw9zLDtZRZPqxG8c4Uvsg6FVg@mail.gmail.com>
 <1445352338838-5820322.post@n5.nabble.com>
 <CAHZrzdoUeypkhB_jqbsUwGU2qG-hnAkweY0aNeMUm228+mQSJw@mail.gmail.com>
 <CAD=7U2BQwYegQ5C+oMYnmxbe-CJmTqcdgcLYTPo7e_Wr9S=yBA@mail.gmail.com>
Message-ID: <22B950C955F8AB4196E72698FBD00002D02A21E5@UKWPISXMB01B.zone1.scb.net>

Since bug fixes are not back ported to all older versions you are sometimes forced to upgrade to avoid serious bugs.

From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of Mike Meyer
Sent: 20 October 2015 19:47
To: Gregory Collins; Jeremy
Cc: Haskell Libraries
Subject: Re: Taking a step back

On Tue, Oct 20, 2015 at 1:35 PM Gregory Collins <greg at gregorycollins.net<mailto:greg at gregorycollins.net>> wrote:
The point Johan is trying to make is this: if I'm thinking of using Haskell, then I'm taking on a lot of project risk to get a (hypothetical, difficult to quantify) X% productivity benefit. If choosing it actually costs me a (real, obvious, easy to quantify) Y% tax because I have to invest K hours every other quarter fixing all my programs to cope with random/spurious changes in the ecosystem and base libraries, then unless we can clearly convince people that X >> Y, the rationale for choosing to use it is degraded or even nullified altogether.

So I'll rephrase a question I asked earlier that never got an answer: if I'm developing a commercial project based on ghc and some ecosystem, what would possibly cause me to change either the ghc version or any part of the ecosystem every other quarter? Or ever, for that matter? I've never worked on  a commercial project that changed anything major mid-project, no matter what language it was using. As far as I'm concerned, one of the major features of stack is that it handles project-specific ecostystems cleanly and transparently.

This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at http://www.standardchartered.com/en/incorporation-details.html

Insofar as this communication contains any market commentary, the market commentary has been prepared by sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied for any other purpose, and is subject to the relevant disclaimers available at http://wholesalebanking.standardchartered.com/en/utility/Pages/d-mkt.aspx

Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign on the term sheet to acknowledge in respect of the same.

Please visit http://wholesalebanking.standardchartered.com/en/capabilities/financialmarkets/Pages/doddfrankdisclosures.aspx for important information with respect to derivative products.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151021/47c210a5/attachment.html>

From petr.mvd at gmail.com  Wed Oct 21 08:20:35 2015
From: petr.mvd at gmail.com (=?UTF-8?B?UGV0ciBQdWRsw6Fr?=)
Date: Wed, 21 Oct 2015 08:20:35 +0000
Subject: 3 release policy
In-Reply-To: <CACbaDy6UK235OnhpyV1=96cof5j6V2+tKEbv__DmsKsTpAD=bw@mail.gmail.com>
References: <1445370906741-5820363.post@n5.nabble.com>
 <C8A34CAA-7C55-4657-8286-16C46B3A6E27@cis.upenn.edu>
 <CAAOoiFZT6rpLYEhfEzGX3=VTyrn4XfnvqN7GZEq1SdMT7N6Rzg@mail.gmail.com>
 <CACbaDy6UK235OnhpyV1=96cof5j6V2+tKEbv__DmsKsTpAD=bw@mail.gmail.com>
Message-ID: <CABSda-cauDv+-G9j5cEmjnErdmRunPWyzjdQ6dCftExe3ZsBHg@mail.gmail.com>

+1 to be able to suppress warnings locally.

This would allow to suppress a warning that I know is OK at that place,
without suppressing the same kind of warnings elsewhere where they might be
important.

Dne st 21. 10. 2015 3:06 u?ivatel Evan Laforge <qdunkan at gmail.com> napsal:

> On Tue, Oct 20, 2015 at 5:48 PM, Mark Lentczner
> <mark.lentczner at gmail.com> wrote:
> > Pretty much every shop I've worked at for the last 30 years has had a
> "must
> > compile clean with no warnings" policy, no matter the language. The
> reason
>
> That's actually not true for java at google.  However, after warning
> bankruptcy was declared, a small set were made into errors and the
> rest suppressed.  So that supports the idea of categorizing warnings
> into serious and advisory, and using -Werror only for serious ones.
> Of course, choosing which ones are which is likely to be a wrangle.
>
> In my personal code I do the same, that is try to make it warning free
> but only enable warnings that I consider worthwhile.  It would also be
> really nice to have pragmas to suppress warnings locally (e.g. ErrorT
> deprecation warnings from transformers-4, which seem to be impossible
> to fix without abandoning 7.8).
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151021/71c85774/attachment-0001.html>

From Henrik.Nilsson at nottingham.ac.uk  Wed Oct 21 08:24:34 2015
From: Henrik.Nilsson at nottingham.ac.uk (Henrik Nilsson)
Date: Wed, 21 Oct 2015 09:24:34 +0100
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <5626DEDD.8040202@apeiron.net>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <5626DEDD.8040202@apeiron.net>
Message-ID: <56274BC2.20507@nottingham.ac.uk>

Hi all,

Geoffrey Mainland wrote;

 > What worries me most is that we have started to see very valuable
 > members of our community publicly state that they are reducing their
 > community involvement.

That worries me too. A lot. To quote myself from an earlier
e-mail in this thread:

 > Therefore, please let us defer further discussion and
 > ultimate decision on MRP to the resurrected
 > HaskellPrime committee, which is where it properly
 > belongs. Otherwise, the Haskell community itself might
 > be one of the things that MRP breaks.

Geoffrey further wrote:

 > Proposal 3: A decision regarding any proposal that significantly
 > affects backwards compatibility is within the purview of the Haskell
 > Prime Committee, not the Core Libraries Committee.

I thus definitely support this, at least for anything related to
the libraries covered by the Haskell report.

Indeed, I strongly suspect that many people who did not actively
follow the libraries discussions did so because they simply did not
think that changes to the central libraries as defined in the Haskell
report, at least not breaking changes, were in the remit of the
libraries committee, and were happy to leave discussions on any
other libraries to the users of those libraries. And as a consequence
they were taken by surprise by AMP etc.

So before breaking anything more, that being code, research papers,
books, what people have learned, or even the community itself, it is
time to very carefully think about what the appropriate processes
should be for going forward.

Best,

/Henrik

-- 
Henrik Nilsson
School of Computer Science
The University of Nottingham
nhn at cs.nott.ac.uk




This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it. 

Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.


From Lennart.Augustsson at sc.com  Wed Oct 21 08:28:11 2015
From: Lennart.Augustsson at sc.com (Augustsson, Lennart)
Date: Wed, 21 Oct 2015 08:28:11 +0000
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <56274BC2.20507@nottingham.ac.uk>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk>
Message-ID: <22B950C955F8AB4196E72698FBD00002D02A2259@UKWPISXMB01B.zone1.scb.net>

I'd say, of course, libraries covered by the Haskell report are not in the remit of the libraries committee.

-----Original Message-----
From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of Henrik Nilsson
Sent: 21 October 2015 09:25
To: Geoffrey Mainland; Bryan O'Sullivan; Gershom B
Cc: Henrik.Nilsson at nottingham.ac.uk; haskell-prime at haskell.org List; Graham Hutton; Haskell Libraries; haskell cafe
Subject: Re: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

Hi all,

Geoffrey Mainland wrote;

 > What worries me most is that we have started to see very valuable  > members of our community publicly state that they are reducing their  > community involvement.

That worries me too. A lot. To quote myself from an earlier e-mail in this thread:

 > Therefore, please let us defer further discussion and  > ultimate decision on MRP to the resurrected  > HaskellPrime committee, which is where it properly  > belongs. Otherwise, the Haskell community itself might  > be one of the things that MRP breaks.

Geoffrey further wrote:

 > Proposal 3: A decision regarding any proposal that significantly  > affects backwards compatibility is within the purview of the Haskell  > Prime Committee, not the Core Libraries Committee.

I thus definitely support this, at least for anything related to the libraries covered by the Haskell report.

Indeed, I strongly suspect that many people who did not actively follow the libraries discussions did so because they simply did not think that changes to the central libraries as defined in the Haskell report, at least not breaking changes, were in the remit of the libraries committee, and were happy to leave discussions on any other libraries to the users of those libraries. And as a consequence they were taken by surprise by AMP etc.

So before breaking anything more, that being code, research papers, books, what people have learned, or even the community itself, it is time to very carefully think about what the appropriate processes should be for going forward.

Best,

/Henrik

--
Henrik Nilsson
School of Computer Science
The University of Nottingham
nhn at cs.nott.ac.uk




This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it. 

Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.

_______________________________________________
Libraries mailing list
Libraries at haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at http://www.standardchartered.com/en/incorporation-details.html

Insofar as this communication contains any market commentary, the market commentary has been prepared by sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied for any other purpose, and is subject to the relevant disclaimers available at http://wholesalebanking.standardchartered.com/en/utility/Pages/d-mkt.aspx

Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign on the term sheet to acknowledge in respect of the same.

Please visit http://wholesalebanking.standardchartered.com/en/capabilities/financialmarkets/Pages/doddfrankdisclosures.aspx for important information with respect to derivative products.

From voldermort at hotmail.com  Wed Oct 21 09:33:57 2015
From: voldermort at hotmail.com (Jeremy)
Date: Wed, 21 Oct 2015 02:33:57 -0700 (MST)
Subject: Breaking Changes and Long Term Support Haskell
Message-ID: <1445420037768-5820429.post@n5.nabble.com>

There seems to be a fair amount of friction between those who want to
introduce new features or fix significant historical warts in the base
libraries - even if this requires breaking changes - and those who insist on
no significant breaking changes in new releases, regardless of the reason or
how much warning was given.

The rest of the industry has already solved this with long-term/extended
support releases. Some version of the platform is blessed with long-term
support, and will continue to receive bug fixes and security patches for a
number of years, but no other changes.

This solution exists for Haskell as well, in the form of Long-Term Support
Haskell (https://github.com/fpco/lts-haskell/blob/master/README.md) by FP
Complete. Not only GHC but an entire ecosystem of libraries are frozen when
a new LTS version is released and only bug/security fixes are allowed going
forward.

Users requiring long-term stability over new features could use LTS Haskell,
while those who accept some fixing up of old code to gain new features (or
remove old warts) can uses the latest GHC and Hackage.

The only deficiency I can see in this is that FP Complete don't seem to
provide any guarantees as to how long they will continue maintaining any LTS
release. However, this is only relevant to bug fixes which tend to taper off
after a while anyway - the actual release is available for perpetuity.
Perhaps they could provide a commercial service with guarantees of bug-fixes
for x years?



--
View this message in context: http://haskell.1045720.n5.nabble.com/Breaking-Changes-and-Long-Term-Support-Haskell-tp5820429.html
Sent from the Haskell - Libraries mailing list archive at Nabble.com.

From Henrik.Nilsson at nottingham.ac.uk  Wed Oct 21 10:16:30 2015
From: Henrik.Nilsson at nottingham.ac.uk (Henrik Nilsson)
Date: Wed, 21 Oct 2015 11:16:30 +0100
Subject: Breaking Changes and Long Term Support Haskell
In-Reply-To: <56274BC2.20507@nottingham.ac.uk>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk>
Message-ID: <562765FE.6070808@nottingham.ac.uk>

Hi all,

Jeremy wrote:

 > There seems to be a fair amount of friction between those who want to
 > introduce new features or fix significant historical warts in the base
 > libraries - even if this requires breaking changes - and those who
 > insist on no significant breaking changes in new releases, regardless
 > of the reason or how much warning was given.

With respect, and without commenting on the merits of the proposal that
is then outlined (Long-Term Support Haskell), I don't think this is
an accurate description of the two main positions in the debate at all.

Most of those who have argued against MRP, for example, have made it
very clear that they are not at all against any breaking change. But
they oppose breaking changes to Haskell itself, including central
libraries, as defined by the Haskell report, unless the benefits are
very compelling indeed.

Speaking for myself, I have had to clarify this position a number
of times now, as there has been a tendency by the some proponents of
the proposed changes to suggest that those who disagree are against
all changes, the long term implication being that Haskell would
"stagnate and die".

And in the light of the above, I felt compelled to clarify this
position again.

It's not about no more changes ever. It is about ensuring that
changes are truly worthwhile and have wide support.

Best,

/Henrik

-- 
Henrik Nilsson
School of Computer Science
The University of Nottingham
nhn at cs.nott.ac.uk




This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it. 

Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.


From Lennart.Augustsson at sc.com  Wed Oct 21 10:56:16 2015
From: Lennart.Augustsson at sc.com (Augustsson, Lennart)
Date: Wed, 21 Oct 2015 10:56:16 +0000
Subject: Breaking Changes and Long Term Support Haskell
In-Reply-To: <562765FE.6070808@nottingham.ac.uk>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk>
 <562765FE.6070808@nottingham.ac.uk>
Message-ID: <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net>

I'd like to vehemently agree with Henrik here. :)

Personally, I think AMP was the right thing to do, but I don't think FTP was the right thing.
And I don't think changes that break code are necessarily bad either, just some of them.

(To clarify, I'm against the Foldable class, but not Traversable.  It would have been quite feasible to have the latter, but not the former.)

  -- Lennart


-----Original Message-----
From: Haskell-prime [mailto:haskell-prime-bounces at haskell.org] On Behalf Of Henrik Nilsson
Sent: 21 October 2015 11:17
To: haskell-prime at haskell.org List; Haskell Libraries
Subject: Re: Breaking Changes and Long Term Support Haskell

Hi all,

Jeremy wrote:

 > There seems to be a fair amount of friction between those who want to  > introduce new features or fix significant historical warts in the base  > libraries - even if this requires breaking changes - and those who  > insist on no significant breaking changes in new releases, regardless  > of the reason or how much warning was given.

With respect, and without commenting on the merits of the proposal that is then outlined (Long-Term Support Haskell), I don't think this is an accurate description of the two main positions in the debate at all.

Most of those who have argued against MRP, for example, have made it very clear that they are not at all against any breaking change. But they oppose breaking changes to Haskell itself, including central libraries, as defined by the Haskell report, unless the benefits are very compelling indeed.

Speaking for myself, I have had to clarify this position a number of times now, as there has been a tendency by the some proponents of the proposed changes to suggest that those who disagree are against all changes, the long term implication being that Haskell would "stagnate and die".

And in the light of the above, I felt compelled to clarify this position again.

It's not about no more changes ever. It is about ensuring that changes are truly worthwhile and have wide support.

Best,

/Henrik

--
Henrik Nilsson
School of Computer Science
The University of Nottingham
nhn at cs.nott.ac.uk




This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it. 

Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.

_______________________________________________
Haskell-prime mailing list
Haskell-prime at haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at http://www.standardchartered.com/en/incorporation-details.html

Insofar as this communication contains any market commentary, the market commentary has been prepared by sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied for any other purpose, and is subject to the relevant disclaimers available at http://wholesalebanking.standardchartered.com/en/utility/Pages/d-mkt.aspx

Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign on the term sheet to acknowledge in respect of the same.

Please visit http://wholesalebanking.standardchartered.com/en/capabilities/financialmarkets/Pages/doddfrankdisclosures.aspx for important information with respect to derivative products.

From simonpj at microsoft.com  Wed Oct 21 11:30:30 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 21 Oct 2015 11:30:30 +0000
Subject: Breaking Changes and Long Term Support Haskell
In-Reply-To: <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk>
 <562765FE.6070808@nottingham.ac.uk>
 <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net>
Message-ID: <a2781834655f4e358b95c6c5fd53e2ac@DB4PR30MB030.064d.mgd.msft.net>

Friends

I think it's good for us to debate the question of how we should balance innovation against change; and how we should make those decisions in future.  Geoff's message had some good ideas, especially this bit:

|  Proposal 2: After a suitable period of discussion on the libraries list, the
|  Core Libraries Committee will summarize the arguments for and against a
|  proposal and post it, along with a (justified) preliminary decision, to a
|  low-traffic, announce-only email list. After another suitable period of
|  discussion, they will issue a final decision. What is a suitable period of
|  time? Perhaps that depends on the properties of the proposal, such as
|  whether it breaks backwards compatibility.

Identifying major changes to the libraries, and having a better publicised, more RFC-like process for deliberating them, would be a good thing.  I believe that the Core Libraries committee is thinking actively about this.

|  Personally, I think AMP was the right thing to do, but I don't think FTP was
|  the right thing.

These make good examples to motivate future changes to our process.  But in the end FTP was subject to a pretty broad deliberative process, precisely along the lines that Geoff suggests above.  We had two clearly-articulated alternatives, a discrete call for opinions broadcast to every Haskell channel we could find, a decent interval for people to respond, and (as it turned out) a very clear preponderance of opinion in one direction.  In a big community, even a broad consultation may yield a result that some think is ill-advised.  That's part of the joyful burden of being a big community.

Let's look forward, not back.  I think we can do better in future than we have done in the past.  I don't think we can hope for unanimity, but I think we can reasonably seek 

 * transparency; 
 * clarity about what decisions are on the table; 
 * broad consultation about decisions that affect 
    a broad constituency; and 
 * a decent opportunity to debate them without having 
    to be involved in massive email threads.  Let's try do to that.

Simon

PS: For what it's worth I'm less keen on Geoff's other proposal:

|  Proposal 3: A decision regarding any proposal that significantly affects
|  backwards compatibility is within the purview of the Haskell Prime
|  Committee, not the Core Libraries Committee.

*Precisely* the same issues will arise whether it's CLC or HPC.  And the HPC is going to be jolly busy with language issues. Moving the question from one group to another risks avoiding the issue rather than addressing it.

From evan at evanrutledgeborden.dreamhosters.com  Wed Oct 21 11:51:30 2015
From: evan at evanrutledgeborden.dreamhosters.com (evan@evan-borden.com)
Date: Wed, 21 Oct 2015 07:51:30 -0400
Subject: 3 release policy
In-Reply-To: <CABSda-cauDv+-G9j5cEmjnErdmRunPWyzjdQ6dCftExe3ZsBHg@mail.gmail.com>
References: <1445370906741-5820363.post@n5.nabble.com>
 <C8A34CAA-7C55-4657-8286-16C46B3A6E27@cis.upenn.edu>
 <CAAOoiFZT6rpLYEhfEzGX3=VTyrn4XfnvqN7GZEq1SdMT7N6Rzg@mail.gmail.com>
 <CACbaDy6UK235OnhpyV1=96cof5j6V2+tKEbv__DmsKsTpAD=bw@mail.gmail.com>
 <CABSda-cauDv+-G9j5cEmjnErdmRunPWyzjdQ6dCftExe3ZsBHg@mail.gmail.com>
Message-ID: <CABmRwSCFwY0ffaZQ57C8XsmuthTFOAVScHKoOqPQ=v7GjHOQ8A@mail.gmail.com>

> +1 to be able to suppress warnings locally.

Isn't this already possible with the OPTIONS_GHC pragma?

{-# OPTIONS_GHC -fnowarn-____ #-}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151021/1c4cfea3/attachment.html>

From hvriedel at gmail.com  Wed Oct 21 11:55:32 2015
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Wed, 21 Oct 2015 13:55:32 +0200
Subject: Committee M.O. Change Proposals (was: [Haskell-cafe] Monad of no
 `return` Proposal (MRP): Moving `return` out of `Monad`)
In-Reply-To: <5626DEDD.8040202@apeiron.net> (Geoffrey Mainland's message of
 "Tue, 20 Oct 2015 20:39:57 -0400")
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <5626DEDD.8040202@apeiron.net>
Message-ID: <87pp088mh7.fsf_-_@gmail.com>

Hello,

On 2015-10-21 at 02:39:57 +0200, Geoffrey Mainland wrote:

[...]

> In effect, only those who actively follow the libraries list have had a
> voice in these decisions. Maybe that is what the community wants. I hope
> not. How then can people like me (and Henrik and Graham) have a say
> without committing to actively following the libraries list?
>  
> We have a method to solve this: elected representatives. Right now the
> Core Libraries Committee elects its own members; perhaps it is time for
> that to change.

[...]

> Proposal 1: Move to community election of the members of the Core
> Libraries Committee. Yes, I know this would have its own issues.

How exactly do public elections of representatives address the problem
that some people feel left out? Have you considered nominating yourself
or somebody else you have confidence in for the core libraries
committee? You'd still have to find somebody to represent your
interests, regardless of whether the committee is self-elected or
direct-elected.

Here's some food for thought regarding language design by voting or its
indirect form via a directly elected language committee:

Back in February there was a large-scale survey which resulted (see [2]
for more details) in a rather unequivocal 4:1 majority *for* going
through with the otherwise controversial FTP implementation. If the
community elections would result in a similar spirit, you'd could easily
end up with a similarly 4:1 pro-change biased committee. Would you
consider that a well balanced committee formation?

> Proposal 2: After a suitable period of discussion on the libraries list,
> the Core Libraries Committee will summarize the arguments for and
> against a proposal and post it, along with a (justified) preliminary
> decision, to a low-traffic, announce-only email list. After another
> suitable period of discussion, they will issue a final decision. What is
> a suitable period of time? Perhaps that depends on the properties of the
> proposal, such as whether it breaks backwards compatibility.

That generally sounds like a good compromise, if this actually helps
reaching the otherwise unreachable parts of the community and have their
voices heard.

> Proposal 3: A decision regarding any proposal that significantly affects
> backwards compatibility is within the purview of the Haskell Prime
> Committee, not the Core Libraries Committee.

I don't see how that would change much. The prior Haskell Prime
Committee has been traditionally self-elected as well. So it's just the
label of the committee you'd swap out.

In the recent call of nominations[1] for Haskell Prime, the stated area
of work for the new nominations was to take care of the *language* part,
because that's what we are lacking the workforce for.

Since its creation for the very purpose of watching over the core
libraries, the core-libraries-committee has been almost exclusively busy
with evaluating and deciding about changes to the `base` library and
overseeing their implementation. Transferring this huge workload to the
new Haskell Prime committee members who have already their hands full
with revising the language part would IMO just achieve to reduce the
effectiveness of the upcoming Haskell Prime committee, and therefore
increase the risk of failure in producing an adequate new Haskell Report
revision.

Regards,
  H.V.Riedel

 [1]: https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html
 [2]: https://mail.haskell.org/pipermail/haskell-cafe/2015-February/118336.html

From adam at bergmark.nl  Wed Oct 21 12:13:10 2015
From: adam at bergmark.nl (Adam Bergmark)
Date: Wed, 21 Oct 2015 14:13:10 +0200
Subject: 3 release policy
In-Reply-To: <CABmRwSCFwY0ffaZQ57C8XsmuthTFOAVScHKoOqPQ=v7GjHOQ8A@mail.gmail.com>
References: <1445370906741-5820363.post@n5.nabble.com>
 <C8A34CAA-7C55-4657-8286-16C46B3A6E27@cis.upenn.edu>
 <CAAOoiFZT6rpLYEhfEzGX3=VTyrn4XfnvqN7GZEq1SdMT7N6Rzg@mail.gmail.com>
 <CACbaDy6UK235OnhpyV1=96cof5j6V2+tKEbv__DmsKsTpAD=bw@mail.gmail.com>
 <CABSda-cauDv+-G9j5cEmjnErdmRunPWyzjdQ6dCftExe3ZsBHg@mail.gmail.com>
 <CABmRwSCFwY0ffaZQ57C8XsmuthTFOAVScHKoOqPQ=v7GjHOQ8A@mail.gmail.com>
Message-ID: <CACnqJZZY6VMt+aKyHeMmjH4Oe207q9b3sLLRZWy=8Fpe2tDang@mail.gmail.com>

I think Petr was suggesting (either way, I am!) that you should be able to
suppress a warning for only one identifier, or only one location.

* I don't want to enable IncoherentInstances for my whole module because
then I might mess up, only for this one instance
* I don't want to allow all orphan instances, only this one instance
* I don't want to hide all possible future and past deprecation warnings, I
only want to mark this one identifier as ok for compatibility reasons

...  et.c.

Cheers,
Adam


On Wed, Oct 21, 2015 at 1:51 PM, evan at evan-borden.com <
evan at evanrutledgeborden.dreamhosters.com> wrote:

> > +1 to be able to suppress warnings locally.
>
> Isn't this already possible with the OPTIONS_GHC pragma?
>
> {-# OPTIONS_GHC -fnowarn-____ #-}
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151021/bc3ef534/attachment.html>

From voldermort at hotmail.com  Wed Oct 21 12:18:53 2015
From: voldermort at hotmail.com (Jeremy)
Date: Wed, 21 Oct 2015 05:18:53 -0700 (MST)
Subject: Breaking Changes and Long Term Support Haskell
In-Reply-To: <562765FE.6070808@nottingham.ac.uk>
References: <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk>
 <562765FE.6070808@nottingham.ac.uk>
Message-ID: <1445429933966-5820461.post@n5.nabble.com>

Henrik Nilsson-2 wrote
> Jeremy wrote:
> 
>  > There seems to be a fair amount of friction between those who want to
>  > introduce new features or fix significant historical warts in the base
>  > libraries - even if this requires breaking changes - and those who
>  > insist on no significant breaking changes in new releases, regardless
>  > of the reason or how much warning was given.
> 
> With respect, and without commenting on the merits of the proposal that
> is then outlined (Long-Term Support Haskell), I don't think this is
> an accurate description of the two main positions in the debate at all.
> 
> Most of those who have argued against MRP, for example, have made it
> very clear that they are not at all against any breaking change. But
> they oppose breaking changes to Haskell itself, including central
> libraries, as defined by the Haskell report, unless the benefits are
> very compelling indeed. 

With equal respect, I stopped following the MRP thread when its length
exceeded my interest, so my comments may not be applicable here :-)

The LTS solution should work as long as all (or at least a big enough
majority) agree that the benefits of a  change are desirable, but disagree
as to the cost of breaking change. It allows the "nice idea but don't keep
breaking my code" people to co-exist with the "nice idea let's do it"
people.



--
View this message in context: http://haskell.1045720.n5.nabble.com/Monad-of-no-return-Proposal-MRP-Moving-return-out-of-Monad-tp5818567p5820461.html
Sent from the Haskell - Libraries mailing list archive at Nabble.com.

From mwm at mired.org  Wed Oct 21 12:19:46 2015
From: mwm at mired.org (Mike Meyer)
Date: Wed, 21 Oct 2015 12:19:46 +0000
Subject: Committee M.O. Change Proposals (was: [Haskell-cafe] Monad of no
 `return` Proposal (MRP): Moving `return` out of `Monad`)
In-Reply-To: <87pp088mh7.fsf_-_@gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <5626DEDD.8040202@apeiron.net> <87pp088mh7.fsf_-_@gmail.com>
Message-ID: <CAD=7U2A441wVcuALshe5+PocQZ0gbmPay8Jv+tYr5=vYOknT2w@mail.gmail.com>

On Wed, Oct 21, 2015 at 6:56 AM Herbert Valerio Riedel <hvriedel at gmail.com>
wrote:

> > Proposal 1: Move to community election of the members of the Core
> > Libraries Committee. Yes, I know this would have its own issues.
> How exactly do public elections of representatives address the problem
> that some people feel left out?


The issue of people feeling left out is addressed by the second part of his
proposal, a low-volume (presumably announcements only) list where changes
that are being seriously considered can be announced, along with pointers
to the discussion areas. That way, the overhead of getting notices is near
zero, and everyone can then decide whether to invest time in the


> Back in February there was a large-scale survey which resulted (see [2]
> for more details) in a rather unequivocal 4:1 majority *for* going
> through with the otherwise controversial FTP implementation. If the
> community elections would result in a similar spirit, you'd could easily
> end up with a similarly 4:1 pro-change biased committee. Would you
> consider that a well balanced committee formation?


This shows two areas of confusion.

The first is that the point of representation isn't to be well-balanced, or
fair, or any such thing. it's to be representative of the community. Or at
least, of some aspect of the community.  Whether or not this is a problem
and how to fix it are hard political problems that I doubt we're going to
solve.

The second is that the composition of the committee matters beyond the
aspect they are supposed to represent. For instance, if the process doesn't
leave final decisions in the hands of the committee, but in a general vote
(just a for instance, not a proposal) then the balance or fairness of the
committee is irrelevant, so long as the community trusts them to administer
the process properly.

In other words, we need to figure out exactly what the job of the committee
is going to be before we start worrying about what kind of composition it
should have.

As for the issue of libraries vs. language, I think the same process should
apply to both, though it might be administered by different groups in order
to spread the workload around.

>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151021/43eb483d/attachment.html>

From voldermort at hotmail.com  Wed Oct 21 12:22:57 2015
From: voldermort at hotmail.com (Jeremy)
Date: Wed, 21 Oct 2015 05:22:57 -0700 (MST)
Subject: 3 release policy
In-Reply-To: <CACnqJZZY6VMt+aKyHeMmjH4Oe207q9b3sLLRZWy=8Fpe2tDang@mail.gmail.com>
References: <1445370906741-5820363.post@n5.nabble.com>
 <C8A34CAA-7C55-4657-8286-16C46B3A6E27@cis.upenn.edu>
 <CAAOoiFZT6rpLYEhfEzGX3=VTyrn4XfnvqN7GZEq1SdMT7N6Rzg@mail.gmail.com>
 <CACbaDy6UK235OnhpyV1=96cof5j6V2+tKEbv__DmsKsTpAD=bw@mail.gmail.com>
 <CABSda-cauDv+-G9j5cEmjnErdmRunPWyzjdQ6dCftExe3ZsBHg@mail.gmail.com>
 <CABmRwSCFwY0ffaZQ57C8XsmuthTFOAVScHKoOqPQ=v7GjHOQ8A@mail.gmail.com>
 <CACnqJZZY6VMt+aKyHeMmjH4Oe207q9b3sLLRZWy=8Fpe2tDang@mail.gmail.com>
Message-ID: <1445430177247-5820464.post@n5.nabble.com>

.NET has a very flexible system for suppressing code analysis warnings, it
may be informative for formulating a GHC solution.

https://msdn.microsoft.com/en-us/library/ms244717.aspx



--
View this message in context: http://haskell.1045720.n5.nabble.com/3-release-policy-tp5820363p5820464.html
Sent from the Haskell - Libraries mailing list archive at Nabble.com.

From mainland at apeiron.net  Wed Oct 21 12:31:18 2015
From: mainland at apeiron.net (Geoffrey Mainland)
Date: Wed, 21 Oct 2015 08:31:18 -0400
Subject: Committee M.O. Change Proposals
In-Reply-To: <87pp088mh7.fsf_-_@gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <5626DEDD.8040202@apeiron.net> <87pp088mh7.fsf_-_@gmail.com>
Message-ID: <56278596.9070005@apeiron.net>

On 10/21/2015 07:55 AM, Herbert Valerio Riedel wrote:
> Hello, > > On 2015-10-21 at 02:39:57 +0200, Geoffrey Mainland wrote: > > [...]
> >> In effect, only those who actively follow the libraries list have
had a >> voice in these decisions. Maybe that is what the community
wants. I hope >> not. How then can people like me (and Henrik and
Graham) have a say >> without committing to actively following the
libraries list? >>  >> We have a method to solve this: elected
representatives. Right now the >> Core Libraries Committee elects its
own members; perhaps it is time for >> that to change. > > [...] > >>
Proposal 1: Move to community election of the members of the Core >>
Libraries Committee. Yes, I know this would have its own issues. > > How
exactly do public elections of representatives address the problem >
that some people feel left out? Have you considered nominating yourself
> or somebody else you have confidence in for the core libraries >
committee? You'd still have to find somebody to represent your >
interests, regardless of whether the committee is self-elected or >
direct-elected. > > Here's some food for thought regarding language
design by voting or its > indirect form via a directly elected language
committee: > > Back in February there was a large-scale survey which
resulted (see [2] > for more details) in a rather unequivocal 4:1
majority *for* going > through with the otherwise controversial FTP
implementation. If the > community elections would result in a similar
spirit, you'd could easily > end up with a similarly 4:1 pro-change
biased committee. Would you > consider that a well balanced committee
formation?

Thanks, all good points.

It is quite possible that direct elections would produce the exact same
committee. I wouldn't see that as a negative outcome at all! At least
that committee would have been put in place by direct election; I would
see that as strengthening their mandate.

I am very much aware of the February survey. I wonder if Proposal 2, had
it been in place at the time, would have increased participation in the
survey.

The recent kerfuffle has caught the attention of many people who don't
normally follow the libraries list. Proposal 1 is an attempt to give
them a voice. Yes, they would still need to find a candidate to
represent their interests. If we moved to direct elections, I would
consider running. However, my preference is that Proposal 3 go through
in some form, in which case my main concern would be the Haskell Prime
committee, and unfortunately nominations for that committee have already
closed.

>> Proposal 2: After a suitable period of discussion on the libraries list, >> the Core Libraries Committee will summarize the arguments for and >>
against a proposal and post it, along with a (justified) preliminary >>
decision, to a low-traffic, announce-only email list. After another >>
suitable period of discussion, they will issue a final decision. What is
>> a suitable period of time? Perhaps that depends on the properties of
the >> proposal, such as whether it breaks backwards compatibility. > >
That generally sounds like a good compromise, if this actually helps >
reaching the otherwise unreachable parts of the community and have their
> voices heard.

My hope is that a low-volume mailing list would indeed reach a wider
audience.

>> Proposal 3: A decision regarding any proposal that significantly affects >> backwards compatibility is within the purview of the Haskell Prime
>> Committee, not the Core Libraries Committee. > > I don't see how that
would change much. The prior Haskell Prime > Committee has been
traditionally self-elected as well. So it's just the > label of the
committee you'd swap out. > > In the recent call of nominations[1] for
Haskell Prime, the stated area > of work for the new nominations was to
take care of the *language* part, > because that's what we are lacking
the workforce for. > > Since its creation for the very purpose of
watching over the core > libraries, the core-libraries-committee has
been almost exclusively busy > with evaluating and deciding about
changes to the `base` library and > overseeing their implementation.
Transferring this huge workload to the > new Haskell Prime committee
members who have already their hands full > with revising the language
part would IMO just achieve to reduce the > effectiveness of the
upcoming Haskell Prime committee, and therefore > increase the risk of
failure in producing an adequate new Haskell Report > revision.

My understanding is that much of the work of the core libraries
committee does not "significantly affect backwards compatibility," at
least not to the extent that MRP does. If this is the case, the bulk of
their workload would not be transferred to the new Haskell Prime
committee. Is my understanding incorrect?

The intent of Proposal 3 was to transfer only a small fraction of the
issues that come before the core libraries committee to the Haskell
Prime committee. In any case, we would certainly need to clarify what
"significantly affects backwards compatibility" means.

Perhaps we should consider direct elections for the Haskell Prime
committee as well as changing their mandate to include some subset of
the changes proposed to libraries covered by the Haskell Report. My
understanding of the current state of affairs is that the Haskell Prime
committee is charged with producing a new report, but the core libraries
committee is in charge of the library part of that report. Is that
correct?

Cheers,
Geoff

> Regards, >   H.V.Riedel > >  [1]:
https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html
>  [2]:
https://mail.haskell.org/pipermail/haskell-cafe/2015-February/118336.html



From ky3 at atamo.com  Wed Oct 21 12:32:50 2015
From: ky3 at atamo.com (Kim-Ee Yeoh)
Date: Wed, 21 Oct 2015 19:32:50 +0700
Subject: Breaking Changes and Long Term Support Haskell
In-Reply-To: <1445429933966-5820461.post@n5.nabble.com>
References: <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk>
 <562765FE.6070808@nottingham.ac.uk> <1445429933966-5820461.post@n5.nabble.com>
Message-ID: <CAPY+ZdSF1b=v22YO1W2LgwJiQTMDEMgaeZMX92m=4N33NgLnQg@mail.gmail.com>

On Wed, Oct 21, 2015 at 7:18 PM, Jeremy <voldermort at hotmail.com> wrote:

> The LTS solution should work as long as all (or at least a big enough
> majority) agree that the benefits of a  change are desirable, but disagree
> as to the cost of breaking change. It allows the "nice idea but don't keep
> breaking my code" people to co-exist with the "nice idea let's do it"
> people.
>

But as Henrik and Lennart have alluded to, what we have currently is
friction between "half-baked idea, I'll fight against it" and "nice idea,
this is the way to progress."

LTS, seen in this light, is a discussion-postponing move.

What's needed is a "let's agree to disagree and have a long, deep
discussion to understand one another", not "let's agree to disagree. Here's
software for you. And here's software for me. Bye-bye."

-- Kim-Ee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151021/b8c7da7e/attachment-0001.html>

From voldermort at hotmail.com  Wed Oct 21 12:39:30 2015
From: voldermort at hotmail.com (Jeremy)
Date: Wed, 21 Oct 2015 05:39:30 -0700 (MST)
Subject: Breaking Changes and Long Term Support Haskell
In-Reply-To: <CAPY+ZdSF1b=v22YO1W2LgwJiQTMDEMgaeZMX92m=4N33NgLnQg@mail.gmail.com>
References: <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk>
 <562765FE.6070808@nottingham.ac.uk>
 <1445429933966-5820461.post@n5.nabble.com>
 <CAPY+ZdSF1b=v22YO1W2LgwJiQTMDEMgaeZMX92m=4N33NgLnQg@mail.gmail.com>
Message-ID: <1445431170772-5820476.post@n5.nabble.com>

Kim-Ee Yeoh wrote
> But as Henrik and Lennart have alluded to, what we have currently is
> friction between "half-baked idea, I'll fight against it" and "nice idea,
> this is the way to progress."
> 
> LTS, seen in this light, is a discussion-postponing move.
> 
> What's needed is a "let's agree to disagree and have a long, deep
> discussion to understand one another", not "let's agree to disagree.
> Here's
> software for you. And here's software for me. Bye-bye."

Indeed, LTS is only relevant after a proposal has been agreed upon in
principle, and the only issue is whether it's worth a breaking change. AMP
may be a good example of where this would help.



--
View this message in context: http://haskell.1045720.n5.nabble.com/Monad-of-no-return-Proposal-MRP-Moving-return-out-of-Monad-tp5818567p5820476.html
Sent from the Haskell - Libraries mailing list archive at Nabble.com.

From mhoermann at gmail.com  Wed Oct 21 12:48:25 2015
From: mhoermann at gmail.com (=?UTF-8?Q?Matthias_H=C3=B6rmann?=)
Date: Wed, 21 Oct 2015 14:48:25 +0200
Subject: Breaking Changes and Long Term Support Haskell
In-Reply-To: <1445431170772-5820476.post@n5.nabble.com>
References: <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk>
 <562765FE.6070808@nottingham.ac.uk>
 <1445429933966-5820461.post@n5.nabble.com>
 <CAPY+ZdSF1b=v22YO1W2LgwJiQTMDEMgaeZMX92m=4N33NgLnQg@mail.gmail.com>
 <1445431170772-5820476.post@n5.nabble.com>
Message-ID: <CABSPmx2PHiYcxT2-T1DQyEfwR8tiRKrKp1po+aDvQ6prySA=Fw@mail.gmail.com>

It might also be relevant to note that any LTS release will lead to even
more surprises about things that happened in the more regular releases
and a correspondingly reduced influence on the direction of Haskell for those
who only use the LTS releases and do not pay attention to the language
or library changes in the regular releases in between two LTS releases.

From voldermort at hotmail.com  Wed Oct 21 12:57:16 2015
From: voldermort at hotmail.com (Jeremy)
Date: Wed, 21 Oct 2015 05:57:16 -0700 (MST)
Subject: Breaking Changes and Long Term Support Haskell
In-Reply-To: <CABSPmx2PHiYcxT2-T1DQyEfwR8tiRKrKp1po+aDvQ6prySA=Fw@mail.gmail.com>
References: <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk>
 <562765FE.6070808@nottingham.ac.uk>
 <1445429933966-5820461.post@n5.nabble.com>
 <CAPY+ZdSF1b=v22YO1W2LgwJiQTMDEMgaeZMX92m=4N33NgLnQg@mail.gmail.com>
 <1445431170772-5820476.post@n5.nabble.com>
 <CABSPmx2PHiYcxT2-T1DQyEfwR8tiRKrKp1po+aDvQ6prySA=Fw@mail.gmail.com>
Message-ID: <1445432236056-5820478.post@n5.nabble.com>

My rationale for proposing LTS as a solution is that this is the model which
enterprise users have already adopted this for other technologies, despite
the big jump between releases. I'm not theorising about a proposition which
may work for users seeking long-term stability, I'm describing the solution
which they're already using and happy with for other technologies.



--
View this message in context: http://haskell.1045720.n5.nabble.com/Monad-of-no-return-Proposal-MRP-Moving-return-out-of-Monad-tp5818567p5820478.html
Sent from the Haskell - Libraries mailing list archive at Nabble.com.

From mainland at apeiron.net  Wed Oct 21 13:27:22 2015
From: mainland at apeiron.net (Geoffrey Mainland)
Date: Wed, 21 Oct 2015 09:27:22 -0400
Subject: Committee M.O. Change Proposals
In-Reply-To: <87pp088mh7.fsf_-_@gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <5626DEDD.8040202@apeiron.net> <87pp088mh7.fsf_-_@gmail.com>
Message-ID: <562792BA.9000908@apeiron.net>

Apologies for the previous mailer-mangled "draft"...

On 10/21/2015 07:55 AM, Herbert Valerio Riedel wrote:
> Hello,
>
> On 2015-10-21 at 02:39:57 +0200, Geoffrey Mainland wrote:
>
> [...]
>
>> In effect, only those who actively follow the libraries list have had a
>> voice in these decisions. Maybe that is what the community wants. I hope
>> not. How then can people like me (and Henrik and Graham) have a say
>> without committing to actively following the libraries list?
>>  
>> We have a method to solve this: elected representatives. Right now the
>> Core Libraries Committee elects its own members; perhaps it is time for
>> that to change.
> [...]
>
>> Proposal 1: Move to community election of the members of the Core
>> Libraries Committee. Yes, I know this would have its own issues.
> How exactly do public elections of representatives address the problem
> that some people feel left out? Have you considered nominating yourself
> or somebody else you have confidence in for the core libraries
> committee? You'd still have to find somebody to represent your
> interests, regardless of whether the committee is self-elected or
> direct-elected.
>
> Here's some food for thought regarding language design by voting or its
> indirect form via a directly elected language committee:
>
> Back in February there was a large-scale survey which resulted (see [2]
> for more details) in a rather unequivocal 4:1 majority *for* going
> through with the otherwise controversial FTP implementation. If the
> community elections would result in a similar spirit, you'd could easily
> end up with a similarly 4:1 pro-change biased committee. Would you
> consider that a well balanced committee formation?

Thanks, all good points.

It is quite possible that direct elections would produce the exact same
committee. I wouldn't see that as a negative outcome at all! At least
that committee would have been put in place by direct election; I would
see that as strengthening their mandate.

I am very much aware of the February survey. I wonder if Proposal 2, had
it been in place at the time, would have increased participation in the
survey.

The recent kerfuffle has caught the attention of many people who don't
normally follow the libraries list. Proposal 1 is an attempt to give
them a voice. Yes, they would still need to find a candidate to
represent their interests. If we moved to direct elections, I would
consider running. However, my preference is that Proposal 3 go through
in some form, in which case my main concern would be the Haskell Prime
committee, and unfortunately nominations for that committee have already
closed.

>> Proposal 2: After a suitable period of discussion on the libraries list,
>> the Core Libraries Committee will summarize the arguments for and
>> against a proposal and post it, along with a (justified) preliminary
>> decision, to a low-traffic, announce-only email list. After another
>> suitable period of discussion, they will issue a final decision. What is
>> a suitable period of time? Perhaps that depends on the properties of the
>> proposal, such as whether it breaks backwards compatibility.
> That generally sounds like a good compromise, if this actually helps
> reaching the otherwise unreachable parts of the community and have their
> voices heard.

My hope is that a low-volume mailing list would indeed reach a wider
audience.

>> Proposal 3: A decision regarding any proposal that significantly affects
>> backwards compatibility is within the purview of the Haskell Prime
>> Committee, not the Core Libraries Committee.
> I don't see how that would change much. The prior Haskell Prime
> Committee has been traditionally self-elected as well. So it's just the
> label of the committee you'd swap out.
>
> In the recent call of nominations[1] for Haskell Prime, the stated area
> of work for the new nominations was to take care of the *language* part,
> because that's what we are lacking the workforce for.
>
> Since its creation for the very purpose of watching over the core
> libraries, the core-libraries-committee has been almost exclusively busy
> with evaluating and deciding about changes to the `base` library and
> overseeing their implementation. Transferring this huge workload to the
> new Haskell Prime committee members who have already their hands full
> with revising the language part would IMO just achieve to reduce the
> effectiveness of the upcoming Haskell Prime committee, and therefore
> increase the risk of failure in producing an adequate new Haskell Report
> revision.

My understanding is that much of the work of the core libraries
committee does not "significantly affect backwards compatibility," at
least not to the extent that MRP does. If this is the case, the bulk of
their workload would not be transferred to the new Haskell Prime
committee. Is my understanding incorrect?

The intent of Proposal 3 was to transfer only a small fraction of the
issues that come before the core libraries committee to the Haskell
Prime committee. In any case, we would certainly need to clarify what
"significantly affects backwards compatibility" means.

Perhaps we should consider direct elections for the Haskell Prime
committee as well as changing their mandate to include some subset of
the changes proposed to libraries covered by the Haskell Report. My
understanding of the current state of affairs is that the Haskell Prime
committee is charged with producing a new report, but the core libraries
committee is in charge of the library part of that report. Is that correct?

Cheers,
Geoff

> Regards,
>   H.V.Riedel
>
>  [1]: https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html
>  [2]: https://mail.haskell.org/pipermail/haskell-cafe/2015-February/118336.html
>


From thomasmiedema at gmail.com  Wed Oct 21 13:27:25 2015
From: thomasmiedema at gmail.com (Thomas Miedema)
Date: Wed, 21 Oct 2015 15:27:25 +0200
Subject: 3 release policy
In-Reply-To: <CACnqJZZY6VMt+aKyHeMmjH4Oe207q9b3sLLRZWy=8Fpe2tDang@mail.gmail.com>
References: <1445370906741-5820363.post@n5.nabble.com>
 <C8A34CAA-7C55-4657-8286-16C46B3A6E27@cis.upenn.edu>
 <CAAOoiFZT6rpLYEhfEzGX3=VTyrn4XfnvqN7GZEq1SdMT7N6Rzg@mail.gmail.com>
 <CACbaDy6UK235OnhpyV1=96cof5j6V2+tKEbv__DmsKsTpAD=bw@mail.gmail.com>
 <CABSda-cauDv+-G9j5cEmjnErdmRunPWyzjdQ6dCftExe3ZsBHg@mail.gmail.com>
 <CABmRwSCFwY0ffaZQ57C8XsmuthTFOAVScHKoOqPQ=v7GjHOQ8A@mail.gmail.com>
 <CACnqJZZY6VMt+aKyHeMmjH4Oe207q9b3sLLRZWy=8Fpe2tDang@mail.gmail.com>
Message-ID: <CAD3WKgjKGBShZfaf0Lea31JjWNstMypOYSP147PWWJ8ra-nCpA@mail.gmail.com>

On Wed, Oct 21, 2015 at 2:13 PM, Adam Bergmark <adam at bergmark.nl> wrote:

> I think Petr was suggesting (either way, I am!) that you should be able to
> suppress a warning for only one identifier, or only one location.
>

See https://ghc.haskell.org/trac/ghc/ticket/602 ("Warning Suppression").
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151021/9e1d7a6f/attachment.html>

From mainland at apeiron.net  Wed Oct 21 14:43:52 2015
From: mainland at apeiron.net (Geoffrey Mainland)
Date: Wed, 21 Oct 2015 10:43:52 -0400
Subject: Breaking Changes and Long Term Support Haskell
In-Reply-To: <a2781834655f4e358b95c6c5fd53e2ac@DB4PR30MB030.064d.mgd.msft.net>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk>
 <562765FE.6070808@nottingham.ac.uk>
 <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net>
 <a2781834655f4e358b95c6c5fd53e2ac@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <5627A4A8.7070107@apeiron.net>

On 10/21/2015 07:30 AM, Simon Peyton Jones wrote:
> Friends
>
> I think it's good for us to debate the question of how we should balance innovation against change; and how we should make those decisions in future.  Geoff's message had some good ideas, especially this bit:
>
> |  Proposal 2: After a suitable period of discussion on the libraries list, the
> |  Core Libraries Committee will summarize the arguments for and against a
> |  proposal and post it, along with a (justified) preliminary decision, to a
> |  low-traffic, announce-only email list. After another suitable period of
> |  discussion, they will issue a final decision. What is a suitable period of
> |  time? Perhaps that depends on the properties of the proposal, such as
> |  whether it breaks backwards compatibility.
>
> Identifying major changes to the libraries, and having a better publicised, more RFC-like process for deliberating them, would be a good thing.  I believe that the Core Libraries committee is thinking actively about this.
>
> |  Personally, I think AMP was the right thing to do, but I don't think FTP was
> |  the right thing.
>
> These make good examples to motivate future changes to our process.  But in the end FTP was subject to a pretty broad deliberative process, precisely along the lines that Geoff suggests above.  We had two clearly-articulated alternatives, a discrete call for opinions broadcast to every Haskell channel we could find, a decent interval for people to respond, and (as it turned out) a very clear preponderance of opinion in one direction.  In a big community, even a broad consultation may yield a result that some think is ill-advised.  That's part of the joyful burden of being a big community.
>
> Let's look forward, not back.  I think we can do better in future than we have done in the past.  I don't think we can hope for unanimity, but I think we can reasonably seek 
>
>  * transparency; 
>  * clarity about what decisions are on the table; 
>  * broad consultation about decisions that affect 
>     a broad constituency; and 
>  * a decent opportunity to debate them without having 
>     to be involved in massive email threads.  Let's try do to that.
>
> Simon
>
> PS: For what it's worth I'm less keen on Geoff's other proposal:
>
> |  Proposal 3: A decision regarding any proposal that significantly affects
> |  backwards compatibility is within the purview of the Haskell Prime
> |  Committee, not the Core Libraries Committee.
>
> *Precisely* the same issues will arise whether it's CLC or HPC.  And the HPC is going to be jolly busy with language issues. Moving the question from one group to another risks avoiding the issue rather than addressing it.

For the record, I am also not sure Proposal 3 is a good idea :)

However, I do think we could clarify what the respective
responsibilities of the core libraries committee and Haskell Prime
committees are.

One possible choice is that the core libraries committee is responsible
for changes to the core libraries that do not affect libraries in the
report. It is meant to be nimble, able to quickly deal with the large
volume of library changes that do not impact backwards compatibility.

In this scenario, the Haskell Prime committee, using a longer
deliberative process, would consider the more impactful library changes
and batch them up into new reports.

You are absolutely correct that moving the question to the Haskell Prime
committee risks pushing the issue around. The idea behind the separation
outlined above is to reduce the treadmill; the two bodies use different
processes, with different time frames, to arrive at decisions. Some
library decisions may deserve a longer deliberative process.

Cheers,
Geoff

From evan at evanrutledgeborden.dreamhosters.com  Wed Oct 21 15:48:47 2015
From: evan at evanrutledgeborden.dreamhosters.com (evan@evan-borden.com)
Date: Wed, 21 Oct 2015 11:48:47 -0400
Subject: Breaking Changes and Long Term Support Haskell
In-Reply-To: <5627A4A8.7070107@apeiron.net>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk>
 <562765FE.6070808@nottingham.ac.uk>
 <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net>
 <a2781834655f4e358b95c6c5fd53e2ac@DB4PR30MB030.064d.mgd.msft.net>
 <5627A4A8.7070107@apeiron.net>
Message-ID: <CABmRwSC=wOVR42yd5Y8ABF97Xr1Ae14Ljz+vS4WMmcCHHkVCCQ@mail.gmail.com>

I'd also like to raise my concerns about an LTS solution.

#1 incremental change is far more consumable than large blocks of change.
We all know the fable of python 3, perl 6, etc.

#2 One concern that has been voiced by departing maintainers is the burden
of maintaining compatibility. An LTS strategy only increases this burden by
extending dead code paths.
On Oct 21, 2015 10:43 AM, "Geoffrey Mainland" <mainland at apeiron.net> wrote:

> On 10/21/2015 07:30 AM, Simon Peyton Jones wrote:
> > Friends
> >
> > I think it's good for us to debate the question of how we should balance
> innovation against change; and how we should make those decisions in
> future.  Geoff's message had some good ideas, especially this bit:
> >
> > |  Proposal 2: After a suitable period of discussion on the libraries
> list, the
> > |  Core Libraries Committee will summarize the arguments for and against
> a
> > |  proposal and post it, along with a (justified) preliminary decision,
> to a
> > |  low-traffic, announce-only email list. After another suitable period
> of
> > |  discussion, they will issue a final decision. What is a suitable
> period of
> > |  time? Perhaps that depends on the properties of the proposal, such as
> > |  whether it breaks backwards compatibility.
> >
> > Identifying major changes to the libraries, and having a better
> publicised, more RFC-like process for deliberating them, would be a good
> thing.  I believe that the Core Libraries committee is thinking actively
> about this.
> >
> > |  Personally, I think AMP was the right thing to do, but I don't think
> FTP was
> > |  the right thing.
> >
> > These make good examples to motivate future changes to our process.  But
> in the end FTP was subject to a pretty broad deliberative process,
> precisely along the lines that Geoff suggests above.  We had two
> clearly-articulated alternatives, a discrete call for opinions broadcast to
> every Haskell channel we could find, a decent interval for people to
> respond, and (as it turned out) a very clear preponderance of opinion in
> one direction.  In a big community, even a broad consultation may yield a
> result that some think is ill-advised.  That's part of the joyful burden of
> being a big community.
> >
> > Let's look forward, not back.  I think we can do better in future than
> we have done in the past.  I don't think we can hope for unanimity, but I
> think we can reasonably seek
> >
> >  * transparency;
> >  * clarity about what decisions are on the table;
> >  * broad consultation about decisions that affect
> >     a broad constituency; and
> >  * a decent opportunity to debate them without having
> >     to be involved in massive email threads.  Let's try do to that.
> >
> > Simon
> >
> > PS: For what it's worth I'm less keen on Geoff's other proposal:
> >
> > |  Proposal 3: A decision regarding any proposal that significantly
> affects
> > |  backwards compatibility is within the purview of the Haskell Prime
> > |  Committee, not the Core Libraries Committee.
> >
> > *Precisely* the same issues will arise whether it's CLC or HPC.  And the
> HPC is going to be jolly busy with language issues. Moving the question
> from one group to another risks avoiding the issue rather than addressing
> it.
>
> For the record, I am also not sure Proposal 3 is a good idea :)
>
> However, I do think we could clarify what the respective
> responsibilities of the core libraries committee and Haskell Prime
> committees are.
>
> One possible choice is that the core libraries committee is responsible
> for changes to the core libraries that do not affect libraries in the
> report. It is meant to be nimble, able to quickly deal with the large
> volume of library changes that do not impact backwards compatibility.
>
> In this scenario, the Haskell Prime committee, using a longer
> deliberative process, would consider the more impactful library changes
> and batch them up into new reports.
>
> You are absolutely correct that moving the question to the Haskell Prime
> committee risks pushing the issue around. The idea behind the separation
> outlined above is to reduce the treadmill; the two bodies use different
> processes, with different time frames, to arrive at decisions. Some
> library decisions may deserve a longer deliberative process.
>
> Cheers,
> Geoff
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151021/97c8b8d2/attachment-0001.html>

From ky3 at atamo.com  Wed Oct 21 16:02:12 2015
From: ky3 at atamo.com (Kim-Ee Yeoh)
Date: Wed, 21 Oct 2015 23:02:12 +0700
Subject: Breaking Changes and Long Term Support Haskell
In-Reply-To: <a2781834655f4e358b95c6c5fd53e2ac@DB4PR30MB030.064d.mgd.msft.net>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <5626DEDD.8040202@apeiron.net>
 <56274BC2.20507@nottingham.ac.uk> <562765FE.6070808@nottingham.ac.uk>
 <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net>
 <a2781834655f4e358b95c6c5fd53e2ac@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <CAPY+ZdQdyWyvsYrys=VzatHL4EAFLapics7Jf65Asdd5kuopCw@mail.gmail.com>

Hi Simon,

I'd just like you to know that the Haskell 98 report, for which you served
as co-editor, played a very important role when I was teaching myself the
language.

In fact, I still refer to it from time to time, both in the language and
also the libraries section.

Which brings me to your email earlier this month:

https://mail.haskell.org/pipermail/haskell-prime/2015-October/003984.html

I think that keeping the CLC and HPC separate has a lot of advantages. Most
important of all is keeping the work tractable by fanning it out. And the
track record speaks for itself: progress is made.

While it made plenty of sense the last time round when it felt like
squeezing blood from a stone assembling a quorum for HPC, wouldn't you say
it's different this time around?

There's a buzz of enthusiasm in HPC self-nominations that signals a very
healthy community, yes?

Some of that enthusiasm spills over into issues concerning the standard
libraries.

Now given that FTP is a done deal, wouldn't you say that it deserves to be
canonized in a report too? Just like Haskell 98?

I'm not saying to do away with the walls that separate the CLC and HPC. I'm
saying that today presents a rare opportunity for a unified committee to
work at a report good for the next 20 years.

Wouldn't it be such a waste to lose the moment?



*Precisely* the same issues will arise whether it's CLC or HPC.  And the
> HPC is going to be jolly busy with language issues.




-- Kim-Ee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151021/12a83cb5/attachment.html>

From cma at bitemyapp.com  Wed Oct 21 16:04:13 2015
From: cma at bitemyapp.com (Christopher Allen)
Date: Wed, 21 Oct 2015 11:04:13 -0500
Subject: Breaking Changes and Long Term Support Haskell
In-Reply-To: <CABmRwSC=wOVR42yd5Y8ABF97Xr1Ae14Ljz+vS4WMmcCHHkVCCQ@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk>
 <562765FE.6070808@nottingham.ac.uk>
 <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net>
 <a2781834655f4e358b95c6c5fd53e2ac@DB4PR30MB030.064d.mgd.msft.net>
 <5627A4A8.7070107@apeiron.net>
 <CABmRwSC=wOVR42yd5Y8ABF97Xr1Ae14Ljz+vS4WMmcCHHkVCCQ@mail.gmail.com>
Message-ID: <CADnndOogvb_UPrZUJgXXdDu=QSiwsx2wR8nuv6KZghUbMzeEpg@mail.gmail.com>

Seconding Evan Borden's concerns. I don't think LTS is needed for GHC
itself, though FPComplete's LTS Stackage snapshots have been nice, that's
on a timescale of months and there are multiple snapshots a year.

An LTS proposal at this time seems like delay for the sake of delay. The
practitioners and learners I know have not found switching to 7.10 to be
troublesome or to require much time. Converting http://haskellbook.com/ to
be up to date with 7.10 took an hour or two. We waited to see (out of
curiosity) if anybody would ask about the new type signatures. A few did,
so we made note of the more general type signatures in the new Prelude, and
showed them how you could assert a more specific (concrete) type signature
for those functions. No problems since then. When they type in the example
or exercise code, a type signature is provided which asserts that we want
the list variant. Polymorphism in Haskell pays off in spades here.

I use Haskell at work, converting the 15-ish libraries (some vendored
variants of public libraries) and 3 core projects totaling ~100k LOC took
an hour. As long as programmers can get a checklist of things to fix from
the compiler, I don't think this is a serious problem for industrial users.
Companies will fix their GHC version and pick a date to switch over
generally, needing to change things before cutting over shouldn't come as a
surprise to anyone.


On Wed, Oct 21, 2015 at 10:48 AM, evan at evan-borden.com <
evan at evanrutledgeborden.dreamhosters.com> wrote:

> I'd also like to raise my concerns about an LTS solution.
>
> #1 incremental change is far more consumable than large blocks of change.
> We all know the fable of python 3, perl 6, etc.
>
> #2 One concern that has been voiced by departing maintainers is the burden
> of maintaining compatibility. An LTS strategy only increases this burden by
> extending dead code paths.
> On Oct 21, 2015 10:43 AM, "Geoffrey Mainland" <mainland at apeiron.net>
> wrote:
>
>> On 10/21/2015 07:30 AM, Simon Peyton Jones wrote:
>> > Friends
>> >
>> > I think it's good for us to debate the question of how we should
>> balance innovation against change; and how we should make those decisions
>> in future.  Geoff's message had some good ideas, especially this bit:
>> >
>> > |  Proposal 2: After a suitable period of discussion on the libraries
>> list, the
>> > |  Core Libraries Committee will summarize the arguments for and
>> against a
>> > |  proposal and post it, along with a (justified) preliminary decision,
>> to a
>> > |  low-traffic, announce-only email list. After another suitable period
>> of
>> > |  discussion, they will issue a final decision. What is a suitable
>> period of
>> > |  time? Perhaps that depends on the properties of the proposal, such as
>> > |  whether it breaks backwards compatibility.
>> >
>> > Identifying major changes to the libraries, and having a better
>> publicised, more RFC-like process for deliberating them, would be a good
>> thing.  I believe that the Core Libraries committee is thinking actively
>> about this.
>> >
>> > |  Personally, I think AMP was the right thing to do, but I don't think
>> FTP was
>> > |  the right thing.
>> >
>> > These make good examples to motivate future changes to our process.
>> But in the end FTP was subject to a pretty broad deliberative process,
>> precisely along the lines that Geoff suggests above.  We had two
>> clearly-articulated alternatives, a discrete call for opinions broadcast to
>> every Haskell channel we could find, a decent interval for people to
>> respond, and (as it turned out) a very clear preponderance of opinion in
>> one direction.  In a big community, even a broad consultation may yield a
>> result that some think is ill-advised.  That's part of the joyful burden of
>> being a big community.
>> >
>> > Let's look forward, not back.  I think we can do better in future than
>> we have done in the past.  I don't think we can hope for unanimity, but I
>> think we can reasonably seek
>> >
>> >  * transparency;
>> >  * clarity about what decisions are on the table;
>> >  * broad consultation about decisions that affect
>> >     a broad constituency; and
>> >  * a decent opportunity to debate them without having
>> >     to be involved in massive email threads.  Let's try do to that.
>> >
>> > Simon
>> >
>> > PS: For what it's worth I'm less keen on Geoff's other proposal:
>> >
>> > |  Proposal 3: A decision regarding any proposal that significantly
>> affects
>> > |  backwards compatibility is within the purview of the Haskell Prime
>> > |  Committee, not the Core Libraries Committee.
>> >
>> > *Precisely* the same issues will arise whether it's CLC or HPC.  And
>> the HPC is going to be jolly busy with language issues. Moving the question
>> from one group to another risks avoiding the issue rather than addressing
>> it.
>>
>> For the record, I am also not sure Proposal 3 is a good idea :)
>>
>> However, I do think we could clarify what the respective
>> responsibilities of the core libraries committee and Haskell Prime
>> committees are.
>>
>> One possible choice is that the core libraries committee is responsible
>> for changes to the core libraries that do not affect libraries in the
>> report. It is meant to be nimble, able to quickly deal with the large
>> volume of library changes that do not impact backwards compatibility.
>>
>> In this scenario, the Haskell Prime committee, using a longer
>> deliberative process, would consider the more impactful library changes
>> and batch them up into new reports.
>>
>> You are absolutely correct that moving the question to the Haskell Prime
>> committee risks pushing the issue around. The idea behind the separation
>> outlined above is to reduce the treadmill; the two bodies use different
>> processes, with different time frames, to arrive at decisions. Some
>> library decisions may deserve a longer deliberative process.
>>
>> Cheers,
>> Geoff
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>


-- 
Chris Allen
Currently working on http://haskellbook.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151021/a5e13a6a/attachment.html>

From ekmett at gmail.com  Wed Oct 21 19:54:17 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Wed, 21 Oct 2015 15:54:17 -0400
Subject: [Haskell-cafe] Committee M.O. Change Proposals
In-Reply-To: <56278596.9070005@apeiron.net>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <5626DEDD.8040202@apeiron.net> <87pp088mh7.fsf_-_@gmail.com>
 <56278596.9070005@apeiron.net>
Message-ID: <CAJumaK8MSqWbLL8dHcJoK-A1vcq7sKZHMC6_5FOJAfzMJZhoSQ@mail.gmail.com>

The committee was formed from a pool of suggestions supplied to SPJ that
represented a fairly wide cross-section of the community.

Simon initially offered both myself and Johan Tibell the role of co-chairs.
Johan ultimately declined.

In the end, putting perhaps too simple a spin on it, the initial committee
was selected: Michael Snoyman for commercial interest, Mark Lentczner
representing the needs of the Platform and implementation concerns, Brent
Yorgey on the theory side, Doug Beardsley representing practitioners,
Joachim Breitner had expressed interest in working on split base, which at
the time was a much more active concern, Dan Doel represented a decent
balance of theory and practice.

Since then we had two slots open up on the committee, and precisely two
self-nominations to fill them, which rather simplified the selection
process. Brent and Doug rotated out and Eric Mertens and Luite Stegeman
rotated in.

Technically, yes, we are self-selected going forward, based on the
precedent of the haskell.org committee and haskell-prime committees, but
you'll note this hasn't actually been a factor yet as there hasn't been any
decision point reached where that has affected a membership decision.

-Edward

On Wed, Oct 21, 2015 at 8:31 AM, Geoffrey Mainland <mainland at apeiron.net>
wrote:

> On 10/21/2015 07:55 AM, Herbert Valerio Riedel wrote:
> > Hello, > > On 2015-10-21 at 02:39:57 +0200, Geoffrey Mainland wrote: > >
> [...]
> > >> In effect, only those who actively follow the libraries list have
> had a >> voice in these decisions. Maybe that is what the community
> wants. I hope >> not. How then can people like me (and Henrik and
> Graham) have a say >> without committing to actively following the
> libraries list? >>  >> We have a method to solve this: elected
> representatives. Right now the >> Core Libraries Committee elects its
> own members; perhaps it is time for >> that to change. > > [...] > >>
> Proposal 1: Move to community election of the members of the Core >>
> Libraries Committee. Yes, I know this would have its own issues. > > How
> exactly do public elections of representatives address the problem >
> that some people feel left out? Have you considered nominating yourself
> > or somebody else you have confidence in for the core libraries >
> committee? You'd still have to find somebody to represent your >
> interests, regardless of whether the committee is self-elected or >
> direct-elected. > > Here's some food for thought regarding language
> design by voting or its > indirect form via a directly elected language
> committee: > > Back in February there was a large-scale survey which
> resulted (see [2] > for more details) in a rather unequivocal 4:1
> majority *for* going > through with the otherwise controversial FTP
> implementation. If the > community elections would result in a similar
> spirit, you'd could easily > end up with a similarly 4:1 pro-change
> biased committee. Would you > consider that a well balanced committee
> formation?
>
> Thanks, all good points.
>
> It is quite possible that direct elections would produce the exact same
> committee. I wouldn't see that as a negative outcome at all! At least
> that committee would have been put in place by direct election; I would
> see that as strengthening their mandate.
>
> I am very much aware of the February survey. I wonder if Proposal 2, had
> it been in place at the time, would have increased participation in the
> survey.
>
> The recent kerfuffle has caught the attention of many people who don't
> normally follow the libraries list. Proposal 1 is an attempt to give
> them a voice. Yes, they would still need to find a candidate to
> represent their interests. If we moved to direct elections, I would
> consider running. However, my preference is that Proposal 3 go through
> in some form, in which case my main concern would be the Haskell Prime
> committee, and unfortunately nominations for that committee have already
> closed.
>
> >> Proposal 2: After a suitable period of discussion on the libraries
> list, >> the Core Libraries Committee will summarize the arguments for and
> >>
> against a proposal and post it, along with a (justified) preliminary >>
> decision, to a low-traffic, announce-only email list. After another >>
> suitable period of discussion, they will issue a final decision. What is
> >> a suitable period of time? Perhaps that depends on the properties of
> the >> proposal, such as whether it breaks backwards compatibility. > >
> That generally sounds like a good compromise, if this actually helps >
> reaching the otherwise unreachable parts of the community and have their
> > voices heard.
>
> My hope is that a low-volume mailing list would indeed reach a wider
> audience.
>
> >> Proposal 3: A decision regarding any proposal that significantly
> affects >> backwards compatibility is within the purview of the Haskell
> Prime
> >> Committee, not the Core Libraries Committee. > > I don't see how that
> would change much. The prior Haskell Prime > Committee has been
> traditionally self-elected as well. So it's just the > label of the
> committee you'd swap out. > > In the recent call of nominations[1] for
> Haskell Prime, the stated area > of work for the new nominations was to
> take care of the *language* part, > because that's what we are lacking
> the workforce for. > > Since its creation for the very purpose of
> watching over the core > libraries, the core-libraries-committee has
> been almost exclusively busy > with evaluating and deciding about
> changes to the `base` library and > overseeing their implementation.
> Transferring this huge workload to the > new Haskell Prime committee
> members who have already their hands full > with revising the language
> part would IMO just achieve to reduce the > effectiveness of the
> upcoming Haskell Prime committee, and therefore > increase the risk of
> failure in producing an adequate new Haskell Report > revision.
>
> My understanding is that much of the work of the core libraries
> committee does not "significantly affect backwards compatibility," at
> least not to the extent that MRP does. If this is the case, the bulk of
> their workload would not be transferred to the new Haskell Prime
> committee. Is my understanding incorrect?
>
> The intent of Proposal 3 was to transfer only a small fraction of the
> issues that come before the core libraries committee to the Haskell
> Prime committee. In any case, we would certainly need to clarify what
> "significantly affects backwards compatibility" means.
>
> Perhaps we should consider direct elections for the Haskell Prime
> committee as well as changing their mandate to include some subset of
> the changes proposed to libraries covered by the Haskell Report. My
> understanding of the current state of affairs is that the Haskell Prime
> committee is charged with producing a new report, but the core libraries
> committee is in charge of the library part of that report. Is that
> correct?
>
> Cheers,
> Geoff
>
> > Regards, >   H.V.Riedel > >  [1]:
> https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html
> >  [2]:
> https://mail.haskell.org/pipermail/haskell-cafe/2015-February/118336.html
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151021/2e959333/attachment-0001.html>

From mainland at apeiron.net  Wed Oct 21 20:04:04 2015
From: mainland at apeiron.net (Geoffrey Mainland)
Date: Wed, 21 Oct 2015 16:04:04 -0400
Subject: [Haskell-cafe] Committee M.O. Change Proposals
In-Reply-To: <CAJumaK8MSqWbLL8dHcJoK-A1vcq7sKZHMC6_5FOJAfzMJZhoSQ@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <5626DEDD.8040202@apeiron.net> <87pp088mh7.fsf_-_@gmail.com>
 <56278596.9070005@apeiron.net>
 <CAJumaK8MSqWbLL8dHcJoK-A1vcq7sKZHMC6_5FOJAfzMJZhoSQ@mail.gmail.com>
Message-ID: <5627EFB4.8020800@apeiron.net>

Thanks for the background, Edward.

I don't mean to question the composition of the committee, only to start
a discussion about how the community might handle the selection process
going forward. I apologize if I was not clear about that. As I said
below, if a direct vote resulted in the same committee we would have had
under the current system, I would consider that a success!

We may also see a larger nomination pool in the future :)

Cheers,
Geoff

On 10/21/2015 03:54 PM, Edward Kmett wrote:
> The committee was formed from a pool of suggestions supplied to SPJ
> that represented a fairly wide cross-section of the community.
>
> Simon initially offered both myself and Johan Tibell the role of
> co-chairs. Johan ultimately declined.
>
> In the end, putting perhaps too simple a spin on it, the initial
> committee was selected: Michael Snoyman for commercial interest, Mark
> Lentczner representing the needs of the Platform and implementation
> concerns, Brent Yorgey on the theory side, Doug Beardsley representing
> practitioners, Joachim Breitner had expressed interest in working on
> split base, which at the time was a much more active concern, Dan Doel
> represented a decent balance of theory and practice.
>
> Since then we had two slots open up on the committee, and precisely
> two self-nominations to fill them, which rather simplified the
> selection process. Brent and Doug rotated out and Eric Mertens and
> Luite Stegeman rotated in.
>
> Technically, yes, we are self-selected going forward, based on the
> precedent of the haskell.org <http://haskell.org> committee and
> haskell-prime committees, but you'll note this hasn't actually been a
> factor yet as there hasn't been any decision point reached where that
> has affected a membership decision.
>
> -Edward
>
> On Wed, Oct 21, 2015 at 8:31 AM, Geoffrey Mainland
> <mainland at apeiron.net <mailto:mainland at apeiron.net>> wrote:
>
>     On 10/21/2015 07:55 AM, Herbert Valerio Riedel wrote:
>     > Hello, > > On 2015-10-21 at 02:39:57 +0200, Geoffrey Mainland
>     wrote: > > [...]
>     > >> In effect, only those who actively follow the libraries list have
>     had a >> voice in these decisions. Maybe that is what the community
>     wants. I hope >> not. How then can people like me (and Henrik and
>     Graham) have a say >> without committing to actively following the
>     libraries list? >>  >> We have a method to solve this: elected
>     representatives. Right now the >> Core Libraries Committee elects its
>     own members; perhaps it is time for >> that to change. > > [...] > >>
>     Proposal 1: Move to community election of the members of the Core >>
>     Libraries Committee. Yes, I know this would have its own issues. >
>     > How
>     exactly do public elections of representatives address the problem >
>     that some people feel left out? Have you considered nominating
>     yourself
>     > or somebody else you have confidence in for the core libraries >
>     committee? You'd still have to find somebody to represent your >
>     interests, regardless of whether the committee is self-elected or >
>     direct-elected. > > Here's some food for thought regarding language
>     design by voting or its > indirect form via a directly elected
>     language
>     committee: > > Back in February there was a large-scale survey which
>     resulted (see [2] > for more details) in a rather unequivocal 4:1
>     majority *for* going > through with the otherwise controversial FTP
>     implementation. If the > community elections would result in a similar
>     spirit, you'd could easily > end up with a similarly 4:1 pro-change
>     biased committee. Would you > consider that a well balanced committee
>     formation?
>
>     Thanks, all good points.
>
>     It is quite possible that direct elections would produce the exact
>     same
>     committee. I wouldn't see that as a negative outcome at all! At least
>     that committee would have been put in place by direct election; I
>     would
>     see that as strengthening their mandate.
>
>     I am very much aware of the February survey. I wonder if Proposal
>     2, had
>     it been in place at the time, would have increased participation
>     in the
>     survey.
>
>     The recent kerfuffle has caught the attention of many people who don't
>     normally follow the libraries list. Proposal 1 is an attempt to give
>     them a voice. Yes, they would still need to find a candidate to
>     represent their interests. If we moved to direct elections, I would
>     consider running. However, my preference is that Proposal 3 go through
>     in some form, in which case my main concern would be the Haskell Prime
>     committee, and unfortunately nominations for that committee have
>     already
>     closed.
>
>     >> Proposal 2: After a suitable period of discussion on the
>     libraries list, >> the Core Libraries Committee will summarize the
>     arguments for and >>
>     against a proposal and post it, along with a (justified)
>     preliminary >>
>     decision, to a low-traffic, announce-only email list. After another >>
>     suitable period of discussion, they will issue a final decision.
>     What is
>     >> a suitable period of time? Perhaps that depends on the
>     properties of
>     the >> proposal, such as whether it breaks backwards
>     compatibility. > >
>     That generally sounds like a good compromise, if this actually helps >
>     reaching the otherwise unreachable parts of the community and have
>     their
>     > voices heard.
>
>     My hope is that a low-volume mailing list would indeed reach a wider
>     audience.
>
>     >> Proposal 3: A decision regarding any proposal that
>     significantly affects >> backwards compatibility is within the
>     purview of the Haskell Prime
>     >> Committee, not the Core Libraries Committee. > > I don't see
>     how that
>     would change much. The prior Haskell Prime > Committee has been
>     traditionally self-elected as well. So it's just the > label of the
>     committee you'd swap out. > > In the recent call of nominations[1] for
>     Haskell Prime, the stated area > of work for the new nominations
>     was to
>     take care of the *language* part, > because that's what we are lacking
>     the workforce for. > > Since its creation for the very purpose of
>     watching over the core > libraries, the core-libraries-committee has
>     been almost exclusively busy > with evaluating and deciding about
>     changes to the `base` library and > overseeing their implementation.
>     Transferring this huge workload to the > new Haskell Prime committee
>     members who have already their hands full > with revising the language
>     part would IMO just achieve to reduce the > effectiveness of the
>     upcoming Haskell Prime committee, and therefore > increase the risk of
>     failure in producing an adequate new Haskell Report > revision.
>
>     My understanding is that much of the work of the core libraries
>     committee does not "significantly affect backwards compatibility," at
>     least not to the extent that MRP does. If this is the case, the
>     bulk of
>     their workload would not be transferred to the new Haskell Prime
>     committee. Is my understanding incorrect?
>
>     The intent of Proposal 3 was to transfer only a small fraction of the
>     issues that come before the core libraries committee to the Haskell
>     Prime committee. In any case, we would certainly need to clarify what
>     "significantly affects backwards compatibility" means.
>
>     Perhaps we should consider direct elections for the Haskell Prime
>     committee as well as changing their mandate to include some subset of
>     the changes proposed to libraries covered by the Haskell Report. My
>     understanding of the current state of affairs is that the Haskell
>     Prime
>     committee is charged with producing a new report, but the core
>     libraries
>     committee is in charge of the library part of that report. Is that
>     correct?
>
>     Cheers,
>     Geoff
>
>     > Regards, >   H.V.Riedel > >  [1]:
>     https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html
>     >  [2]:
>     https://mail.haskell.org/pipermail/haskell-cafe/2015-February/118336.html
>
>


From dan.doel at gmail.com  Wed Oct 21 21:22:52 2015
From: dan.doel at gmail.com (Dan Doel)
Date: Wed, 21 Oct 2015 17:22:52 -0400
Subject: Breaking Changes and Long Term Support Haskell
In-Reply-To: <5627A4A8.7070107@apeiron.net>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk>
 <562765FE.6070808@nottingham.ac.uk>
 <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net>
 <a2781834655f4e358b95c6c5fd53e2ac@DB4PR30MB030.064d.mgd.msft.net>
 <5627A4A8.7070107@apeiron.net>
Message-ID: <CAHEA9tMB4vgyijZBt-PWEU-SPVvm2ouw1vgntkwss38e5tSh9Q@mail.gmail.com>

Hello,

I'm Dan Doel. I'm on the core libraries committee (though I'm speaking
only for myself). As I recall, one of the reasons I got tapped for it
was due to my having some historical knowledge about Haskell; not
because I was there, but because I've gone back and looked at some old
reports and whatnot (and sometimes think they're better than what we
have now).

But, I was around (of course) when the core libraries committee
started up, so perhaps I can play the role of historian for this as
well.

The reason the committee exists is because a couple years ago, people
brought up the ideas that were finally realized in the
Applicative-Monad proposal and the Foldable-Traversable proposal. A
lot of people weighed in saying they thought they were a good idea,
and significantly fewer people weighed in saying they thought that it
shouldn't happen for various reasons---roughly the same things that
people are still bringing up about these proposals.

This wasn't the first time that happened, either. I think it was
widely agreed among most users that Functor should be a superclass of
Monad since I started learning Haskell around 10 years ago. And once
Applicative was introduced, it was agreed that that should go in the
middle of the two. But it appeared that it would never happen, despite
a significant majority thinking it should, because no one wanted to do
anything without pretty much unanimous consent.

So, one question that got raised is: why should this majority of
people even use Haskell/GHC anymore? Why shouldn't they start using
some other language that will let them change 15-year-old mistakes, or
adapt to ideas that weren't even available at that time (but are still
fairly old and established, all things considered). And the answer was
that there should be some body empowered to decide to move forward
with these ideas, even if there is some dissent. And frankly, it
wasn't going to be the prime committee, because it hadn't shown any
activity in something like 3 years at the time, and even when it was
active, it didn't make anywhere near the sort of changes that were
being discussed.

And the kicker to me is, many things that people are complaining about
again (e.g. the FTP) were the very things that the committee was
established to execute. I don't think we had a formal vote on that
proposal, because we didn't need to. Our existence was in part to
execute that proposal (and AMP). And then a year ago, when it was
finally time to release the changes, there was another ruckus. And we
still didn't have a CLC vote on the matter. What we did was conduct a
community poll, and then SPJ reviewed the submissions. But I don't
mean to pass the buck to him, because I'm pretty sure he was worried
that we were crazy, and overstepping our bounds. Just, the results of
the survey were sufficient for him to not overrule us.

So my point is this: there seems to be some sentiment that the core
libraries committee is unsound, and making bad decisions. But the
complaints are mostly not even about actual decisions we made (aside
from maybe Lennart Augustsson's, where he is unhappy with details of
the FTP that you can blame on us, but were designed to break the least
code, instead of being the most elegant; if we had pleased him more,
we would have pleased others less). They are about the reasons for
founding the committee in the first place. You can blame us, if you
like, because I think it's certain that we would have approved them if
we had formally voted. We just didn't even need to do so.

Forgive me if I'm wrong, but suggestions that these decisions should
have been deferred to a Haskell Prime committee mean, to me, that the
hope is that they would have been rejected. That the Haskell Prime
committee should have just vetoed these proposals that something like
80% or more of practicing Haskell users (as far as we can tell) wanted
for years before they finally happened. That the Haskell Prime
committee should be responsible for enforcing the very status quo that
led to the CLC in the first place, where proposals with broad support
but minority dissent never pass for various core modules.

If this is the case, then one could simply repose the earlier
question: why should most of these people stick around to obey by the
Haskell Prime committee's pronouncements, instead of getting to work
on a language that incorporates their input?

And if it isn't, then I don't ultimately understand what the
complaints are. We try to accomplish the (large) changes in a manner
that allows transition via refactoring over multiple versions (and as
I mentioned earlier, some complaints are that we compromised _too
much_ for this). And in light of the more recent complaints, it's even
been decided that our time frames should be longer. Rolling up changes
into a report just seems like it makes transitions less smooth. Unless
the idea is to make GHC capable of switching out entire base library
sets; but someone has to implement that, and once you have it, it
makes the report specifications _less_ essential.

Anyhow, that's my history lesson. Take it as you (all) will.

Cheers,
-- Dan

On Wed, Oct 21, 2015 at 10:43 AM, Geoffrey Mainland
<mainland at apeiron.net> wrote:
> On 10/21/2015 07:30 AM, Simon Peyton Jones wrote:
>> Friends
>>
>> I think it's good for us to debate the question of how we should balance innovation against change; and how we should make those decisions in future.  Geoff's message had some good ideas, especially this bit:
>>
>> |  Proposal 2: After a suitable period of discussion on the libraries list, the
>> |  Core Libraries Committee will summarize the arguments for and against a
>> |  proposal and post it, along with a (justified) preliminary decision, to a
>> |  low-traffic, announce-only email list. After another suitable period of
>> |  discussion, they will issue a final decision. What is a suitable period of
>> |  time? Perhaps that depends on the properties of the proposal, such as
>> |  whether it breaks backwards compatibility.
>>
>> Identifying major changes to the libraries, and having a better publicised, more RFC-like process for deliberating them, would be a good thing.  I believe that the Core Libraries committee is thinking actively about this.
>>
>> |  Personally, I think AMP was the right thing to do, but I don't think FTP was
>> |  the right thing.
>>
>> These make good examples to motivate future changes to our process.  But in the end FTP was subject to a pretty broad deliberative process, precisely along the lines that Geoff suggests above.  We had two clearly-articulated alternatives, a discrete call for opinions broadcast to every Haskell channel we could find, a decent interval for people to respond, and (as it turned out) a very clear preponderance of opinion in one direction.  In a big community, even a broad consultation may yield a result that some think is ill-advised.  That's part of the joyful burden of being a big community.
>>
>> Let's look forward, not back.  I think we can do better in future than we have done in the past.  I don't think we can hope for unanimity, but I think we can reasonably seek
>>
>>  * transparency;
>>  * clarity about what decisions are on the table;
>>  * broad consultation about decisions that affect
>>     a broad constituency; and
>>  * a decent opportunity to debate them without having
>>     to be involved in massive email threads.  Let's try do to that.
>>
>> Simon
>>
>> PS: For what it's worth I'm less keen on Geoff's other proposal:
>>
>> |  Proposal 3: A decision regarding any proposal that significantly affects
>> |  backwards compatibility is within the purview of the Haskell Prime
>> |  Committee, not the Core Libraries Committee.
>>
>> *Precisely* the same issues will arise whether it's CLC or HPC.  And the HPC is going to be jolly busy with language issues. Moving the question from one group to another risks avoiding the issue rather than addressing it.
>
> For the record, I am also not sure Proposal 3 is a good idea :)
>
> However, I do think we could clarify what the respective
> responsibilities of the core libraries committee and Haskell Prime
> committees are.
>
> One possible choice is that the core libraries committee is responsible
> for changes to the core libraries that do not affect libraries in the
> report. It is meant to be nimble, able to quickly deal with the large
> volume of library changes that do not impact backwards compatibility.
>
> In this scenario, the Haskell Prime committee, using a longer
> deliberative process, would consider the more impactful library changes
> and batch them up into new reports.
>
> You are absolutely correct that moving the question to the Haskell Prime
> committee risks pushing the issue around. The idea behind the separation
> outlined above is to reduce the treadmill; the two bodies use different
> processes, with different time frames, to arrive at decisions. Some
> library decisions may deserve a longer deliberative process.
>
> Cheers,
> Geoff
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

From carter.schonwald at gmail.com  Wed Oct 21 21:48:23 2015
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Wed, 21 Oct 2015 17:48:23 -0400
Subject: Breaking Changes and Long Term Support Haskell
In-Reply-To: <CAHEA9tMB4vgyijZBt-PWEU-SPVvm2ouw1vgntkwss38e5tSh9Q@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk>
 <562765FE.6070808@nottingham.ac.uk>
 <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net>
 <a2781834655f4e358b95c6c5fd53e2ac@DB4PR30MB030.064d.mgd.msft.net>
 <5627A4A8.7070107@apeiron.net>
 <CAHEA9tMB4vgyijZBt-PWEU-SPVvm2ouw1vgntkwss38e5tSh9Q@mail.gmail.com>
Message-ID: <CAHYVw0xpX+=3wiKuyqDbLHtGXKvAyROAQw6tXc-2LSwvO4_PJQ@mail.gmail.com>

Well said!

I do have a small worry that the longer roll out window will be harder to
manage given that every thing is done by (outstanding) volunteers.  But
maybe the answer there is that ghc should do major version releases more
frequently :), eg every 9 months instead of every 12! ?

On Wednesday, October 21, 2015, Dan Doel <dan.doel at gmail.com> wrote:

> Hello,
>
> I'm Dan Doel. I'm on the core libraries committee (though I'm speaking
> only for myself). As I recall, one of the reasons I got tapped for it
> was due to my having some historical knowledge about Haskell; not
> because I was there, but because I've gone back and looked at some old
> reports and whatnot (and sometimes think they're better than what we
> have now).
>
> But, I was around (of course) when the core libraries committee
> started up, so perhaps I can play the role of historian for this as
> well.
>
> The reason the committee exists is because a couple years ago, people
> brought up the ideas that were finally realized in the
> Applicative-Monad proposal and the Foldable-Traversable proposal. A
> lot of people weighed in saying they thought they were a good idea,
> and significantly fewer people weighed in saying they thought that it
> shouldn't happen for various reasons---roughly the same things that
> people are still bringing up about these proposals.
>
> This wasn't the first time that happened, either. I think it was
> widely agreed among most users that Functor should be a superclass of
> Monad since I started learning Haskell around 10 years ago. And once
> Applicative was introduced, it was agreed that that should go in the
> middle of the two. But it appeared that it would never happen, despite
> a significant majority thinking it should, because no one wanted to do
> anything without pretty much unanimous consent.
>
> So, one question that got raised is: why should this majority of
> people even use Haskell/GHC anymore? Why shouldn't they start using
> some other language that will let them change 15-year-old mistakes, or
> adapt to ideas that weren't even available at that time (but are still
> fairly old and established, all things considered). And the answer was
> that there should be some body empowered to decide to move forward
> with these ideas, even if there is some dissent. And frankly, it
> wasn't going to be the prime committee, because it hadn't shown any
> activity in something like 3 years at the time, and even when it was
> active, it didn't make anywhere near the sort of changes that were
> being discussed.
>
> And the kicker to me is, many things that people are complaining about
> again (e.g. the FTP) were the very things that the committee was
> established to execute. I don't think we had a formal vote on that
> proposal, because we didn't need to. Our existence was in part to
> execute that proposal (and AMP). And then a year ago, when it was
> finally time to release the changes, there was another ruckus. And we
> still didn't have a CLC vote on the matter. What we did was conduct a
> community poll, and then SPJ reviewed the submissions. But I don't
> mean to pass the buck to him, because I'm pretty sure he was worried
> that we were crazy, and overstepping our bounds. Just, the results of
> the survey were sufficient for him to not overrule us.
>
> So my point is this: there seems to be some sentiment that the core
> libraries committee is unsound, and making bad decisions. But the
> complaints are mostly not even about actual decisions we made (aside
> from maybe Lennart Augustsson's, where he is unhappy with details of
> the FTP that you can blame on us, but were designed to break the least
> code, instead of being the most elegant; if we had pleased him more,
> we would have pleased others less). They are about the reasons for
> founding the committee in the first place. You can blame us, if you
> like, because I think it's certain that we would have approved them if
> we had formally voted. We just didn't even need to do so.
>
> Forgive me if I'm wrong, but suggestions that these decisions should
> have been deferred to a Haskell Prime committee mean, to me, that the
> hope is that they would have been rejected. That the Haskell Prime
> committee should have just vetoed these proposals that something like
> 80% or more of practicing Haskell users (as far as we can tell) wanted
> for years before they finally happened. That the Haskell Prime
> committee should be responsible for enforcing the very status quo that
> led to the CLC in the first place, where proposals with broad support
> but minority dissent never pass for various core modules.
>
> If this is the case, then one could simply repose the earlier
> question: why should most of these people stick around to obey by the
> Haskell Prime committee's pronouncements, instead of getting to work
> on a language that incorporates their input?
>
> And if it isn't, then I don't ultimately understand what the
> complaints are. We try to accomplish the (large) changes in a manner
> that allows transition via refactoring over multiple versions (and as
> I mentioned earlier, some complaints are that we compromised _too
> much_ for this). And in light of the more recent complaints, it's even
> been decided that our time frames should be longer. Rolling up changes
> into a report just seems like it makes transitions less smooth. Unless
> the idea is to make GHC capable of switching out entire base library
> sets; but someone has to implement that, and once you have it, it
> makes the report specifications _less_ essential.
>
> Anyhow, that's my history lesson. Take it as you (all) will.
>
> Cheers,
> -- Dan
>
> On Wed, Oct 21, 2015 at 10:43 AM, Geoffrey Mainland
> <mainland at apeiron.net <javascript:;>> wrote:
> > On 10/21/2015 07:30 AM, Simon Peyton Jones wrote:
> >> Friends
> >>
> >> I think it's good for us to debate the question of how we should
> balance innovation against change; and how we should make those decisions
> in future.  Geoff's message had some good ideas, especially this bit:
> >>
> >> |  Proposal 2: After a suitable period of discussion on the libraries
> list, the
> >> |  Core Libraries Committee will summarize the arguments for and
> against a
> >> |  proposal and post it, along with a (justified) preliminary decision,
> to a
> >> |  low-traffic, announce-only email list. After another suitable period
> of
> >> |  discussion, they will issue a final decision. What is a suitable
> period of
> >> |  time? Perhaps that depends on the properties of the proposal, such as
> >> |  whether it breaks backwards compatibility.
> >>
> >> Identifying major changes to the libraries, and having a better
> publicised, more RFC-like process for deliberating them, would be a good
> thing.  I believe that the Core Libraries committee is thinking actively
> about this.
> >>
> >> |  Personally, I think AMP was the right thing to do, but I don't think
> FTP was
> >> |  the right thing.
> >>
> >> These make good examples to motivate future changes to our process.
> But in the end FTP was subject to a pretty broad deliberative process,
> precisely along the lines that Geoff suggests above.  We had two
> clearly-articulated alternatives, a discrete call for opinions broadcast to
> every Haskell channel we could find, a decent interval for people to
> respond, and (as it turned out) a very clear preponderance of opinion in
> one direction.  In a big community, even a broad consultation may yield a
> result that some think is ill-advised.  That's part of the joyful burden of
> being a big community.
> >>
> >> Let's look forward, not back.  I think we can do better in future than
> we have done in the past.  I don't think we can hope for unanimity, but I
> think we can reasonably seek
> >>
> >>  * transparency;
> >>  * clarity about what decisions are on the table;
> >>  * broad consultation about decisions that affect
> >>     a broad constituency; and
> >>  * a decent opportunity to debate them without having
> >>     to be involved in massive email threads.  Let's try do to that.
> >>
> >> Simon
> >>
> >> PS: For what it's worth I'm less keen on Geoff's other proposal:
> >>
> >> |  Proposal 3: A decision regarding any proposal that significantly
> affects
> >> |  backwards compatibility is within the purview of the Haskell Prime
> >> |  Committee, not the Core Libraries Committee.
> >>
> >> *Precisely* the same issues will arise whether it's CLC or HPC.  And
> the HPC is going to be jolly busy with language issues. Moving the question
> from one group to another risks avoiding the issue rather than addressing
> it.
> >
> > For the record, I am also not sure Proposal 3 is a good idea :)
> >
> > However, I do think we could clarify what the respective
> > responsibilities of the core libraries committee and Haskell Prime
> > committees are.
> >
> > One possible choice is that the core libraries committee is responsible
> > for changes to the core libraries that do not affect libraries in the
> > report. It is meant to be nimble, able to quickly deal with the large
> > volume of library changes that do not impact backwards compatibility.
> >
> > In this scenario, the Haskell Prime committee, using a longer
> > deliberative process, would consider the more impactful library changes
> > and batch them up into new reports.
> >
> > You are absolutely correct that moving the question to the Haskell Prime
> > committee risks pushing the issue around. The idea behind the separation
> > outlined above is to reduce the treadmill; the two bodies use different
> > processes, with different time frames, to arrive at decisions. Some
> > library decisions may deserve a longer deliberative process.
> >
> > Cheers,
> > Geoff
> > _______________________________________________
> > Libraries mailing list
> > Libraries at haskell.org <javascript:;>
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org <javascript:;>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151021/7f252358/attachment-0001.html>

From simonpj at microsoft.com  Wed Oct 21 21:48:59 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 21 Oct 2015 21:48:59 +0000
Subject: Breaking Changes and Long Term Support Haskell
In-Reply-To: <CAHEA9tMB4vgyijZBt-PWEU-SPVvm2ouw1vgntkwss38e5tSh9Q@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>	<560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <5626DEDD.8040202@apeiron.net>	<56274BC2.20507@nottingham.ac.uk>
 <562765FE.6070808@nottingham.ac.uk>
 <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net>
 <a2781834655f4e358b95c6c5fd53e2ac@DB4PR30MB030.064d.mgd.msft.net>
 <5627A4A8.7070107@apeiron.net>
 <CAHEA9tMB4vgyijZBt-PWEU-SPVvm2ouw1vgntkwss38e5tSh9Q@mail.gmail.com>
Message-ID: <0b12e5e1ed6349cc8c63d5783fefae29@DB4PR30MB030.064d.mgd.msft.net>

While we are here, let me say

  A BIG THANK YOU TO THE CORE LIBRARIES COMMITTEE

Library design has a lot of detail, and a lot of competing priorities.  I am personally very grateful to the CLC for the work they put into this. Like many crucial tasks it's one that often seems to attract more complaints than thanks, but they are doing us all a huge service, and at significant cost in terms of their most precious and inelastic commodity: their personal time.

Remember, as Dan says, before the CLC we no process whatsoever for library evolution... various people made various patches, and there was no way of getting anything substantial done.  So we are far far further on than before.

Still not perfect, as my last post said. But still: THANK YOU.

Simon

| -----Original Message-----
| From: Dan Doel [mailto:dan.doel at gmail.com]
| Sent: 21 October 2015 22:23
| To: Geoffrey Mainland
| Cc: Simon Peyton Jones; Augustsson, Lennart; Henrik Nilsson; haskell-
| prime at haskell.org List; Haskell Libraries
| Subject: Re: Breaking Changes and Long Term Support Haskell
| 
| Hello,
| 
| I'm Dan Doel. I'm on the core libraries committee (though I'm speaking
| only for myself). As I recall, one of the reasons I got tapped for it
| was due to my having some historical knowledge about Haskell; not
| because I was there, but because I've gone back and looked at some old
| reports and whatnot (and sometimes think they're better than what we
| have now).
| 
| But, I was around (of course) when the core libraries committee
| started up, so perhaps I can play the role of historian for this as
| well.
| 
| The reason the committee exists is because a couple years ago, people
| brought up the ideas that were finally realized in the
| Applicative-Monad proposal and the Foldable-Traversable proposal. A
| lot of people weighed in saying they thought they were a good idea,
| and significantly fewer people weighed in saying they thought that it
| shouldn't happen for various reasons---roughly the same things that
| people are still bringing up about these proposals.
| 
| This wasn't the first time that happened, either. I think it was
| widely agreed among most users that Functor should be a superclass of
| Monad since I started learning Haskell around 10 years ago. And once
| Applicative was introduced, it was agreed that that should go in the
| middle of the two. But it appeared that it would never happen, despite
| a significant majority thinking it should, because no one wanted to do
| anything without pretty much unanimous consent.
| 
| So, one question that got raised is: why should this majority of
| people even use Haskell/GHC anymore? Why shouldn't they start using
| some other language that will let them change 15-year-old mistakes, or
| adapt to ideas that weren't even available at that time (but are still
| fairly old and established, all things considered). And the answer was
| that there should be some body empowered to decide to move forward
| with these ideas, even if there is some dissent. And frankly, it
| wasn't going to be the prime committee, because it hadn't shown any
| activity in something like 3 years at the time, and even when it was
| active, it didn't make anywhere near the sort of changes that were
| being discussed.
| 
| And the kicker to me is, many things that people are complaining about
| again (e.g. the FTP) were the very things that the committee was
| established to execute. I don't think we had a formal vote on that
| proposal, because we didn't need to. Our existence was in part to
| execute that proposal (and AMP). And then a year ago, when it was
| finally time to release the changes, there was another ruckus. And we
| still didn't have a CLC vote on the matter. What we did was conduct a
| community poll, and then SPJ reviewed the submissions. But I don't
| mean to pass the buck to him, because I'm pretty sure he was worried
| that we were crazy, and overstepping our bounds. Just, the results of
| the survey were sufficient for him to not overrule us.
| 
| So my point is this: there seems to be some sentiment that the core
| libraries committee is unsound, and making bad decisions. But the
| complaints are mostly not even about actual decisions we made (aside
| from maybe Lennart Augustsson's, where he is unhappy with details of
| the FTP that you can blame on us, but were designed to break the least
| code, instead of being the most elegant; if we had pleased him more,
| we would have pleased others less). They are about the reasons for
| founding the committee in the first place. You can blame us, if you
| like, because I think it's certain that we would have approved them if
| we had formally voted. We just didn't even need to do so.
| 
| Forgive me if I'm wrong, but suggestions that these decisions should
| have been deferred to a Haskell Prime committee mean, to me, that the
| hope is that they would have been rejected. That the Haskell Prime
| committee should have just vetoed these proposals that something like
| 80% or more of practicing Haskell users (as far as we can tell) wanted
| for years before they finally happened. That the Haskell Prime
| committee should be responsible for enforcing the very status quo that
| led to the CLC in the first place, where proposals with broad support
| but minority dissent never pass for various core modules.
| 
| If this is the case, then one could simply repose the earlier
| question: why should most of these people stick around to obey by the
| Haskell Prime committee's pronouncements, instead of getting to work
| on a language that incorporates their input?
| 
| And if it isn't, then I don't ultimately understand what the
| complaints are. We try to accomplish the (large) changes in a manner
| that allows transition via refactoring over multiple versions (and as
| I mentioned earlier, some complaints are that we compromised _too
| much_ for this). And in light of the more recent complaints, it's even
| been decided that our time frames should be longer. Rolling up changes
| into a report just seems like it makes transitions less smooth. Unless
| the idea is to make GHC capable of switching out entire base library
| sets; but someone has to implement that, and once you have it, it
| makes the report specifications _less_ essential.
| 
| Anyhow, that's my history lesson. Take it as you (all) will.
| 
| Cheers,
| -- Dan
| 
| On Wed, Oct 21, 2015 at 10:43 AM, Geoffrey Mainland
| <mainland at apeiron.net> wrote:
| > On 10/21/2015 07:30 AM, Simon Peyton Jones wrote:
| >> Friends
| >>
| >> I think it's good for us to debate the question of how we should
| balance innovation against change; and how we should make those decisions
| in future.  Geoff's message had some good ideas, especially this bit:
| >>
| >> |  Proposal 2: After a suitable period of discussion on the libraries
| list, the
| >> |  Core Libraries Committee will summarize the arguments for and
| against a
| >> |  proposal and post it, along with a (justified) preliminary decision,
| to a
| >> |  low-traffic, announce-only email list. After another suitable period
| of
| >> |  discussion, they will issue a final decision. What is a suitable
| period of
| >> |  time? Perhaps that depends on the properties of the proposal, such
| as
| >> |  whether it breaks backwards compatibility.
| >>
| >> Identifying major changes to the libraries, and having a better
| publicised, more RFC-like process for deliberating them, would be a good
| thing.  I believe that the Core Libraries committee is thinking actively
| about this.
| >>
| >> |  Personally, I think AMP was the right thing to do, but I don't think
| FTP was
| >> |  the right thing.
| >>
| >> These make good examples to motivate future changes to our process.
| But in the end FTP was subject to a pretty broad deliberative process,
| precisely along the lines that Geoff suggests above.  We had two clearly-
| articulated alternatives, a discrete call for opinions broadcast to every
| Haskell channel we could find, a decent interval for people to respond,
| and (as it turned out) a very clear preponderance of opinion in one
| direction.  In a big community, even a broad consultation may yield a
| result that some think is ill-advised.  That's part of the joyful burden
| of being a big community.
| >>
| >> Let's look forward, not back.  I think we can do better in future than
| we have done in the past.  I don't think we can hope for unanimity, but I
| think we can reasonably seek
| >>
| >>  * transparency;
| >>  * clarity about what decisions are on the table;
| >>  * broad consultation about decisions that affect
| >>     a broad constituency; and
| >>  * a decent opportunity to debate them without having
| >>     to be involved in massive email threads.  Let's try do to that.
| >>
| >> Simon
| >>
| >> PS: For what it's worth I'm less keen on Geoff's other proposal:
| >>
| >> |  Proposal 3: A decision regarding any proposal that significantly
| affects
| >> |  backwards compatibility is within the purview of the Haskell Prime
| >> |  Committee, not the Core Libraries Committee.
| >>
| >> *Precisely* the same issues will arise whether it's CLC or HPC.  And
| the HPC is going to be jolly busy with language issues. Moving the
| question from one group to another risks avoiding the issue rather than
| addressing it.
| >
| > For the record, I am also not sure Proposal 3 is a good idea :)
| >
| > However, I do think we could clarify what the respective
| > responsibilities of the core libraries committee and Haskell Prime
| > committees are.
| >
| > One possible choice is that the core libraries committee is responsible
| > for changes to the core libraries that do not affect libraries in the
| > report. It is meant to be nimble, able to quickly deal with the large
| > volume of library changes that do not impact backwards compatibility.
| >
| > In this scenario, the Haskell Prime committee, using a longer
| > deliberative process, would consider the more impactful library changes
| > and batch them up into new reports.
| >
| > You are absolutely correct that moving the question to the Haskell Prime
| > committee risks pushing the issue around. The idea behind the separation
| > outlined above is to reduce the treadmill; the two bodies use different
| > processes, with different time frames, to arrive at decisions. Some
| > library decisions may deserve a longer deliberative process.
| >
| > Cheers,
| > Geoff
| > _______________________________________________
| > Libraries mailing list
| > Libraries at haskell.org
| >
| https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haske
| ll.org%2fcgi-
| bin%2fmailman%2flistinfo%2flibraries&data=01%7c01%7csimonpj%40064d.mgd.mic
| rosoft.com%7c6e0a5cbb4f5541caf14108d2da5dc7f8%7c72f988bf86f141af91ab2d7cd0
| 11db47%7c1&sdata=zL3zfXigvfpvdXL%2bhWuGoQzUUhGp%2bg8ofO1tGaFzlvE%3d

From johnw at newartisans.com  Wed Oct 21 21:46:29 2015
From: johnw at newartisans.com (John Wiegley)
Date: Wed, 21 Oct 2015 14:46:29 -0700
Subject: 3 release policy
In-Reply-To: <cf09d114b9c64dab9ad73741d53941aa@DB4PR30MB030.064d.mgd.msft.net>
 (Simon Peyton Jones's message of "Wed, 21 Oct 2015 07:53:00 +0000")
References: <1445370906741-5820363.post@n5.nabble.com>
 <C8A34CAA-7C55-4657-8286-16C46B3A6E27@cis.upenn.edu>
 <CAAOoiFZT6rpLYEhfEzGX3=VTyrn4XfnvqN7GZEq1SdMT7N6Rzg@mail.gmail.com>
 <CACbaDy6UK235OnhpyV1=96cof5j6V2+tKEbv__DmsKsTpAD=bw@mail.gmail.com>
 <cf09d114b9c64dab9ad73741d53941aa@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <m2zizbvqru.fsf@newartisans.com>

>>>>> Simon Peyton Jones <simonpj at microsoft.com> writes:

> I'd love to find a way to make warnings more supple, less of a blunt
> instrument. It hurts me that what is intended as a gentle hint actually ends
> up disrupting our entire ecosystem!

Since warnings are intended to mean "This could be a problem, but might not
be, be warned", there should be a case-by-case way of answering it and saying
"I know this isn't a problem". I think a pragma for disabling a particular
warning at certain code location would be a good addition to our current
disabling mechanisms?

John

From simonpj at microsoft.com  Wed Oct 21 22:17:12 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 21 Oct 2015 22:17:12 +0000
Subject: Breaking Changes and Long Term Support Haskell
In-Reply-To: <5627A4A8.7070107@apeiron.net>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk>
 <562765FE.6070808@nottingham.ac.uk>
 <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net>
 <a2781834655f4e358b95c6c5fd53e2ac@DB4PR30MB030.064d.mgd.msft.net>
 <5627A4A8.7070107@apeiron.net>
Message-ID: <a524f7507d94428da27c2fd2340fb8cd@DB4PR30MB030.064d.mgd.msft.net>

| For the record, I am also not sure Proposal 3 is a good idea :)
| 
| However, I do think we could clarify what the respective
| responsibilities of the core libraries committee and Haskell Prime
| committees are.

My instinct is this:
  Haskell Prime: language
  Core Libraries Committee: libraries

That seems simple.  If we try to move the largest and most challenging library design tasks from CLC to HP, I fear that we will overload the latter and devalue the former.

| You are absolutely correct that moving the question to the Haskell Prime
| committee risks pushing the issue around. The idea behind the separation
| outlined above is to reduce the treadmill; the two bodies use different
| processes, with different time frames, to arrive at decisions. Some
| library decisions may deserve a longer deliberative process.

I do agree that some library changes are far-reaching, and need a more deliberative process.  I think the CLC is in the process of developing such a process.  Moreover, I trust them to be able to tell the difference between low-impact and high-impact changes.

That said, as HP moves towards a new language Report, it would be good if CLC similarly moved towards a new libraries Report, so that there was a single unified document, just as we have had to date.

Simon



From mainland at apeiron.net  Wed Oct 21 22:18:34 2015
From: mainland at apeiron.net (Geoffrey Mainland)
Date: Wed, 21 Oct 2015 18:18:34 -0400
Subject: Breaking Changes and Long Term Support Haskell
In-Reply-To: <CAHEA9tMB4vgyijZBt-PWEU-SPVvm2ouw1vgntkwss38e5tSh9Q@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk>
 <562765FE.6070808@nottingham.ac.uk>
 <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net>
 <a2781834655f4e358b95c6c5fd53e2ac@DB4PR30MB030.064d.mgd.msft.net>
 <5627A4A8.7070107@apeiron.net>
 <CAHEA9tMB4vgyijZBt-PWEU-SPVvm2ouw1vgntkwss38e5tSh9Q@mail.gmail.com>
Message-ID: <56280F3A.7070902@apeiron.net>

Hi Dan,

Thank you for the historical perspective.

I was careful not to criticize the committee. Instead, I made three
concrete proposals with the hope that they would help orient a conversation.

It sounds like you are not for proposal 3. How about the other two?

My original email stated my underlying concern: we are losing valuable
members of the community not because of the technical decisions that are
being made, but because of the process by which they are being made.
That concern is what drove my proposals. It is perfectly valid to think
that that loss was the inevitable price of progress, but that is not my
view.

Cheers,
Geoff

On 10/21/15 5:22 PM, Dan Doel wrote:
> Hello,
>
> I'm Dan Doel. I'm on the core libraries committee (though I'm speaking
> only for myself). As I recall, one of the reasons I got tapped for it
> was due to my having some historical knowledge about Haskell; not
> because I was there, but because I've gone back and looked at some old
> reports and whatnot (and sometimes think they're better than what we
> have now).
>
> But, I was around (of course) when the core libraries committee
> started up, so perhaps I can play the role of historian for this as
> well.
>
> The reason the committee exists is because a couple years ago, people
> brought up the ideas that were finally realized in the
> Applicative-Monad proposal and the Foldable-Traversable proposal. A
> lot of people weighed in saying they thought they were a good idea,
> and significantly fewer people weighed in saying they thought that it
> shouldn't happen for various reasons---roughly the same things that
> people are still bringing up about these proposals.
>
> This wasn't the first time that happened, either. I think it was
> widely agreed among most users that Functor should be a superclass of
> Monad since I started learning Haskell around 10 years ago. And once
> Applicative was introduced, it was agreed that that should go in the
> middle of the two. But it appeared that it would never happen, despite
> a significant majority thinking it should, because no one wanted to do
> anything without pretty much unanimous consent.
>
> So, one question that got raised is: why should this majority of
> people even use Haskell/GHC anymore? Why shouldn't they start using
> some other language that will let them change 15-year-old mistakes, or
> adapt to ideas that weren't even available at that time (but are still
> fairly old and established, all things considered). And the answer was
> that there should be some body empowered to decide to move forward
> with these ideas, even if there is some dissent. And frankly, it
> wasn't going to be the prime committee, because it hadn't shown any
> activity in something like 3 years at the time, and even when it was
> active, it didn't make anywhere near the sort of changes that were
> being discussed.
>
> And the kicker to me is, many things that people are complaining about
> again (e.g. the FTP) were the very things that the committee was
> established to execute. I don't think we had a formal vote on that
> proposal, because we didn't need to. Our existence was in part to
> execute that proposal (and AMP). And then a year ago, when it was
> finally time to release the changes, there was another ruckus. And we
> still didn't have a CLC vote on the matter. What we did was conduct a
> community poll, and then SPJ reviewed the submissions. But I don't
> mean to pass the buck to him, because I'm pretty sure he was worried
> that we were crazy, and overstepping our bounds. Just, the results of
> the survey were sufficient for him to not overrule us.
>
> So my point is this: there seems to be some sentiment that the core
> libraries committee is unsound, and making bad decisions. But the
> complaints are mostly not even about actual decisions we made (aside
> from maybe Lennart Augustsson's, where he is unhappy with details of
> the FTP that you can blame on us, but were designed to break the least
> code, instead of being the most elegant; if we had pleased him more,
> we would have pleased others less). They are about the reasons for
> founding the committee in the first place. You can blame us, if you
> like, because I think it's certain that we would have approved them if
> we had formally voted. We just didn't even need to do so.
>
> Forgive me if I'm wrong, but suggestions that these decisions should
> have been deferred to a Haskell Prime committee mean, to me, that the
> hope is that they would have been rejected. That the Haskell Prime
> committee should have just vetoed these proposals that something like
> 80% or more of practicing Haskell users (as far as we can tell) wanted
> for years before they finally happened. That the Haskell Prime
> committee should be responsible for enforcing the very status quo that
> led to the CLC in the first place, where proposals with broad support
> but minority dissent never pass for various core modules.
>
> If this is the case, then one could simply repose the earlier
> question: why should most of these people stick around to obey by the
> Haskell Prime committee's pronouncements, instead of getting to work
> on a language that incorporates their input?
>
> And if it isn't, then I don't ultimately understand what the
> complaints are. We try to accomplish the (large) changes in a manner
> that allows transition via refactoring over multiple versions (and as
> I mentioned earlier, some complaints are that we compromised _too
> much_ for this). And in light of the more recent complaints, it's even
> been decided that our time frames should be longer. Rolling up changes
> into a report just seems like it makes transitions less smooth. Unless
> the idea is to make GHC capable of switching out entire base library
> sets; but someone has to implement that, and once you have it, it
> makes the report specifications _less_ essential.
>
> Anyhow, that's my history lesson. Take it as you (all) will.
>
> Cheers,
> -- Dan
>
> On Wed, Oct 21, 2015 at 10:43 AM, Geoffrey Mainland
> <mainland at apeiron.net> wrote:
>> On 10/21/2015 07:30 AM, Simon Peyton Jones wrote:
>>> Friends
>>>
>>> I think it's good for us to debate the question of how we should balance innovation against change; and how we should make those decisions in future.  Geoff's message had some good ideas, especially this bit:
>>>
>>> |  Proposal 2: After a suitable period of discussion on the libraries list, the
>>> |  Core Libraries Committee will summarize the arguments for and against a
>>> |  proposal and post it, along with a (justified) preliminary decision, to a
>>> |  low-traffic, announce-only email list. After another suitable period of
>>> |  discussion, they will issue a final decision. What is a suitable period of
>>> |  time? Perhaps that depends on the properties of the proposal, such as
>>> |  whether it breaks backwards compatibility.
>>>
>>> Identifying major changes to the libraries, and having a better publicised, more RFC-like process for deliberating them, would be a good thing.  I believe that the Core Libraries committee is thinking actively about this.
>>>
>>> |  Personally, I think AMP was the right thing to do, but I don't think FTP was
>>> |  the right thing.
>>>
>>> These make good examples to motivate future changes to our process.  But in the end FTP was subject to a pretty broad deliberative process, precisely along the lines that Geoff suggests above.  We had two clearly-articulated alternatives, a discrete call for opinions broadcast to every Haskell channel we could find, a decent interval for people to respond, and (as it turned out) a very clear preponderance of opinion in one direction.  In a big community, even a broad consultation may yield a result that some think is ill-advised.  That's part of the joyful burden of being a big community.
>>>
>>> Let's look forward, not back.  I think we can do better in future than we have done in the past.  I don't think we can hope for unanimity, but I think we can reasonably seek
>>>
>>>  * transparency;
>>>  * clarity about what decisions are on the table;
>>>  * broad consultation about decisions that affect
>>>     a broad constituency; and
>>>  * a decent opportunity to debate them without having
>>>     to be involved in massive email threads.  Let's try do to that.
>>>
>>> Simon
>>>
>>> PS: For what it's worth I'm less keen on Geoff's other proposal:
>>>
>>> |  Proposal 3: A decision regarding any proposal that significantly affects
>>> |  backwards compatibility is within the purview of the Haskell Prime
>>> |  Committee, not the Core Libraries Committee.
>>>
>>> *Precisely* the same issues will arise whether it's CLC or HPC.  And the HPC is going to be jolly busy with language issues. Moving the question from one group to another risks avoiding the issue rather than addressing it.
>> For the record, I am also not sure Proposal 3 is a good idea :)
>>
>> However, I do think we could clarify what the respective
>> responsibilities of the core libraries committee and Haskell Prime
>> committees are.
>>
>> One possible choice is that the core libraries committee is responsible
>> for changes to the core libraries that do not affect libraries in the
>> report. It is meant to be nimble, able to quickly deal with the large
>> volume of library changes that do not impact backwards compatibility.
>>
>> In this scenario, the Haskell Prime committee, using a longer
>> deliberative process, would consider the more impactful library changes
>> and batch them up into new reports.
>>
>> You are absolutely correct that moving the question to the Haskell Prime
>> committee risks pushing the issue around. The idea behind the separation
>> outlined above is to reduce the treadmill; the two bodies use different
>> processes, with different time frames, to arrive at decisions. Some
>> library decisions may deserve a longer deliberative process.
>>
>> Cheers,
>> Geoff
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


From Henrik.Nilsson at nottingham.ac.uk  Wed Oct 21 23:09:57 2015
From: Henrik.Nilsson at nottingham.ac.uk (Henrik Nilsson)
Date: Thu, 22 Oct 2015 00:09:57 +0100
Subject: Breaking Changes and Long Term Support Haskell
In-Reply-To: <CAHEA9tMB4vgyijZBt-PWEU-SPVvm2ouw1vgntkwss38e5tSh9Q@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>	<alpine.DEB.2.02.1510011830520.7958@sputnik>	<560D8DA4.2080706@gmail.com>	<560E57D1.9060302@nottingham.ac.uk>	<6C299172-B95C-44C0-A664-F92AD11218B6@me.com>	<B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>	<51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>	<CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>	<1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>	<etPan.56128a31.41b8da8.7b73@mbp.local>	<A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>	<5626DEDD.8040202@apeiron.net>	<56274BC2.20507@nottingham.ac.uk>	<562765FE.6070808@nottingham.ac.uk>	<22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net>	<a2781834655f4e358b95c6c5fd53e2ac@DB4PR30MB030.064d.mgd.msft.net>	<5627A4A8.7070107@apeiron.net>
 <CAHEA9tMB4vgyijZBt-PWEU-SPVvm2ouw1vgntkwss38e5tSh9Q@mail.gmail.com>
Message-ID: <56281B45.8030708@nottingham.ac.uk>

Hi Dan,

Thanks for the history lesson. You do make many valid points.
And I also want to say thank you for the hard work that CLC
has put in.

Let me nevertheless react to a handful of things:

 > And the answer was that there should be some body empowered to decide
 > to move forward with these ideas, even if there is some dissent. And
 > frankly, it wasn't going to be the prime committee, because it hadn't
 > shown any activity in something like 3 years at the time, and even
 > when it was active, it didn't make anywhere near the sort of changes
 > that were being discussed.

I have seen criticism of the Haskell committee along similar lines
before, but I think it is overly simplistic, and arguably unfair,
for two reasons. First, squarely measuring accomplishment in terms
of number or scope of changes, which seems to be the gist (apologies
if I misunderstand), is, frankly, naive. In many ways, what didn't
change, for example, can be at least as important as what did for
establishing a language as a viable and attractive proposition for
large scale work. And the value of that for a language community as a
whole is hard to overstate. Now, I have no real data to back up that the
committee achieved that. But it is clear that Haskell has grown
a lot over the past 5 to 10 years, i.e. well before AMP, FTP, etc.
So maybe the last instance of the Haskell committee actually achieved
a great deal more than some seem willing to give it credit for.

Secondly, let us not forget that at least one highly controversial
and very breaking change was adopted for Haskell 2010: dropping
n + k patterns. The reason that went through was that there were very
compelling technical reasons and ultimately a clear case for
the advantages outweighing the disadvantages by a wide margin. So it is
not as if a committee cannot make controversial decisions. That does
presuppose that the majority of its members fundamentally have the 
interest of the community at large at the fore, and are willing to take
good arguments aboard, rather than being prone to take stances mainly
for "political" reasons. Fortunately, I strongly believe the Haskell
community by and large is rational in this sense.

 > Forgive me if I'm wrong, but suggestions that these decisions should
 > have been deferred to a Haskell Prime committee mean, to me, that the
 > hope is that they would have been rejected.

OK, you are forgiven! I can of course only speak for myself, but I have
followed this discussion very carefully, and discussed with many people
in person. And as far as I can tell, there is absolutely nothing to
suggest that the reason that those who are unhappy with the process by
which AMP, FTP etc. happened (or by some of the details of those
proposals)  raise the possibility that the Haskell committee in one way
or another should have been (or in the future be) involved at least as
a vetting instance when it comes to the most far-reaching library
changes, is a secret hope of "death by committee".

Anyway, whether there are one or two committees ultimately does not
really matter, as long as both are widely seen to have a wide mandate
for whatever they are entrusted with, and as long as the process for
far-reaching changes is sufficiently robust and long.

 > That the Haskell Prime
 > committee should have just vetoed these proposals that something like
 > 80% or more of practicing Haskell users (as far as we can tell) wanted
 > for years before they finally happened.

Now, I have no desire to diminish the significance of the outcome of
that poll. Nor have I any desire to be branded as an "anti-democrat".
But if I am, so be it: I am bracing myself.

However, I have to point out that there is a lot more to
well-functioning democracies than simple majority votes. Look at any
developed democracy and there are lots of checks and balances in place
to safe-guard the interests of an as broad part of the population as
possible. In a federated state, just to give one example, there is
often a bicameral parliament where the states (broadly) have equal say
in one of the chambers irrespective of their size.

And yes, the workings of democracies are slow, sometimes painfully
so, but fundamentally that is for good reason.

To return to the case of a programming language community,
it is pretty much by definition going to be the case that a small
part of that community will be hit disproportionately hard by
changes to the language and/or its core libraries.

Their interests need to be adequately safeguarded too, or they will
surely jump ship in search of high and dry ground rather than run the
risk of drowning in the next wave of changes.

This, to the best of my understanding, is where I and others who
are suggesting that far-reaching changes should go past a
committee with a clear mandate and a sufficiently robust and long
process are coming from.

And I believe this is also what underlies Lennart's sentiment:

 > I think voting to decide these kind of issues a terrible idea; we
 > might as well throw dice.

Best,

/Henrik

-- 
Henrik Nilsson
School of Computer Science
The University of Nottingham
nhn at cs.nott.ac.uk




This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it. 

Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.


From johnw at newartisans.com  Wed Oct 21 23:37:44 2015
From: johnw at newartisans.com (John Wiegley)
Date: Wed, 21 Oct 2015 16:37:44 -0700
Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving
 `return` out of `Monad`
In-Reply-To: <56274BC2.20507@nottingham.ac.uk> (Henrik Nilsson's message of
 "Wed, 21 Oct 2015 09:24:34 +0100")
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk>
Message-ID: <m2y4evu71z.fsf@newartisans.com>

>>>>> Henrik Nilsson <Henrik.Nilsson at nottingham.ac.uk> writes:

> So before breaking anything more, that being code, research papers, books,
> what people have learned, or even the community itself, it is time to very
> carefully think about what the appropriate processes should be for going
> forward.

Hi Henrik,

I'd really like to understand your position better, since I'm pretty sure it's
not just a juxtaposition between "change" or "no change".

How would you like to see Haskell grow in the future? What does a successful
process to evolve the language look like to you? Is it the change causing you
difficulty, or the way we arrive at the change?

John

From greg at gregorycollins.net  Thu Oct 22 00:42:44 2015
From: greg at gregorycollins.net (Gregory Collins)
Date: Wed, 21 Oct 2015 17:42:44 -0700
Subject: Breaking Changes and Long Term Support Haskell
In-Reply-To: <56280F3A.7070902@apeiron.net>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk>
 <562765FE.6070808@nottingham.ac.uk>
 <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net>
 <a2781834655f4e358b95c6c5fd53e2ac@DB4PR30MB030.064d.mgd.msft.net>
 <5627A4A8.7070107@apeiron.net>
 <CAHEA9tMB4vgyijZBt-PWEU-SPVvm2ouw1vgntkwss38e5tSh9Q@mail.gmail.com>
 <56280F3A.7070902@apeiron.net>
Message-ID: <CAHZrzdr0DFFXCcVdOQcudgURNxQ+b7Dt3-NCxqfud1Ugej9DfQ@mail.gmail.com>

On Wed, Oct 21, 2015 at 3:18 PM, Geoffrey Mainland <mainland at apeiron.net>
wrote:

> My original email stated my underlying concern: we are losing valuable
> members of the community not because of the technical decisions that are
> being made, but because of the process by which they are being made.
>

I disagree. The issue is not process, it's posture: e.g. what do we think
the language is for, who are its users, what factors do we take into
consideration when making decisions about how to change things (and
especially: how do we weight those factors), etc. There are several
important constituencies within the Haskell community, and they usually
have very different attitudes towards what's relevant to take into
consideration when deciding what to do.

For example: Haskell has had great success and wide adoption in academic
research within a few fields centred around ICFP, POPL, and the like. We
all like a GHC that serves as a testbed for research and sometimes that is
going to mean churn. The research world would probably be happiest with a
Haskell that evolved quickly and speculatively, and that dispensed with
blemishes with savage efficiency: if you're doing research you're on the
treadmill, almost by definition, and you're delighted that we're finally
making some rapid progress on fixing up some of the longstanding warts.

If you're a practitioner, you are interested in using Haskell for, y'know,
writing programs. You're probably in one of two camps: you're in "green
field" mode writing a lot of new code (early stage startups, prototype
work, etc), or you're maintaining/extending programs you've already written
that are out "in the field" for you doing useful work. Laura Wingerd calls
this the "annealing temperature" of software, and I think this is a nice
metaphor to describe it. How tolerant you are of ecosystem churn depends on
what your temperature is: and I think it should be obvious to everyone that
Haskell having "success" for programming work would mean that lots of
useful and correct programs get written, so everyone who is in the former
camp will cool over time to join the latter.

I've made the point before and I don't really want to belabor it: our de
facto collective posture towards breaking stuff, especially in the past few
years, has been extremely permissive, and this alienates people who are
maintaining working programs. I'm actually firmly of the belief that the
existing committee doesn't really have process issues, and in fact, that
often it's been pretty careful to minimize the impact of the changes it
wants to make. As others have pointed out, lots of the churn actually comes
from platform libraries, which are out of the purview of this group.

All I'm saying is that if we want to appeal to or cater to working software
engineers, we have to be a lot less cavalier about causing more work for
them, and we need to prize stability of the core infrastructure more
highly. That'd be a broader cultural change, and that goes beyond process:
it's policy.

-- 
Gregory Collins <greg at gregorycollins.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151021/01f36570/attachment-0001.html>

From dan.doel at gmail.com  Thu Oct 22 05:09:48 2015
From: dan.doel at gmail.com (Dan Doel)
Date: Thu, 22 Oct 2015 01:09:48 -0400
Subject: Breaking Changes and Long Term Support Haskell
In-Reply-To: <56280F3A.7070902@apeiron.net>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk>
 <562765FE.6070808@nottingham.ac.uk>
 <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net>
 <a2781834655f4e358b95c6c5fd53e2ac@DB4PR30MB030.064d.mgd.msft.net>
 <5627A4A8.7070107@apeiron.net>
 <CAHEA9tMB4vgyijZBt-PWEU-SPVvm2ouw1vgntkwss38e5tSh9Q@mail.gmail.com>
 <56280F3A.7070902@apeiron.net>
Message-ID: <CAHEA9tOQAZf5oSQpwkfnTzdoHK8b5dyfCP3VD3jrK_-rLQ6Tkw@mail.gmail.com>

For proposal 3, I don't see what difference it makes whether a
refreshed Haskell committee or a new libraries committee makes
decisions that affect backwards compatibility. A name doesn't ensure
good decision making. The only difference I can see is that the
Haskell committee might only publish final decisions every couple
years. But the Haskell report also isn't designed to describe
migration plans between feature revisions; unless the plan is to start
incorporating library deprecation and whatnot into the report (which
would be odd to me). But that would just be doing the same thing
slower, so it'd be little different than making library changes over 6
to 9 GHC versions instead of 3.

For proposal 2, I don't know how effective it will be in practice. I
believe it is already the job of a proposal submitter to summarize the
arguments made about it, according to the library proposal guidelines.
We could post those summaries to another list. But unless more people
promise they will be diligent about reading that list, I'm not sure
that one factor in these dust ups (surprise) will actually be any
different.

Also, if amount of discussion is at issue, I'm not sure I agree. For
AMP, I was waiting a decade, more or less. I thought we should do it,
other people thought we shouldn't because it would break things. I
don't know what more there was to discuss, except there was more stuff
to break the longer we waited.

As for FTP, some aspects only became known as the proposal was
implemented, and I don't know that they would have been realized
regardless of how long the proposal were discussed. And then we still
had a month or so of discussion after the implementation was
finalized, on the cusp of GHC 7.10 being released. So how much more
_was_ needed, that people are now discussing it again?

If it's just about documenting more things, there's certainly no harm in that.

For 1, I don't have a very strong opinion. If pressed, I would
probably express some similar sentiments to Henrik. I certainly don't
think Haskell would be nearly as good as it is if it were a simple
majority vote by all users (and I probably wouldn't use it if that's
how things were decided). Would a community vote for libraries
committee be better than appointment by people who previously held the
power (but have more to do than any human can accomplish)? I don't
know.

I should say, though, that things are not now run by simple majority
vote. What we conducted a year ago was a survey, where people
submitted their thoughts. I didn't get to read them, because they were
private, and it wasn't my decision to make. But it was not just +80
-20.

With regard to your last paragraph, unless I've missed something (and
I confess that I haven't read every comment in these threads), the
recent resignations didn't express disagreement with the decision
making process. They expressed disagreement with the (technical)
decisions (and their effects). I don't see how a different process
could have solved that unless it is expected that it would have made
different decisions.

-- Dan

On Wed, Oct 21, 2015 at 6:18 PM, Geoffrey Mainland <mainland at apeiron.net> wrote:
> Hi Dan,
>
> Thank you for the historical perspective.
>
> I was careful not to criticize the committee. Instead, I made three
> concrete proposals with the hope that they would help orient a conversation.
>
> It sounds like you are not for proposal 3. How about the other two?
>
> My original email stated my underlying concern: we are losing valuable
> members of the community not because of the technical decisions that are
> being made, but because of the process by which they are being made.
> That concern is what drove my proposals. It is perfectly valid to think
> that that loss was the inevitable price of progress, but that is not my
> view.
>
> Cheers,
> Geoff
>
> On 10/21/15 5:22 PM, Dan Doel wrote:
>> Hello,
>>
>> I'm Dan Doel. I'm on the core libraries committee (though I'm speaking
>> only for myself). As I recall, one of the reasons I got tapped for it
>> was due to my having some historical knowledge about Haskell; not
>> because I was there, but because I've gone back and looked at some old
>> reports and whatnot (and sometimes think they're better than what we
>> have now).
>>
>> But, I was around (of course) when the core libraries committee
>> started up, so perhaps I can play the role of historian for this as
>> well.
>>
>> The reason the committee exists is because a couple years ago, people
>> brought up the ideas that were finally realized in the
>> Applicative-Monad proposal and the Foldable-Traversable proposal. A
>> lot of people weighed in saying they thought they were a good idea,
>> and significantly fewer people weighed in saying they thought that it
>> shouldn't happen for various reasons---roughly the same things that
>> people are still bringing up about these proposals.
>>
>> This wasn't the first time that happened, either. I think it was
>> widely agreed among most users that Functor should be a superclass of
>> Monad since I started learning Haskell around 10 years ago. And once
>> Applicative was introduced, it was agreed that that should go in the
>> middle of the two. But it appeared that it would never happen, despite
>> a significant majority thinking it should, because no one wanted to do
>> anything without pretty much unanimous consent.
>>
>> So, one question that got raised is: why should this majority of
>> people even use Haskell/GHC anymore? Why shouldn't they start using
>> some other language that will let them change 15-year-old mistakes, or
>> adapt to ideas that weren't even available at that time (but are still
>> fairly old and established, all things considered). And the answer was
>> that there should be some body empowered to decide to move forward
>> with these ideas, even if there is some dissent. And frankly, it
>> wasn't going to be the prime committee, because it hadn't shown any
>> activity in something like 3 years at the time, and even when it was
>> active, it didn't make anywhere near the sort of changes that were
>> being discussed.
>>
>> And the kicker to me is, many things that people are complaining about
>> again (e.g. the FTP) were the very things that the committee was
>> established to execute. I don't think we had a formal vote on that
>> proposal, because we didn't need to. Our existence was in part to
>> execute that proposal (and AMP). And then a year ago, when it was
>> finally time to release the changes, there was another ruckus. And we
>> still didn't have a CLC vote on the matter. What we did was conduct a
>> community poll, and then SPJ reviewed the submissions. But I don't
>> mean to pass the buck to him, because I'm pretty sure he was worried
>> that we were crazy, and overstepping our bounds. Just, the results of
>> the survey were sufficient for him to not overrule us.
>>
>> So my point is this: there seems to be some sentiment that the core
>> libraries committee is unsound, and making bad decisions. But the
>> complaints are mostly not even about actual decisions we made (aside
>> from maybe Lennart Augustsson's, where he is unhappy with details of
>> the FTP that you can blame on us, but were designed to break the least
>> code, instead of being the most elegant; if we had pleased him more,
>> we would have pleased others less). They are about the reasons for
>> founding the committee in the first place. You can blame us, if you
>> like, because I think it's certain that we would have approved them if
>> we had formally voted. We just didn't even need to do so.
>>
>> Forgive me if I'm wrong, but suggestions that these decisions should
>> have been deferred to a Haskell Prime committee mean, to me, that the
>> hope is that they would have been rejected. That the Haskell Prime
>> committee should have just vetoed these proposals that something like
>> 80% or more of practicing Haskell users (as far as we can tell) wanted
>> for years before they finally happened. That the Haskell Prime
>> committee should be responsible for enforcing the very status quo that
>> led to the CLC in the first place, where proposals with broad support
>> but minority dissent never pass for various core modules.
>>
>> If this is the case, then one could simply repose the earlier
>> question: why should most of these people stick around to obey by the
>> Haskell Prime committee's pronouncements, instead of getting to work
>> on a language that incorporates their input?
>>
>> And if it isn't, then I don't ultimately understand what the
>> complaints are. We try to accomplish the (large) changes in a manner
>> that allows transition via refactoring over multiple versions (and as
>> I mentioned earlier, some complaints are that we compromised _too
>> much_ for this). And in light of the more recent complaints, it's even
>> been decided that our time frames should be longer. Rolling up changes
>> into a report just seems like it makes transitions less smooth. Unless
>> the idea is to make GHC capable of switching out entire base library
>> sets; but someone has to implement that, and once you have it, it
>> makes the report specifications _less_ essential.
>>
>> Anyhow, that's my history lesson. Take it as you (all) will.
>>
>> Cheers,
>> -- Dan
>>
>> On Wed, Oct 21, 2015 at 10:43 AM, Geoffrey Mainland
>> <mainland at apeiron.net> wrote:
>>> On 10/21/2015 07:30 AM, Simon Peyton Jones wrote:
>>>> Friends
>>>>
>>>> I think it's good for us to debate the question of how we should balance innovation against change; and how we should make those decisions in future.  Geoff's message had some good ideas, especially this bit:
>>>>
>>>> |  Proposal 2: After a suitable period of discussion on the libraries list, the
>>>> |  Core Libraries Committee will summarize the arguments for and against a
>>>> |  proposal and post it, along with a (justified) preliminary decision, to a
>>>> |  low-traffic, announce-only email list. After another suitable period of
>>>> |  discussion, they will issue a final decision. What is a suitable period of
>>>> |  time? Perhaps that depends on the properties of the proposal, such as
>>>> |  whether it breaks backwards compatibility.
>>>>
>>>> Identifying major changes to the libraries, and having a better publicised, more RFC-like process for deliberating them, would be a good thing.  I believe that the Core Libraries committee is thinking actively about this.
>>>>
>>>> |  Personally, I think AMP was the right thing to do, but I don't think FTP was
>>>> |  the right thing.
>>>>
>>>> These make good examples to motivate future changes to our process.  But in the end FTP was subject to a pretty broad deliberative process, precisely along the lines that Geoff suggests above.  We had two clearly-articulated alternatives, a discrete call for opinions broadcast to every Haskell channel we could find, a decent interval for people to respond, and (as it turned out) a very clear preponderance of opinion in one direction.  In a big community, even a broad consultation may yield a result that some think is ill-advised.  That's part of the joyful burden of being a big community.
>>>>
>>>> Let's look forward, not back.  I think we can do better in future than we have done in the past.  I don't think we can hope for unanimity, but I think we can reasonably seek
>>>>
>>>>  * transparency;
>>>>  * clarity about what decisions are on the table;
>>>>  * broad consultation about decisions that affect
>>>>     a broad constituency; and
>>>>  * a decent opportunity to debate them without having
>>>>     to be involved in massive email threads.  Let's try do to that.
>>>>
>>>> Simon
>>>>
>>>> PS: For what it's worth I'm less keen on Geoff's other proposal:
>>>>
>>>> |  Proposal 3: A decision regarding any proposal that significantly affects
>>>> |  backwards compatibility is within the purview of the Haskell Prime
>>>> |  Committee, not the Core Libraries Committee.
>>>>
>>>> *Precisely* the same issues will arise whether it's CLC or HPC.  And the HPC is going to be jolly busy with language issues. Moving the question from one group to another risks avoiding the issue rather than addressing it.
>>> For the record, I am also not sure Proposal 3 is a good idea :)
>>>
>>> However, I do think we could clarify what the respective
>>> responsibilities of the core libraries committee and Haskell Prime
>>> committees are.
>>>
>>> One possible choice is that the core libraries committee is responsible
>>> for changes to the core libraries that do not affect libraries in the
>>> report. It is meant to be nimble, able to quickly deal with the large
>>> volume of library changes that do not impact backwards compatibility.
>>>
>>> In this scenario, the Haskell Prime committee, using a longer
>>> deliberative process, would consider the more impactful library changes
>>> and batch them up into new reports.
>>>
>>> You are absolutely correct that moving the question to the Haskell Prime
>>> committee risks pushing the issue around. The idea behind the separation
>>> outlined above is to reduce the treadmill; the two bodies use different
>>> processes, with different time frames, to arrive at decisions. Some
>>> library decisions may deserve a longer deliberative process.
>>>
>>> Cheers,
>>> Geoff
>>> _______________________________________________
>>> Libraries mailing list
>>> Libraries at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>

From strake888 at gmail.com  Thu Oct 22 05:40:43 2015
From: strake888 at gmail.com (M Farkas-Dyck)
Date: Wed, 21 Oct 2015 21:40:43 -0800
Subject: 3 release policy
In-Reply-To: <m2zizbvqru.fsf@newartisans.com>
References: <1445370906741-5820363.post@n5.nabble.com>
 <C8A34CAA-7C55-4657-8286-16C46B3A6E27@cis.upenn.edu>
 <CAAOoiFZT6rpLYEhfEzGX3=VTyrn4XfnvqN7GZEq1SdMT7N6Rzg@mail.gmail.com>
 <CACbaDy6UK235OnhpyV1=96cof5j6V2+tKEbv__DmsKsTpAD=bw@mail.gmail.com>
 <cf09d114b9c64dab9ad73741d53941aa@DB4PR30MB030.064d.mgd.msft.net>
 <m2zizbvqru.fsf@newartisans.com>
Message-ID: <CAL3m8eCjXKq4W9z0YicO5KsO9=GG=bP1pPh5a2_swZLrDbeL7w@mail.gmail.com>

On 21/10/2015, John Wiegley <johnw at newartisans.com> wrote:
> Since warnings are intended to mean "This could be a problem, but might not
> be, be warned", there should be a case-by-case way of answering it and
> saying
> "I know this isn't a problem". I think a pragma for disabling a particular
> warning at certain code location would be a good addition to our current
> disabling mechanisms?

I hope we won't warn about unused warning suppression...

From taruti at taruti.net  Thu Oct 22 06:04:10 2015
From: taruti at taruti.net (Taru Karttunen)
Date: Thu, 22 Oct 2015 09:04:10 +0300
Subject: Breaking Changes and Long Term Support Haskell
In-Reply-To: <CAHZrzdr0DFFXCcVdOQcudgURNxQ+b7Dt3-NCxqfud1Ugej9DfQ@mail.gmail.com>
References: <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk>
 <562765FE.6070808@nottingham.ac.uk>
 <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net>
 <a2781834655f4e358b95c6c5fd53e2ac@DB4PR30MB030.064d.mgd.msft.net>
 <5627A4A8.7070107@apeiron.net>
 <CAHEA9tMB4vgyijZBt-PWEU-SPVvm2ouw1vgntkwss38e5tSh9Q@mail.gmail.com>
 <56280F3A.7070902@apeiron.net>
 <CAHZrzdr0DFFXCcVdOQcudgURNxQ+b7Dt3-NCxqfud1Ugej9DfQ@mail.gmail.com>
Message-ID: <EE205C499E6DFEBBF1C1ABFA5B1672@mail.local>

On 21.10 17:42, Gregory Collins wrote:
> All I'm saying is that if we want to appeal to or cater to working software
> engineers, we have to be a lot less cavalier about causing more work for
> them, and we need to prize stability of the core infrastructure more
> highly. That'd be a broader cultural change, and that goes beyond process:
> it's policy.

I think that how the changes are handled can make a large difference.

E.g. if

A) Most of Hackage (including dependencies) compiles with new GHC.
(stack & stackage helps somewhat)

B) There is an automated tool that can be used to fix most code
to compile with new versions of GHC without warnings or CPP.

C) Hackage displays vocally what works with which versions of
GHC (Status reports do help somewhat)

Then I think much of the complaints would go away.

- Taru Karttunen

From ekmett at gmail.com  Thu Oct 22 06:18:29 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Thu, 22 Oct 2015 02:18:29 -0400
Subject: Breaking Changes and Long Term Support Haskell
In-Reply-To: <EE205C499E6DFEBBF1C1ABFA5B1672@mail.local>
References: <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk>
 <562765FE.6070808@nottingham.ac.uk>
 <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net>
 <a2781834655f4e358b95c6c5fd53e2ac@DB4PR30MB030.064d.mgd.msft.net>
 <5627A4A8.7070107@apeiron.net>
 <CAHEA9tMB4vgyijZBt-PWEU-SPVvm2ouw1vgntkwss38e5tSh9Q@mail.gmail.com>
 <56280F3A.7070902@apeiron.net>
 <CAHZrzdr0DFFXCcVdOQcudgURNxQ+b7Dt3-NCxqfud1Ugej9DfQ@mail.gmail.com>
 <EE205C499E6DFEBBF1C1ABFA5B1672@mail.local>
Message-ID: <CAJumaK8MG=b_dO1gFmknE5K6kTWDT_1JwuNirLVJcy=DhxLpaw@mail.gmail.com>

On Thu, Oct 22, 2015 at 2:04 AM, Taru Karttunen <taruti at taruti.net> wrote:

> E.g. if
>
> A) Most of Hackage (including dependencies) compiles with new GHC.
> (stack & stackage helps somewhat)
>
> B) There is an automated tool that can be used to fix most code
> to compile with new versions of GHC without warnings or CPP.
>
> C) Hackage displays vocally what works with which versions of
> GHC (Status reports do help somewhat)
>


> Then I think much of the complaints would go away.


If we had those things, indeed they would!

However, beyond A (GHC 7.10 was tested more extensively against
hackage/stackage than any previous release of Haskell by far!), the others
require various degrees of engineering effort, including some way to deal
with refactoring code that already has CPP in it, more extensive build-bot
services, etc. and those sort of non-trivial artifacts just haven't been
forthcoming. =/

I would be very happy if those things showed up, however.

-Edward
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151022/f8a71dce/attachment.html>

From ekmett at gmail.com  Thu Oct 22 06:40:06 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Thu, 22 Oct 2015 02:40:06 -0400
Subject: Breaking Changes and Long Term Support Haskell
In-Reply-To: <CAHZrzdr0DFFXCcVdOQcudgURNxQ+b7Dt3-NCxqfud1Ugej9DfQ@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk>
 <562765FE.6070808@nottingham.ac.uk>
 <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net>
 <a2781834655f4e358b95c6c5fd53e2ac@DB4PR30MB030.064d.mgd.msft.net>
 <5627A4A8.7070107@apeiron.net>
 <CAHEA9tMB4vgyijZBt-PWEU-SPVvm2ouw1vgntkwss38e5tSh9Q@mail.gmail.com>
 <56280F3A.7070902@apeiron.net>
 <CAHZrzdr0DFFXCcVdOQcudgURNxQ+b7Dt3-NCxqfud1Ugej9DfQ@mail.gmail.com>
Message-ID: <CAJumaK_7ctgnU1cw0BZM-fourh2yaNuO+K2fc-krNNXss11WDg@mail.gmail.com>

On Wed, Oct 21, 2015 at 8:42 PM, Gregory Collins <greg at gregorycollins.net>
wrote:

>
> On Wed, Oct 21, 2015 at 3:18 PM, Geoffrey Mainland <mainland at apeiron.net>
> wrote:
>
>> My original email stated my underlying concern: we are losing valuable
>> members of the community not because of the technical decisions that are
>> being made, but because of the process by which they are being made.
>>
> [If] you're doing research you're on the treadmill, almost by definition,
> and you're delighted that we're finally making some rapid progress on
> fixing up some of the longstanding warts.
>
> If you're a practitioner, you are interested in using Haskell for, y'know,
> writing programs. You're probably in one of two camps: you're in "green
> field" mode writing a lot of new code (early stage startups, prototype
> work, etc), or you're maintaining/extending programs you've already written
> that are out "in the field" for you doing useful work. Laura Wingerd calls
> this the "annealing temperature" of software, and I think this is a nice
> metaphor to describe it. How tolerant you are of ecosystem churn depends on
> what your temperature is: and I think it should be obvious to everyone that
> Haskell having "success" for programming work would mean that lots of
> useful and correct programs get written, so everyone who is in the former
> camp will cool over time to join the latter.
>

I've made the point before and I don't really want to belabor it: our de
> facto collective posture towards breaking stuff, especially in the past few
> years, has been extremely permissive, and this alienates people who are
> maintaining working programs.
>

Even among people who purported to be teaching Haskell or using Haskell
today in industry the margin of preference for the concrete FTP proposal
was ~79%. This was considerably higher than I expected in two senses. One:
there were a lot more people who claimed to be in one of those two roles
than I expected by far, and two: their appetite for change was higher than
I expected. I initially expected to see a stronger "academic vs. industry"
split in the poll, but the groups were only distinguishable by a few
percentage point delta, so while I expected roughly the end percentage of
the poll, based on the year prior I'd spent running around the planet to
user group meetings and the like, I expected it mostly because I expected
more hobbyists and less support among industrialists.

>
I'm actually firmly of the belief that the existing committee doesn't
> really have process issues, and in fact, that often it's been pretty
> careful to minimize the impact of the changes it wants to make. As others
> have pointed out, lots of the churn actually comes from platform libraries,
> which are out of the purview of this group.
>

Historically we've had a bit of a split personality on this front. Nothing
that touches the Prelude had changed in 17 years. On the other hand the
platform libraries had maintained a pretty heavy rolling wave of breakage
the entire time I've been around in the community. On a more experimental
feature front, I've lost count of the number of different things we've done
to Typeable or template-haskell.


> All I'm saying is that if we want to appeal to or cater to working
> software engineers, we have to be a lot less cavalier about causing more
> work for them, and we need to prize stability of the core infrastructure
> more highly. That'd be a broader cultural change, and that goes beyond
> process: it's policy.
>

The way things are shaping up, we've had 17 years of rock solid stability,
1 release that incorporated changes that were designed to minimize impact,
to the point that the majority of the objections against them are of the
form where people would prefer that we broke _more_ code, to get a more
sensible state. Going forward, it looks like the next 2 GHC releases will
have basically nothing affecting the Prelude, and there will be another
punctuation in the equilibrium around 8.4 as the next set of changes kicks
in over 8.4 and 8.6 That gives 2 years worth of advance notice of pending
changes, and a pretty strong guarantee from the committee that you should
be able to maintain code with a 3 release window without running afoul of
warnings or needing CPP.

So, out of curiosity, what additional stability policy is it that you seek?

-Edward
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151022/8f6e0fb8/attachment-0001.html>

From hvr at gnu.org  Thu Oct 22 07:04:29 2015
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Thu, 22 Oct 2015 09:04:29 +0200
Subject: Breaking Changes and Long Term Support Haskell
In-Reply-To: <EE205C499E6DFEBBF1C1ABFA5B1672@mail.local> (Taru Karttunen's
 message of "Thu, 22 Oct 2015 09:04:10 +0300")
References: <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk>
 <562765FE.6070808@nottingham.ac.uk>
 <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net>
 <a2781834655f4e358b95c6c5fd53e2ac@DB4PR30MB030.064d.mgd.msft.net>
 <5627A4A8.7070107@apeiron.net>
 <CAHEA9tMB4vgyijZBt-PWEU-SPVvm2ouw1vgntkwss38e5tSh9Q@mail.gmail.com>
 <56280F3A.7070902@apeiron.net>
 <CAHZrzdr0DFFXCcVdOQcudgURNxQ+b7Dt3-NCxqfud1Ugej9DfQ@mail.gmail.com>
 <EE205C499E6DFEBBF1C1ABFA5B1672@mail.local>
Message-ID: <878u6v9yf6.fsf@gnu.org>

On 2015-10-22 at 08:04:10 +0200, Taru Karttunen wrote:

[...]

> B) There is an automated tool that can be used to fix most code
> to compile with new versions of GHC without warnings or CPP.

Fyi, Alan is currently working on levaraging HaRe[1] in

 https://github.com/alanz/Hs2010To201x (the `parsing-only` branch)

and it's already showing great promise. However, tools like this will
only be able to handle the no-brainer cases, as in general it's a NP
hard problem. But luckily, those boring mechanical refactorings usually
represent the vast majority, and that's the tedious work we want
tooling to assist us most with.


> C) Hackage displays vocally what works with which versions of
> GHC (Status reports do help somewhat)


I.e. something like

  http://matrix.hackage.haskell.org/package/text

? :-)


 [1]: Btw, here's a recent talk which also mentions the use-case of using
      HaRe to update between Haskell Report revisions or `base` versions:
 
      https://skillsmatter.com/skillscasts/6539-a-new-foundation-for-refactoring-ghc-exactprint

From olshanskydr at gmail.com  Thu Oct 22 10:08:38 2015
From: olshanskydr at gmail.com (Dmitry Olshansky)
Date: Thu, 22 Oct 2015 13:08:38 +0300
Subject: 3 release policy
In-Reply-To: <1445370906741-5820363.post@n5.nabble.com>
References: <1445370906741-5820363.post@n5.nabble.com>
Message-ID: <CAHe9v2J4=4HzLRikE7J7K_1R0juiXMkp9=6e7VuOLbc74ixe5w@mail.gmail.com>

Personally as user of libraries I have no problem with warnings. Because
- I can't improve it
- I got it only once when install library

I just care about warnings in my projects and that is not so hard.

So I want to say that it is not a big deal. Perhaps warning's levels are
good but simplicity is more important for me.

Dmitry

2015-10-20 22:55 GMT+03:00 Jeremy <voldermort at hotmail.com>:

> A "3 release policy" has been recently mentioned several times, whereby it
> should always be possible to write code that compiles with the last three
> releases of GHC, without generating any -Wall warnings.
>
> The no warning requirement seems excessively harsh. Will early warnings of
> impending breakage really cause so much trouble that accepted proposals
> have
> to be dragged out over several years to avoid them? If so, would a flag to
> suppress the warnings suffice?
>
> I should note that GHC has traditionally had no qualms about introducing
> new
> warnings, on by default.
>
>
>
> --
> View this message in context:
> http://haskell.1045720.n5.nabble.com/3-release-policy-tp5820363.html
> Sent from the Haskell - Libraries mailing list archive at Nabble.com.
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151022/a95226aa/attachment.html>

From taruti at taruti.net  Thu Oct 22 10:52:17 2015
From: taruti at taruti.net (Taru Karttunen)
Date: Thu, 22 Oct 2015 13:52:17 +0300
Subject: Breaking Changes and Long Term Support Haskell
In-Reply-To: <878u6v9yf6.fsf@gnu.org>
References: <56274BC2.20507@nottingham.ac.uk>
 <562765FE.6070808@nottingham.ac.uk>
 <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net>
 <a2781834655f4e358b95c6c5fd53e2ac@DB4PR30MB030.064d.mgd.msft.net>
 <5627A4A8.7070107@apeiron.net>
 <CAHEA9tMB4vgyijZBt-PWEU-SPVvm2ouw1vgntkwss38e5tSh9Q@mail.gmail.com>
 <56280F3A.7070902@apeiron.net>
 <CAHZrzdr0DFFXCcVdOQcudgURNxQ+b7Dt3-NCxqfud1Ugej9DfQ@mail.gmail.com>
 <EE205C499E6DFEBBF1C1ABFA5B1672@mail.local>
 <878u6v9yf6.fsf@gnu.org>
Message-ID: <0068D6BB4E7EC3FCA343D9CB91AF56@mail.local>

On 22.10 09:04, Herbert Valerio Riedel wrote:
> Fyi, Alan is currently working on levaraging HaRe[1] in
> 
>  https://github.com/alanz/Hs2010To201x (the `parsing-only` branch)
> 
> and it's already showing great promise. However, tools like this will
> only be able to handle the no-brainer cases, as in general it's a NP
> hard problem. But luckily, those boring mechanical refactorings usually
> represent the vast majority, and that's the tedious work we want
> tooling to assist us most with.

Yes, getting it 99% there as an automated tool would be enough
for most cases.


> > C) Hackage displays vocally what works with which versions of
> > GHC (Status reports do help somewhat)
> 
> 
> I.e. something like
> 
>   http://matrix.hackage.haskell.org/package/text

Yes! Is there a reason that it is not displayed on
http://hackage.haskell.org/package/text which only
displays a link to Status of a 7.8.3 build?

How many percent of Hackage is built with matrix.h.h.o
and is there a plan to integrate it into Hackage pages?

- Taru Karttunen

From tab at snarc.org  Thu Oct 22 10:57:11 2015
From: tab at snarc.org (Vincent Hanquez)
Date: Thu, 22 Oct 2015 11:57:11 +0100
Subject: Breaking Changes and Long Term Support Haskell
In-Reply-To: <CAHZrzdr0DFFXCcVdOQcudgURNxQ+b7Dt3-NCxqfud1Ugej9DfQ@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk>
 <562765FE.6070808@nottingham.ac.uk>
 <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net>
 <a2781834655f4e358b95c6c5fd53e2ac@DB4PR30MB030.064d.mgd.msft.net>
 <5627A4A8.7070107@apeiron.net>
 <CAHEA9tMB4vgyijZBt-PWEU-SPVvm2ouw1vgntkwss38e5tSh9Q@mail.gmail.com>
 <56280F3A.7070902@apeiron.net>
 <CAHZrzdr0DFFXCcVdOQcudgURNxQ+b7Dt3-NCxqfud1Ugej9DfQ@mail.gmail.com>
Message-ID: <5628C107.5090106@snarc.org>



On 22/10/2015 01:42, Gregory Collins wrote:
>
> All I'm saying is that if we want to appeal to or cater to working 
> software engineers, we have to be a lot less cavalier about causing 
> more work for them, and we need to prize stability of the core 
> infrastructure more highly. That'd be a broader cultural change, and 
> that goes beyond process: it's policy.
Not that I disagree that we need general stability but,

I think it's quite unfair to say that working software engineers are 
being pushed away because of the current "instability", and actually I 
don't see any proof of such a thing.

Working software engineers have developed methods to deal with change 
(or not to deal with it) for decades.
To name a few with Haskell: private hackage, stackage, cabal pinning.
It's also commonly available through stack nowadays.

Also, having worked on multiples different Haskell teams doing 
commercial/professional software, compiler/libraries upgrades were never 
a concern of the team.
It was always something that can be dealt quickly, painlessly and with a 
lot more certitude w.r.t the quality assurance, compared to e.g. dynamic 
languages where you don't have any types safety etc..

I can't help but think that you meant "opensource library maintainers" 
instead of "working software engineers", which is somewhat a very 
different beast.

-- 
Vincent

From alois.cochard at gmail.com  Thu Oct 22 11:23:33 2015
From: alois.cochard at gmail.com (Alois Cochard)
Date: Thu, 22 Oct 2015 13:23:33 +0200
Subject: Breaking Changes and Long Term Support Haskell
In-Reply-To: <5628C107.5090106@snarc.org>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk>
 <562765FE.6070808@nottingham.ac.uk>
 <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net>
 <a2781834655f4e358b95c6c5fd53e2ac@DB4PR30MB030.064d.mgd.msft.net>
 <5627A4A8.7070107@apeiron.net>
 <CAHEA9tMB4vgyijZBt-PWEU-SPVvm2ouw1vgntkwss38e5tSh9Q@mail.gmail.com>
 <56280F3A.7070902@apeiron.net>
 <CAHZrzdr0DFFXCcVdOQcudgURNxQ+b7Dt3-NCxqfud1Ugej9DfQ@mail.gmail.com>
 <5628C107.5090106@snarc.org>
Message-ID: <CAJHA+wqSgBCVjBc4wguH3Lc_2wrepnqs5rNHC5yYukxAWFt0rw@mail.gmail.com>

That is very interesting, I just want to second Vincent because what I have
read here initially was the exact opposite of the impression I had online.

>From my probably biased point of view, the most visible and vocable persons
who are being upset recently about FRP seems to be teachers and academics!
Which is I must admit was extremely surprising to me.
Most haskellers I know working in the industry, or on open source
libraries, seems to be totally fine with the change (and usually they got
aware of it long time ago... when it was discussed).

Like some others have pointed out, it feel to me that it's much more an
issue about communication than anything else.

Cheers

On 22 October 2015 at 12:57, Vincent Hanquez <tab at snarc.org> wrote:

>
>
> On 22/10/2015 01:42, Gregory Collins wrote:
>
>>
>> All I'm saying is that if we want to appeal to or cater to working
>> software engineers, we have to be a lot less cavalier about causing more
>> work for them, and we need to prize stability of the core infrastructure
>> more highly. That'd be a broader cultural change, and that goes beyond
>> process: it's policy.
>>
> Not that I disagree that we need general stability but,
>
> I think it's quite unfair to say that working software engineers are being
> pushed away because of the current "instability", and actually I don't see
> any proof of such a thing.
>
> Working software engineers have developed methods to deal with change (or
> not to deal with it) for decades.
> To name a few with Haskell: private hackage, stackage, cabal pinning.
> It's also commonly available through stack nowadays.
>
> Also, having worked on multiples different Haskell teams doing
> commercial/professional software, compiler/libraries upgrades were never a
> concern of the team.
> It was always something that can be dealt quickly, painlessly and with a
> lot more certitude w.r.t the quality assurance, compared to e.g. dynamic
> languages where you don't have any types safety etc..
>
> I can't help but think that you meant "opensource library maintainers"
> instead of "working software engineers", which is somewhat a very different
> beast.
>
> --
> Vincent
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>



-- 
*?\ois*
http://twitter.com/aloiscochard
http://github.com/aloiscochard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151022/10d757d8/attachment.html>

From mainland at apeiron.net  Thu Oct 22 13:29:54 2015
From: mainland at apeiron.net (Geoffrey Mainland)
Date: Thu, 22 Oct 2015 09:29:54 -0400
Subject: Breaking Changes and Long Term Support Haskell
In-Reply-To: <CAJumaK_7ctgnU1cw0BZM-fourh2yaNuO+K2fc-krNNXss11WDg@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk>
 <562765FE.6070808@nottingham.ac.uk>
 <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net>
 <a2781834655f4e358b95c6c5fd53e2ac@DB4PR30MB030.064d.mgd.msft.net>
 <5627A4A8.7070107@apeiron.net>
 <CAHEA9tMB4vgyijZBt-PWEU-SPVvm2ouw1vgntkwss38e5tSh9Q@mail.gmail.com>
 <56280F3A.7070902@apeiron.net>
 <CAHZrzdr0DFFXCcVdOQcudgURNxQ+b7Dt3-NCxqfud1Ugej9DfQ@mail.gmail.com>
 <CAJumaK_7ctgnU1cw0BZM-fourh2yaNuO+K2fc-krNNXss11WDg@mail.gmail.com>
Message-ID: <5628E4D2.5040904@apeiron.net>

On 10/22/2015 02:40 AM, Edward Kmett wrote:
> On Wed, Oct 21, 2015 at 8:42 PM, Gregory Collins
> <greg at gregorycollins.net <mailto:greg at gregorycollins.net>> wrote:
>
>
>     On Wed, Oct 21, 2015 at 3:18 PM, Geoffrey Mainland
>     <mainland at apeiron.net <mailto:mainland at apeiron.net>> wrote:
>
>         My original email stated my underlying concern: we are losing
>         valuable
>         members of the community not because of the technical
>         decisions that are
>         being made, but because of the process by which they are being
>         made.
>
>     [If] you're doing research you're on the treadmill, almost by
>     definition, and you're delighted that we're finally making some
>     rapid progress on fixing up some of the longstanding warts.
>
>     If you're a practitioner, you are interested in using Haskell for,
>     y'know, writing programs. You're probably in one of two camps:
>     you're in "green field" mode writing a lot of new code (early
>     stage startups, prototype work, etc), or you're
>     maintaining/extending programs you've already written that are out
>     "in the field" for you doing useful work. Laura Wingerd calls this
>     the "annealing temperature" of software, and I think this is a
>     nice metaphor to describe it. How tolerant you are of ecosystem
>     churn depends on what your temperature is: and I think it should
>     be obvious to everyone that Haskell having "success" for
>     programming work would mean that lots of useful and correct
>     programs get written, so everyone who is in the former camp will
>     cool over time to join the latter.
>
>
>     I've made the point before and I don't really want to belabor it:
>     our de facto collective posture towards breaking stuff, especially
>     in the past few years, has been extremely permissive, and this
>     alienates people who are maintaining working programs.
>
>
> Even among people who purported to be teaching Haskell or using
> Haskell today in industry the margin of preference for the concrete
> FTP proposal was ~79%. This was considerably higher than I expected in
> two senses. One: there were a lot more people who claimed to be in one
> of those two roles than I expected by far, and two: their appetite for
> change was higher than I expected. I initially expected to see a
> stronger "academic vs. industry" split in the poll, but the groups
> were only distinguishable by a few percentage point delta, so while I
> expected roughly the end percentage of the poll, based on the year
> prior I'd spent running around the planet to user group meetings and
> the like, I expected it mostly because I expected more hobbyists and
> less support among industrialists.
>
>     I'm actually firmly of the belief that the existing committee
>     doesn't really have process issues, and in fact, that often it's
>     been pretty careful to minimize the impact of the changes it wants
>     to make. As others have pointed out, lots of the churn actually
>     comes from platform libraries, which are out of the purview of
>     this group.
>
>
> Historically we've had a bit of a split personality on this front.
> Nothing that touches the Prelude had changed in 17 years. On the other
> hand the platform libraries had maintained a pretty heavy rolling wave
> of breakage the entire time I've been around in the community. On a
> more experimental feature front, I've lost count of the number of
> different things we've done to Typeable or template-haskell.
>  
>
>     All I'm saying is that if we want to appeal to or cater to working
>     software engineers, we have to be a lot less cavalier about
>     causing more work for them, and we need to prize stability of the
>     core infrastructure more highly. That'd be a broader cultural
>     change, and that goes beyond process: it's policy.
>
>
> The way things are shaping up, we've had 17 years of rock solid
> stability, 1 release that incorporated changes that were designed to
> minimize impact, to the point that the majority of the objections
> against them are of the form where people would prefer that we broke
> _more_ code, to get a more sensible state. Going forward, it looks
> like the next 2 GHC releases will have basically nothing affecting the
> Prelude, and there will be another punctuation in the equilibrium
> around 8.4 as the next set of changes kicks in over 8.4 and 8.6 That
> gives 2 years worth of advance notice of pending changes, and a pretty
> strong guarantee from the committee that you should be able to
> maintain code with a 3 release window without running afoul of
> warnings or needing CPP.
>
> So, out of curiosity, what additional stability policy is it that you
> seek?

Thanks to you and Dan [1], I now have a greater understanding and
appreciation for where the committee has been coming from. My new
understanding is that the changes that were formalized in AMP, FTP, and
MRP were the basis for the committee's creation. It also seems that
there are more changes in the pipeline that have not yet been made into
proposals, e.g., pulling (>>) out of Control.Monad [2]. Part of
"stability" is signaling change as far ahead as possible. The committee
has put a lot of effort into this, which I appreciate! However, as each
of these proposal has come down the pipeline, I never realized that they
were part of a larger master plan.

1) What is the master plan, and where is it documented, even if this
document is not up to the standard of a proposal? What is the final
target, and when might we expect it to be reached? What is in the
pipeline after MRP?

Relatedly, guidance on how to write code now so that it will be
compatible with future changes helps mitigate the stability issue.

2) How can I write code that makes use of the Prelude so that it will
work with every new GHC release over the next 3 years? 5 years? For
example, how can I write a Monad instance now, knowing the changes that
are coming, so that the instance will work with every new GHC release
for the next 3 years? 5 years? If the answer is "you can't," then when
might I be able to do such a thing? As of 8.4? 8.6? I'm embarrassed to
say I don't know the answer!

Finally, if none of these changes broke Prelude backwards compatibility,
far fewer people would be complaining :) Of course, we can't always make
progress without breaking things, but a more deliberative process might
offer an opportunity to make progress while still preserving backwards
compatibility. Take AMP for example. There were at least two [3] [4]
proposals for preserving backwards compatibility. Investigating them
would have taken time and delayed AMP, yes, but why the rush?

3) Can we have a process that allows more deliberation over, and wider
publicity for, changes that break backwards compatibility? The goal of
such a process would not be to prevent change, but to allow more time to
find possible solution to the issue of backwards compatibility.

My proposal for a low-traffic mailing list where all proposals were
announced was meant to provide wider publicity.

Personally, I think these proposals do indeed fix a lot of warts in the
language. As a researcher who uses actively uses Haskell every day,
these warts have had approximately zero impact on me for the past
(almost) decade, and I would be perfectly content if they were never
fixed. The only pain I can recall enduring is having to occasionally
write an orphan Applicative instance. I have been importing Prelude
hiding mapM for years. I have been importing Control.Applicative for
years. Neither has been painful. Dealing with AMP? I'm working on a
collaborative research project that is stuck on 7.8 because of AMP. I
agree, that seems silly, but whether or not it is silly, it is an impact
I feel.

One way to look at these proposals is to ask the question "Wouldn't the
language be nicer if all these changes were made?" Another is to ask the
question "Does the fact that these changes have not been made make your
life as a Haskell programmer more difficult in any significant way?" I
answer "yes" to the former and "no" to the latter. Is our stance that
answering "yes" to the former question is enough to motivate braking
change? Shouldn't a answer "no" to the latter question cause some
hesitation?

Maybe there are a lot of people who answer "yes" to both questions. I
would like to know! But does having return in the Monad class really
cause anyone anything other than existential pain?

Cheers,
Geoff

[1] https://mail.haskell.org/pipermail/libraries/2015-October/026390.html
[2] https://mail.haskell.org/pipermail/libraries/2015-September/026158.html
[3] https://ghc.haskell.org/trac/ghc/wiki/InstanceTemplates
[4] https://ghc.haskell.org/trac/ghc/wiki/IntrinsicSuperclasses


From mhoermann at gmail.com  Thu Oct 22 15:02:50 2015
From: mhoermann at gmail.com (=?UTF-8?Q?Matthias_H=C3=B6rmann?=)
Date: Thu, 22 Oct 2015 17:02:50 +0200
Subject: Breaking Changes and Long Term Support Haskell
In-Reply-To: <5628E4D2.5040904@apeiron.net>
References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk>
 <562765FE.6070808@nottingham.ac.uk>
 <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net>
 <a2781834655f4e358b95c6c5fd53e2ac@DB4PR30MB030.064d.mgd.msft.net>
 <5627A4A8.7070107@apeiron.net>
 <CAHEA9tMB4vgyijZBt-PWEU-SPVvm2ouw1vgntkwss38e5tSh9Q@mail.gmail.com>
 <56280F3A.7070902@apeiron.net>
 <CAHZrzdr0DFFXCcVdOQcudgURNxQ+b7Dt3-NCxqfud1Ugej9DfQ@mail.gmail.com>
 <CAJumaK_7ctgnU1cw0BZM-fourh2yaNuO+K2fc-krNNXss11WDg@mail.gmail.com>
 <5628E4D2.5040904@apeiron.net>
Message-ID: <CABSPmx2fwvZxgeu5b3Rrh8dd3+Lv9Zz8EnrAkoSofZ9_rp5cig@mail.gmail.com>

I would say that the need to import Control.Applicative in virtually
every module manually
definitely caused some pain before AMP. I would also argue that a
non-negligible amount
of effort goes into teaching the warts, the reasons for the warts and
how to work around them.

> Dealing with AMP? I'm working on a collaborative research project that is stuck on 7.8 because of AMP.

I am curious what exactly about AMP causes your research project to be
"stuck" on GHC 7.8
considering we have had multiple people mention how little effort it
took to update even large codebases.
I think it would be useful information to have to plan future changes
in a way that might avoid
your issues.

On Thu, Oct 22, 2015 at 3:29 PM, Geoffrey Mainland <mainland at apeiron.net> wrote:
> On 10/22/2015 02:40 AM, Edward Kmett wrote:
>> On Wed, Oct 21, 2015 at 8:42 PM, Gregory Collins
>> <greg at gregorycollins.net <mailto:greg at gregorycollins.net>> wrote:
>>
>>
>>     On Wed, Oct 21, 2015 at 3:18 PM, Geoffrey Mainland
>>     <mainland at apeiron.net <mailto:mainland at apeiron.net>> wrote:
>>
>>         My original email stated my underlying concern: we are losing
>>         valuable
>>         members of the community not because of the technical
>>         decisions that are
>>         being made, but because of the process by which they are being
>>         made.
>>
>>     [If] you're doing research you're on the treadmill, almost by
>>     definition, and you're delighted that we're finally making some
>>     rapid progress on fixing up some of the longstanding warts.
>>
>>     If you're a practitioner, you are interested in using Haskell for,
>>     y'know, writing programs. You're probably in one of two camps:
>>     you're in "green field" mode writing a lot of new code (early
>>     stage startups, prototype work, etc), or you're
>>     maintaining/extending programs you've already written that are out
>>     "in the field" for you doing useful work. Laura Wingerd calls this
>>     the "annealing temperature" of software, and I think this is a
>>     nice metaphor to describe it. How tolerant you are of ecosystem
>>     churn depends on what your temperature is: and I think it should
>>     be obvious to everyone that Haskell having "success" for
>>     programming work would mean that lots of useful and correct
>>     programs get written, so everyone who is in the former camp will
>>     cool over time to join the latter.
>>
>>
>>     I've made the point before and I don't really want to belabor it:
>>     our de facto collective posture towards breaking stuff, especially
>>     in the past few years, has been extremely permissive, and this
>>     alienates people who are maintaining working programs.
>>
>>
>> Even among people who purported to be teaching Haskell or using
>> Haskell today in industry the margin of preference for the concrete
>> FTP proposal was ~79%. This was considerably higher than I expected in
>> two senses. One: there were a lot more people who claimed to be in one
>> of those two roles than I expected by far, and two: their appetite for
>> change was higher than I expected. I initially expected to see a
>> stronger "academic vs. industry" split in the poll, but the groups
>> were only distinguishable by a few percentage point delta, so while I
>> expected roughly the end percentage of the poll, based on the year
>> prior I'd spent running around the planet to user group meetings and
>> the like, I expected it mostly because I expected more hobbyists and
>> less support among industrialists.
>>
>>     I'm actually firmly of the belief that the existing committee
>>     doesn't really have process issues, and in fact, that often it's
>>     been pretty careful to minimize the impact of the changes it wants
>>     to make. As others have pointed out, lots of the churn actually
>>     comes from platform libraries, which are out of the purview of
>>     this group.
>>
>>
>> Historically we've had a bit of a split personality on this front.
>> Nothing that touches the Prelude had changed in 17 years. On the other
>> hand the platform libraries had maintained a pretty heavy rolling wave
>> of breakage the entire time I've been around in the community. On a
>> more experimental feature front, I've lost count of the number of
>> different things we've done to Typeable or template-haskell.
>>
>>
>>     All I'm saying is that if we want to appeal to or cater to working
>>     software engineers, we have to be a lot less cavalier about
>>     causing more work for them, and we need to prize stability of the
>>     core infrastructure more highly. That'd be a broader cultural
>>     change, and that goes beyond process: it's policy.
>>
>>
>> The way things are shaping up, we've had 17 years of rock solid
>> stability, 1 release that incorporated changes that were designed to
>> minimize impact, to the point that the majority of the objections
>> against them are of the form where people would prefer that we broke
>> _more_ code, to get a more sensible state. Going forward, it looks
>> like the next 2 GHC releases will have basically nothing affecting the
>> Prelude, and there will be another punctuation in the equilibrium
>> around 8.4 as the next set of changes kicks in over 8.4 and 8.6 That
>> gives 2 years worth of advance notice of pending changes, and a pretty
>> strong guarantee from the committee that you should be able to
>> maintain code with a 3 release window without running afoul of
>> warnings or needing CPP.
>>
>> So, out of curiosity, what additional stability policy is it that you
>> seek?
>
> Thanks to you and Dan [1], I now have a greater understanding and
> appreciation for where the committee has been coming from. My new
> understanding is that the changes that were formalized in AMP, FTP, and
> MRP were the basis for the committee's creation. It also seems that
> there are more changes in the pipeline that have not yet been made into
> proposals, e.g., pulling (>>) out of Control.Monad [2]. Part of
> "stability" is signaling change as far ahead as possible. The committee
> has put a lot of effort into this, which I appreciate! However, as each
> of these proposal has come down the pipeline, I never realized that they
> were part of a larger master plan.
>
> 1) What is the master plan, and where is it documented, even if this
> document is not up to the standard of a proposal? What is the final
> target, and when might we expect it to be reached? What is in the
> pipeline after MRP?
>
> Relatedly, guidance on how to write code now so that it will be
> compatible with future changes helps mitigate the stability issue.
>
> 2) How can I write code that makes use of the Prelude so that it will
> work with every new GHC release over the next 3 years? 5 years? For
> example, how can I write a Monad instance now, knowing the changes that
> are coming, so that the instance will work with every new GHC release
> for the next 3 years? 5 years? If the answer is "you can't," then when
> might I be able to do such a thing? As of 8.4? 8.6? I'm embarrassed to
> say I don't know the answer!
>
> Finally, if none of these changes broke Prelude backwards compatibility,
> far fewer people would be complaining :) Of course, we can't always make
> progress without breaking things, but a more deliberative process might
> offer an opportunity to make progress while still preserving backwards
> compatibility. Take AMP for example. There were at least two [3] [4]
> proposals for preserving backwards compatibility. Investigating them
> would have taken time and delayed AMP, yes, but why the rush?
>
> 3) Can we have a process that allows more deliberation over, and wider
> publicity for, changes that break backwards compatibility? The goal of
> such a process would not be to prevent change, but to allow more time to
> find possible solution to the issue of backwards compatibility.
>
> My proposal for a low-traffic mailing list where all proposals were
> announced was meant to provide wider publicity.
>
> Personally, I think these proposals do indeed fix a lot of warts in the
> language. As a researcher who uses actively uses Haskell every day,
> these warts have had approximately zero impact on me for the past
> (almost) decade, and I would be perfectly content if they were never
> fixed. The only pain I can recall enduring is having to occasionally
> write an orphan Applicative instance. I have been importing Prelude
> hiding mapM for years. I have been importing Control.Applicative for
> years. Neither has been painful. Dealing with AMP? I'm working on a
> collaborative research project that is stuck on 7.8 because of AMP. I
> agree, that seems silly, but whether or not it is silly, it is an impact
> I feel.
>
> One way to look at these proposals is to ask the question "Wouldn't the
> language be nicer if all these changes were made?" Another is to ask the
> question "Does the fact that these changes have not been made make your
> life as a Haskell programmer more difficult in any significant way?" I
> answer "yes" to the former and "no" to the latter. Is our stance that
> answering "yes" to the former question is enough to motivate braking
> change? Shouldn't a answer "no" to the latter question cause some
> hesitation?
>
> Maybe there are a lot of people who answer "yes" to both questions. I
> would like to know! But does having return in the Monad class really
> cause anyone anything other than existential pain?
>
> Cheers,
> Geoff
>
> [1] https://mail.haskell.org/pipermail/libraries/2015-October/026390.html
> [2] https://mail.haskell.org/pipermail/libraries/2015-September/026158.html
> [3] https://ghc.haskell.org/trac/ghc/wiki/InstanceTemplates
> [4] https://ghc.haskell.org/trac/ghc/wiki/IntrinsicSuperclasses
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

From mainland at apeiron.net  Thu Oct 22 15:36:31 2015
From: mainland at apeiron.net (Geoffrey Mainland)
Date: Thu, 22 Oct 2015 11:36:31 -0400
Subject: Breaking Changes and Long Term Support Haskell
In-Reply-To: <CABSPmx2fwvZxgeu5b3Rrh8dd3+Lv9Zz8EnrAkoSofZ9_rp5cig@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk>
 <562765FE.6070808@nottingham.ac.uk>
 <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net>
 <a2781834655f4e358b95c6c5fd53e2ac@DB4PR30MB030.064d.mgd.msft.net>
 <5627A4A8.7070107@apeiron.net>
 <CAHEA9tMB4vgyijZBt-PWEU-SPVvm2ouw1vgntkwss38e5tSh9Q@mail.gmail.com>
 <56280F3A.7070902@apeiron.net>
 <CAHZrzdr0DFFXCcVdOQcudgURNxQ+b7Dt3-NCxqfud1Ugej9DfQ@mail.gmail.com>
 <CAJumaK_7ctgnU1cw0BZM-fourh2yaNuO+K2fc-krNNXss11WDg@mail.gmail.com>
 <5628E4D2.5040904@apeiron.net>
 <CABSPmx2fwvZxgeu5b3Rrh8dd3+Lv9Zz8EnrAkoSofZ9_rp5cig@mail.gmail.com>
Message-ID: <5629027F.2070607@apeiron.net>

On 10/22/2015 11:02 AM, Matthias H?rmann wrote:
> I would say that the need to import Control.Applicative in virtually
> every module manually
> definitely caused some pain before AMP.

In this particular case, there is a trade off between breaking code on
the one hand and having to write some import statements on the other. I
find writing some extra imports less painful than breaking (other
people's and my) code, but the other position is defensible as well. I
sense that I am in the minority, at least on the libraries list.

> I would also argue that a
> non-negligible amount
> of effort goes into teaching the warts, the reasons for the warts and
> how to work around them.

Which wart(s) in particular? All of them? Does having return (and (>>))
in Monad make teaching more difficult?

I teach Haskell beginners, and I found that AMP made explaining monads
slightly more difficult because it served as a source of confusion for
my students.

On the other hand, the warts provide a teachable moment once students
understand all this stuff :)

>> Dealing with AMP? I'm working on a collaborative research project that is stuck on 7.8 because of AMP.
> I am curious what exactly about AMP causes your research project to be
> "stuck" on GHC 7.8
> considering we have had multiple people mention how little effort it
> took to update even large codebases.
> I think it would be useful information to have to plan future changes
> in a way that might avoid
> your issues.

I was hoping that mentioning this wouldn't distract from the three main
(numbered) questions I posed below. Alas.

If I were working alone, AMP wouldn't be a huge deal. I could fix the
code for 7.10 compatibility, but then unless everyone switches to 7.10,
changes to the codebase made by someone using 7.8, e.g., defining a new
Monad instance, could break things on 7.10 again. It's easier to stick
with 7.8. Any time spent dealing with compatibility issues is time not
spent writing actual code.

I outlined one possible path to avoid this kind of issue: spend more
time thinking about ways to maintain compatibility. We had proposals for
doing this with AMP.

Cheers,
Geoff

>
> On Thu, Oct 22, 2015 at 3:29 PM, Geoffrey Mainland <mainland at apeiron.net> wrote:
>> On 10/22/2015 02:40 AM, Edward Kmett wrote:
>>> On Wed, Oct 21, 2015 at 8:42 PM, Gregory Collins
>>> <greg at gregorycollins.net <mailto:greg at gregorycollins.net>> wrote:
>>>
>>>
>>>     On Wed, Oct 21, 2015 at 3:18 PM, Geoffrey Mainland
>>>     <mainland at apeiron.net <mailto:mainland at apeiron.net>> wrote:
>>>
>>>         My original email stated my underlying concern: we are losing
>>>         valuable
>>>         members of the community not because of the technical
>>>         decisions that are
>>>         being made, but because of the process by which they are being
>>>         made.
>>>
>>>     [If] you're doing research you're on the treadmill, almost by
>>>     definition, and you're delighted that we're finally making some
>>>     rapid progress on fixing up some of the longstanding warts.
>>>
>>>     If you're a practitioner, you are interested in using Haskell for,
>>>     y'know, writing programs. You're probably in one of two camps:
>>>     you're in "green field" mode writing a lot of new code (early
>>>     stage startups, prototype work, etc), or you're
>>>     maintaining/extending programs you've already written that are out
>>>     "in the field" for you doing useful work. Laura Wingerd calls this
>>>     the "annealing temperature" of software, and I think this is a
>>>     nice metaphor to describe it. How tolerant you are of ecosystem
>>>     churn depends on what your temperature is: and I think it should
>>>     be obvious to everyone that Haskell having "success" for
>>>     programming work would mean that lots of useful and correct
>>>     programs get written, so everyone who is in the former camp will
>>>     cool over time to join the latter.
>>>
>>>
>>>     I've made the point before and I don't really want to belabor it:
>>>     our de facto collective posture towards breaking stuff, especially
>>>     in the past few years, has been extremely permissive, and this
>>>     alienates people who are maintaining working programs.
>>>
>>>
>>> Even among people who purported to be teaching Haskell or using
>>> Haskell today in industry the margin of preference for the concrete
>>> FTP proposal was ~79%. This was considerably higher than I expected in
>>> two senses. One: there were a lot more people who claimed to be in one
>>> of those two roles than I expected by far, and two: their appetite for
>>> change was higher than I expected. I initially expected to see a
>>> stronger "academic vs. industry" split in the poll, but the groups
>>> were only distinguishable by a few percentage point delta, so while I
>>> expected roughly the end percentage of the poll, based on the year
>>> prior I'd spent running around the planet to user group meetings and
>>> the like, I expected it mostly because I expected more hobbyists and
>>> less support among industrialists.
>>>
>>>     I'm actually firmly of the belief that the existing committee
>>>     doesn't really have process issues, and in fact, that often it's
>>>     been pretty careful to minimize the impact of the changes it wants
>>>     to make. As others have pointed out, lots of the churn actually
>>>     comes from platform libraries, which are out of the purview of
>>>     this group.
>>>
>>>
>>> Historically we've had a bit of a split personality on this front.
>>> Nothing that touches the Prelude had changed in 17 years. On the other
>>> hand the platform libraries had maintained a pretty heavy rolling wave
>>> of breakage the entire time I've been around in the community. On a
>>> more experimental feature front, I've lost count of the number of
>>> different things we've done to Typeable or template-haskell.
>>>
>>>
>>>     All I'm saying is that if we want to appeal to or cater to working
>>>     software engineers, we have to be a lot less cavalier about
>>>     causing more work for them, and we need to prize stability of the
>>>     core infrastructure more highly. That'd be a broader cultural
>>>     change, and that goes beyond process: it's policy.
>>>
>>>
>>> The way things are shaping up, we've had 17 years of rock solid
>>> stability, 1 release that incorporated changes that were designed to
>>> minimize impact, to the point that the majority of the objections
>>> against them are of the form where people would prefer that we broke
>>> _more_ code, to get a more sensible state. Going forward, it looks
>>> like the next 2 GHC releases will have basically nothing affecting the
>>> Prelude, and there will be another punctuation in the equilibrium
>>> around 8.4 as the next set of changes kicks in over 8.4 and 8.6 That
>>> gives 2 years worth of advance notice of pending changes, and a pretty
>>> strong guarantee from the committee that you should be able to
>>> maintain code with a 3 release window without running afoul of
>>> warnings or needing CPP.
>>>
>>> So, out of curiosity, what additional stability policy is it that you
>>> seek?
>> Thanks to you and Dan [1], I now have a greater understanding and
>> appreciation for where the committee has been coming from. My new
>> understanding is that the changes that were formalized in AMP, FTP, and
>> MRP were the basis for the committee's creation. It also seems that
>> there are more changes in the pipeline that have not yet been made into
>> proposals, e.g., pulling (>>) out of Control.Monad [2]. Part of
>> "stability" is signaling change as far ahead as possible. The committee
>> has put a lot of effort into this, which I appreciate! However, as each
>> of these proposal has come down the pipeline, I never realized that they
>> were part of a larger master plan.
>>
>> 1) What is the master plan, and where is it documented, even if this
>> document is not up to the standard of a proposal? What is the final
>> target, and when might we expect it to be reached? What is in the
>> pipeline after MRP?
>>
>> Relatedly, guidance on how to write code now so that it will be
>> compatible with future changes helps mitigate the stability issue.
>>
>> 2) How can I write code that makes use of the Prelude so that it will
>> work with every new GHC release over the next 3 years? 5 years? For
>> example, how can I write a Monad instance now, knowing the changes that
>> are coming, so that the instance will work with every new GHC release
>> for the next 3 years? 5 years? If the answer is "you can't," then when
>> might I be able to do such a thing? As of 8.4? 8.6? I'm embarrassed to
>> say I don't know the answer!
>>
>> Finally, if none of these changes broke Prelude backwards compatibility,
>> far fewer people would be complaining :) Of course, we can't always make
>> progress without breaking things, but a more deliberative process might
>> offer an opportunity to make progress while still preserving backwards
>> compatibility. Take AMP for example. There were at least two [3] [4]
>> proposals for preserving backwards compatibility. Investigating them
>> would have taken time and delayed AMP, yes, but why the rush?
>>
>> 3) Can we have a process that allows more deliberation over, and wider
>> publicity for, changes that break backwards compatibility? The goal of
>> such a process would not be to prevent change, but to allow more time to
>> find possible solution to the issue of backwards compatibility.
>>
>> My proposal for a low-traffic mailing list where all proposals were
>> announced was meant to provide wider publicity.
>>
>> Personally, I think these proposals do indeed fix a lot of warts in the
>> language. As a researcher who uses actively uses Haskell every day,
>> these warts have had approximately zero impact on me for the past
>> (almost) decade, and I would be perfectly content if they were never
>> fixed. The only pain I can recall enduring is having to occasionally
>> write an orphan Applicative instance. I have been importing Prelude
>> hiding mapM for years. I have been importing Control.Applicative for
>> years. Neither has been painful. Dealing with AMP? I'm working on a
>> collaborative research project that is stuck on 7.8 because of AMP. I
>> agree, that seems silly, but whether or not it is silly, it is an impact
>> I feel.
>>
>> One way to look at these proposals is to ask the question "Wouldn't the
>> language be nicer if all these changes were made?" Another is to ask the
>> question "Does the fact that these changes have not been made make your
>> life as a Haskell programmer more difficult in any significant way?" I
>> answer "yes" to the former and "no" to the latter. Is our stance that
>> answering "yes" to the former question is enough to motivate braking
>> change? Shouldn't a answer "no" to the latter question cause some
>> hesitation?
>>
>> Maybe there are a lot of people who answer "yes" to both questions. I
>> would like to know! But does having return in the Monad class really
>> cause anyone anything other than existential pain?
>>
>> Cheers,
>> Geoff
>>
>> [1] https://mail.haskell.org/pipermail/libraries/2015-October/026390.html
>> [2] https://mail.haskell.org/pipermail/libraries/2015-September/026158.html
>> [3] https://ghc.haskell.org/trac/ghc/wiki/InstanceTemplates
>> [4] https://ghc.haskell.org/trac/ghc/wiki/IntrinsicSuperclasses


From davidleothomas at gmail.com  Thu Oct 22 15:48:35 2015
From: davidleothomas at gmail.com (David Thomas)
Date: Thu, 22 Oct 2015 08:48:35 -0700
Subject: 3 release policy
In-Reply-To: <CAL3m8eCjXKq4W9z0YicO5KsO9=GG=bP1pPh5a2_swZLrDbeL7w@mail.gmail.com>
References: <1445370906741-5820363.post@n5.nabble.com>
 <C8A34CAA-7C55-4657-8286-16C46B3A6E27@cis.upenn.edu>
 <CAAOoiFZT6rpLYEhfEzGX3=VTyrn4XfnvqN7GZEq1SdMT7N6Rzg@mail.gmail.com>
 <CACbaDy6UK235OnhpyV1=96cof5j6V2+tKEbv__DmsKsTpAD=bw@mail.gmail.com>
 <cf09d114b9c64dab9ad73741d53941aa@DB4PR30MB030.064d.mgd.msft.net>
 <m2zizbvqru.fsf@newartisans.com>
 <CAL3m8eCjXKq4W9z0YicO5KsO9=GG=bP1pPh5a2_swZLrDbeL7w@mail.gmail.com>
Message-ID: <CAJUDvcgA-ZwADLFcFsgiX9X-X48ph38XXFR-43c1nB1PiKBfJQ@mail.gmail.com>

I hope we *will* have an option to warn about that.  But not by
default, I agree!

On Wed, Oct 21, 2015 at 10:40 PM, M Farkas-Dyck <strake888 at gmail.com> wrote:
> On 21/10/2015, John Wiegley <johnw at newartisans.com> wrote:
>> Since warnings are intended to mean "This could be a problem, but might not
>> be, be warned", there should be a case-by-case way of answering it and
>> saying
>> "I know this isn't a problem". I think a pragma for disabling a particular
>> warning at certain code location would be a good addition to our current
>> disabling mechanisms?
>
> I hope we won't warn about unused warning suppression...
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

From mblazevic at stilo.com  Thu Oct 22 16:22:23 2015
From: mblazevic at stilo.com (=?UTF-8?Q?Mario_Bla=c5=beevi=c4=87?=)
Date: Thu, 22 Oct 2015 12:22:23 -0400
Subject: Breaking Changes and Long Term Support Haskell
In-Reply-To: <5628E4D2.5040904@apeiron.net>
References: <87io6zmr2x.fsf@gnu.org> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk>
 <562765FE.6070808@nottingham.ac.uk>
 <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net>
 <a2781834655f4e358b95c6c5fd53e2ac@DB4PR30MB030.064d.mgd.msft.net>
 <5627A4A8.7070107@apeiron.net>
 <CAHEA9tMB4vgyijZBt-PWEU-SPVvm2ouw1vgntkwss38e5tSh9Q@mail.gmail.com>
 <56280F3A.7070902@apeiron.net>
 <CAHZrzdr0DFFXCcVdOQcudgURNxQ+b7Dt3-NCxqfud1Ugej9DfQ@mail.gmail.com>
 <CAJumaK_7ctgnU1cw0BZM-fourh2yaNuO+K2fc-krNNXss11WDg@mail.gmail.com>
 <5628E4D2.5040904@apeiron.net>
Message-ID: <56290D3F.1070702@stilo.com>

On 15-10-22 09:29 AM, Geoffrey Mainland wrote:
> ...
>
> 1) What is the master plan, and where is it documented, even if this
> document is not up to the standard of a proposal? What is the final
> target, and when might we expect it to be reached? What is in the
> pipeline after MRP?
>
> Relatedly, guidance on how to write code now so that it will be
> compatible with future changes helps mitigate the stability issue.

	I have been fully in favour of all the proposals implemented so far, 
and I think that having an explicit master plan would be a great idea. 
It would address some of the process-related objections that have been 
raised, and it would provide a fixed long-term target that would be much 
easier to make the whole community aware of and contribute to.

	For that purpose, the master plan should be advertised directly on the 
front page of haskell.org. Once we have it settled and agreed, the 
purpose of the base-library commitee would essentially become to figure 
out the details like the timeline and code migration path. One thing 
they wouldn't need to worry about is whether anybody disagrees with 
their goals.


> 2) How can I write code that makes use of the Prelude so that it will
> work with every new GHC release over the next 3 years? 5 years? For
> example, how can I write a Monad instance now, knowing the changes that
> are coming, so that the instance will work with every new GHC release
> for the next 3 years? 5 years? If the answer is "you can't," then when
> might I be able to do such a thing? As of 8.4? 8.6? I'm embarrassed to
> say I don't know the answer!

	From the discussions so far it appears that the answer for 3 years (or 
at least the next 3 GHC releases) would be to write the code that works 
with the current GHC and base, but this policy has not been codified 
anywhere yet. Knowing the upcoming changes doesn't help with making your 
code any more robust, and I think that's a shame. We could have a 
two-pronged policy:

- code that works and compiles with the latest GHC with no *warnings* 
will continue to work and compile with no *errors* with the following 2 
releases, and
- code that also follows the forward-compatibility recommendations 
current for that version of GHC will continue to work and compile with 
no *errors* with the following 4 releases.

	The forward-compatibility recommendations would become a part of the 
online GHC documentation so nobody complains they didn't know about 
them. Personally, I'd prefer if the recommendations were built into the 
compiler itself as a new class of warnings, but then (a) some people 
would insist on turning them on together with -Werror and then complain 
when their builds break and (b) this would increase the pressure on GHC 
implementors.


> Finally, if none of these changes broke Prelude backwards compatibility,
> far fewer people would be complaining :) Of course, we can't always make
> progress without breaking things, but a more deliberative process might
> offer an opportunity to make progress while still preserving backwards
> compatibility. Take AMP for example. There were at least two [3] [4]
> proposals for preserving backwards compatibility. Investigating them
> would have taken time and delayed AMP, yes, but why the rush?

	Because they have been investigated for years with no effect.


> 3) Can we have a process that allows more deliberation over, and wider
> publicity for, changes that break backwards compatibility? The goal of
> such a process would not be to prevent change, but to allow more time to
> find possible solution to the issue of backwards compatibility.

	I doubt we can, but this question has already been answered by others.


From ekmett at gmail.com  Thu Oct 22 16:32:08 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Thu, 22 Oct 2015 12:32:08 -0400
Subject: Breaking Changes and Long Term Support Haskell
In-Reply-To: <5628E4D2.5040904@apeiron.net>
References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com>
 <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk>
 <562765FE.6070808@nottingham.ac.uk>
 <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net>
 <a2781834655f4e358b95c6c5fd53e2ac@DB4PR30MB030.064d.mgd.msft.net>
 <5627A4A8.7070107@apeiron.net>
 <CAHEA9tMB4vgyijZBt-PWEU-SPVvm2ouw1vgntkwss38e5tSh9Q@mail.gmail.com>
 <56280F3A.7070902@apeiron.net>
 <CAHZrzdr0DFFXCcVdOQcudgURNxQ+b7Dt3-NCxqfud1Ugej9DfQ@mail.gmail.com>
 <CAJumaK_7ctgnU1cw0BZM-fourh2yaNuO+K2fc-krNNXss11WDg@mail.gmail.com>
 <5628E4D2.5040904@apeiron.net>
Message-ID: <CAJumaK9c5seF3Z11jqT=Kx2kG+RoMCmokcWwiz1T0Lz_Ucspbw@mail.gmail.com>

On Thu, Oct 22, 2015 at 9:29 AM, Geoffrey Mainland <mainland at apeiron.net>
wrote:

> Thanks to you and Dan [1], I now have a greater understanding and
> appreciation for where the committee has been coming from. My new
> understanding is that the changes that were formalized in AMP, FTP, and
> MRP were the basis for the committee's creation. It also seems that
> there are more changes in the pipeline that have not yet been made into
> proposals, e.g., pulling (>>) out of Control.Monad [2]. Part of
> "stability" is signaling change as far ahead as possible. The committee
> has put a lot of effort into this, which I appreciate! However, as each
> of these proposal has come down the pipeline, I never realized that they
> were part of a larger master plan.
>

The "master plan" where (>>) is concerned is that it'd be nice to get
Traversable down to a minimal state and to eliminate unnecessary
distinctions in the Prelude between things like mapM and traverse. Right
now they have different type constraints, but this is entirely a historical
artifact. But it causes problems, we have a situation where folks have
commonly optimized (>>) but left (*>) unfixed. This yields different
performance for mapM_ and traverse_. A consequence of the AMP is that the
neither one of those could be defined in terms of the other (*>) has a
default definition in terms of (<*>). (>>) has a default definition in
terms of (>>=). With two places where optimizations can happen and two
different definitions for operations that are logically required to be the
same thing we can and do see rather radically different performance between
these two things.

This proposal is something that was put out as a sort of addendum to the
Monad of No Return proposal for discussion, but unlike MRP has no
particular impact on a sacred cow like return. We have yet to put together
a timeline that incorporates the (>>) changes from MRP.

1) What is the master plan, and where is it documented, even if this
> document is not up to the standard of a proposal? What is the final
> target, and when might we expect it to be reached? What is in the
> pipeline after MRP?
>
> Relatedly, guidance on how to write code now so that it will be
> compatible with future changes helps mitigate the stability issue.
>

The current plans more or less stop with finishing the MonadFail proposal,
getting Semigroup in as a superclass of Monoid, and incorporating some
additional members into Floating. The working document for the timeline
going forward is available here:

https://ghc.haskell.org/trac/ghc/wiki/Status/BaseLibrary

>
> 2) How can I write code that makes use of the Prelude so that it will
> work with every new GHC release over the next 3 years? 5 years? For
> example, how can I write a Monad instance now, knowing the changes that
> are coming, so that the instance will work with every new GHC release
> for the next 3 years? 5 years? If the answer is "you can't," then when
> might I be able to do such a thing? As of 8.4? 8.6? I'm embarrassed to
> say I don't know the answer!
>

We have a backwards facing "3 release policy" that says it should always be
possible to write code that works backwards for 3 releases. This means that
changes like moving fail out of Monad will take 5 years. However,
maintaining both that and a _forward facing_ 3 release policy would mean
that any change that introduced a superclass would take something like 9
years of intermediate states that make no sense to complete. *9 years to
move one method.*

Now looking forward. You can write code today with 7.10 that will work
without warnings until 8.2. That happens to be 3 releases. In 8.4 you'll
start to get warnings about Semigroup and MonadFail changes, but looking at
it as 3 releases going forward in 8.0 you can just write the instances and
your code would be warning free forward for 3 releases. In 8.6 those
changes go into effect, but you will have been able to make the code
changes that you need to accomodate 8.6 since 8.0.

The current roadmap happens to give you a 3 year sliding window.

Finally, if none of these changes broke Prelude backwards compatibility,
> far fewer people would be complaining :)


If none of our changes were ever able to break Prelude backwards
compatibility the same people who have been complaining about the utter
lack of progress for the previous 17 years and that nearly exploded the
community 2 years ago would be complaining, and based on polling and
discusssions that is actually a much larger group. The AMP passed nearly
unanimously.


> Of course, we can't always make
> progress without breaking things, but a more deliberative process might
> offer an opportunity to make progress while still preserving backwards
> compatibility. Take AMP for example. There were at least two [3] [4]
> proposals for preserving backwards compatibility. Investigating them
> would have taken time and delayed AMP, yes, but why the rush?
>

We've been talking about various superclass defaulting proposals for the
better part of a decade and no progress has been made. The rush was that
we'd been letting them block every previous discussion, and that the
concrete plan with an actual implementation that was on hand was a very
popular proposal even without that mitigation strategy.

3) Can we have a process that allows more deliberation over, and wider
> publicity for, changes that break backwards compatibility? The goal of
> such a process would not be to prevent change, but to allow more time to
> find possible solution to the issue of backwards compatibility.
>
> My proposal for a low-traffic mailing list where all proposals were
> announced was meant to provide wider publicity.
>

I don't think anybody has an objection to wider visibility of proposals
that affect things mentioned in the Haskell Report.


> Personally, I think these proposals do indeed fix a lot of warts in the
> language. As a researcher who uses actively uses Haskell every day,
> these warts have had approximately zero impact on me for the past
> (almost) decade, and I would be perfectly content if they were never
> fixed. The only pain I can recall enduring is having to occasionally
> write an orphan Applicative instance. I have been importing Prelude
> hiding mapM for years. I have been importing Control.Applicative for
> years. Neither has been painful.


And yet the vast preponderance of public opinion lies in the other camp.
The "change nothing" policy had an iron grip on the state of affairs for 17
years and there were serious cracks starting to form from the appearance
that nothing could ever be fixed if the Prelude was affected in any way.

The only thing that broke with that was when Ian Lynagh unilaterally
removed Eq and Show as superclasses of Num. That was more or less the first
glimmer that the world wouldn't end if deliberated changes were made to the
Prelude.

Dealing with AMP? I'm working on a
> collaborative research project that is stuck on 7.8 because of AMP. I
> agree, that seems silly, but whether or not it is silly, it is an impact
> I feel.
>

What changes did you face beyond writing

instance Functor Foo where
  fmap = liftM

instance Applicative Foo where
  pure = return
  (<*>) = ap

that is AMP related?

Maybe there are a lot of people who answer "yes" to both questions. I
> would like to know! But does having return in the Monad class really
> cause anyone anything other than existential pain?
>

The MRP is by far the most marginal proposal on the table. This is why it
remains *just a proposal* and not part of the roadmap. That said, moving
return to a top level definition will mean that more code that is compiled
will be able to infer an Applicative constraint.

The other proposals that are on the roadmap on the other hand defend a lot
better.

The (>>) fragment of MRP fixes rampant performance regressions, however. We
went to generalize the implementation of mapM_ to use (*>) internally and
found performance regressions within base itself due to instances that are
optimized inconsistently. This informed the design here. More code will
infer with weaker Applicative constraints, Traversable can eventually be
simplified, and folks like Simon Marlow who have folks internally at
Facebook use mapM will just have their code "work" in Haxl. I can answer
"yes" to both of your questions here.

The continued existence of fail in Monad on the other hand has caused a
great deal of pain in instances for things like `Either a` for years. To
supply `fail`, we used to incur a needless Error a constraint. We can be
more precise and remove a potential source of partiality from a lot of
code. I can answer "yes" to both of your questions here.

The lack of Semigroup as a superclass of Monoid has meant that the Monoid
instance for Maybe adds a unit to something that already has a unit. It
means that First and Last, etc. all useless tack an extra case that
everyone has to handle in. It has dozens of knock-on consequences. Much
code that currently only needs a semigroup falls back on a monoid because
of the lack of a proper class relationship or gets duplicated. I can answer
"yes" to both of your questions here.

The numerics changes to Floating mean that Haskell numerics just have awful
precision. Adding expm1, etc. to Floating means that people will be able to
write decent numerical code without having to choose between generality
(using exp from Floating that works everywhere) and accuracy. I can answer
"yes" to both of your questions here.

-Edward
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151022/d65704d8/attachment-0001.html>

From ekmett at gmail.com  Thu Oct 22 16:38:10 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Thu, 22 Oct 2015 12:38:10 -0400
Subject: Breaking Changes and Long Term Support Haskell
In-Reply-To: <5629027F.2070607@apeiron.net>
References: <87io6zmr2x.fsf@gnu.org>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk>
 <562765FE.6070808@nottingham.ac.uk>
 <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net>
 <a2781834655f4e358b95c6c5fd53e2ac@DB4PR30MB030.064d.mgd.msft.net>
 <5627A4A8.7070107@apeiron.net>
 <CAHEA9tMB4vgyijZBt-PWEU-SPVvm2ouw1vgntkwss38e5tSh9Q@mail.gmail.com>
 <56280F3A.7070902@apeiron.net>
 <CAHZrzdr0DFFXCcVdOQcudgURNxQ+b7Dt3-NCxqfud1Ugej9DfQ@mail.gmail.com>
 <CAJumaK_7ctgnU1cw0BZM-fourh2yaNuO+K2fc-krNNXss11WDg@mail.gmail.com>
 <5628E4D2.5040904@apeiron.net>
 <CABSPmx2fwvZxgeu5b3Rrh8dd3+Lv9Zz8EnrAkoSofZ9_rp5cig@mail.gmail.com>
 <5629027F.2070607@apeiron.net>
Message-ID: <CAJumaK_8J9MY-0REkAyB65SH8PxeuD7jvo4=AmxSbTysSpcNcw@mail.gmail.com>

On Thu, Oct 22, 2015 at 11:36 AM, Geoffrey Mainland <mainland at apeiron.net>
wrote:

> On 10/22/2015 11:02 AM, Matthias H?rmann wrote:
> > I would say that the need to import Control.Applicative in virtually
> > every module manually
> > definitely caused some pain before AMP.
>
> In this particular case, there is a trade off between breaking code on
> the one hand and having to write some import statements on the other. I
> find writing some extra imports less painful than breaking (other
> people's and my) code, but the other position is defensible as well. I
> sense that I am in the minority, at least on the libraries list.
>
> > I would also argue that a
> > non-negligible amount
> > of effort goes into teaching the warts, the reasons for the warts and
> > how to work around them.
>
> Which wart(s) in particular? All of them? Does having return (and (>>))
> in Monad make teaching more difficult?
>

Having (>>) means that we have hundreds of monads out there where (>>) has
been optimized, but (*>) has not.

If I were working alone, AMP wouldn't be a huge deal. I could fix the
> code for 7.10 compatibility, but then unless everyone switches to 7.10,
> changes to the codebase made by someone using 7.8, e.g., defining a new
> Monad instance, could break things on 7.10 again. It's easier to stick
> with 7.8. Any time spent dealing with compatibility issues is time not
> spent writing actual code.
>

In the open source world many of us just fire off our code to travis-ci and
get it to build with a dozen different compiler versions. I maintain a lot
of code that supports things back to 7.0 and forward to HEAD this way.


> I outlined one possible path to avoid this kind of issue: spend more
> time thinking about ways to maintain compatibility. We had proposals for
> doing this with AMP.
>

And on the other hand we also had a concrete proposal that didn't require
language changes that was ridiculously popular. People had been talking
about Applicative as a superclass of Monad for a decade before we finally
acted upon the AMP. People had been talking about superclass defaulting for
a decade. When do you cut off discussion and ship the proposal that has
overwhelming support? If there is no process that enables this you can
stall the process indefinitely by raising objections of this form. Such a
situation is not without costs all its own.

-Edward


> Cheers,
> Geoff
>
> >
> > On Thu, Oct 22, 2015 at 3:29 PM, Geoffrey Mainland <mainland at apeiron.net>
> wrote:
> >> On 10/22/2015 02:40 AM, Edward Kmett wrote:
> >>> On Wed, Oct 21, 2015 at 8:42 PM, Gregory Collins
> >>> <greg at gregorycollins.net <mailto:greg at gregorycollins.net>> wrote:
> >>>
> >>>
> >>>     On Wed, Oct 21, 2015 at 3:18 PM, Geoffrey Mainland
> >>>     <mainland at apeiron.net <mailto:mainland at apeiron.net>> wrote:
> >>>
> >>>         My original email stated my underlying concern: we are losing
> >>>         valuable
> >>>         members of the community not because of the technical
> >>>         decisions that are
> >>>         being made, but because of the process by which they are being
> >>>         made.
> >>>
> >>>     [If] you're doing research you're on the treadmill, almost by
> >>>     definition, and you're delighted that we're finally making some
> >>>     rapid progress on fixing up some of the longstanding warts.
> >>>
> >>>     If you're a practitioner, you are interested in using Haskell for,
> >>>     y'know, writing programs. You're probably in one of two camps:
> >>>     you're in "green field" mode writing a lot of new code (early
> >>>     stage startups, prototype work, etc), or you're
> >>>     maintaining/extending programs you've already written that are out
> >>>     "in the field" for you doing useful work. Laura Wingerd calls this
> >>>     the "annealing temperature" of software, and I think this is a
> >>>     nice metaphor to describe it. How tolerant you are of ecosystem
> >>>     churn depends on what your temperature is: and I think it should
> >>>     be obvious to everyone that Haskell having "success" for
> >>>     programming work would mean that lots of useful and correct
> >>>     programs get written, so everyone who is in the former camp will
> >>>     cool over time to join the latter.
> >>>
> >>>
> >>>     I've made the point before and I don't really want to belabor it:
> >>>     our de facto collective posture towards breaking stuff, especially
> >>>     in the past few years, has been extremely permissive, and this
> >>>     alienates people who are maintaining working programs.
> >>>
> >>>
> >>> Even among people who purported to be teaching Haskell or using
> >>> Haskell today in industry the margin of preference for the concrete
> >>> FTP proposal was ~79%. This was considerably higher than I expected in
> >>> two senses. One: there were a lot more people who claimed to be in one
> >>> of those two roles than I expected by far, and two: their appetite for
> >>> change was higher than I expected. I initially expected to see a
> >>> stronger "academic vs. industry" split in the poll, but the groups
> >>> were only distinguishable by a few percentage point delta, so while I
> >>> expected roughly the end percentage of the poll, based on the year
> >>> prior I'd spent running around the planet to user group meetings and
> >>> the like, I expected it mostly because I expected more hobbyists and
> >>> less support among industrialists.
> >>>
> >>>     I'm actually firmly of the belief that the existing committee
> >>>     doesn't really have process issues, and in fact, that often it's
> >>>     been pretty careful to minimize the impact of the changes it wants
> >>>     to make. As others have pointed out, lots of the churn actually
> >>>     comes from platform libraries, which are out of the purview of
> >>>     this group.
> >>>
> >>>
> >>> Historically we've had a bit of a split personality on this front.
> >>> Nothing that touches the Prelude had changed in 17 years. On the other
> >>> hand the platform libraries had maintained a pretty heavy rolling wave
> >>> of breakage the entire time I've been around in the community. On a
> >>> more experimental feature front, I've lost count of the number of
> >>> different things we've done to Typeable or template-haskell.
> >>>
> >>>
> >>>     All I'm saying is that if we want to appeal to or cater to working
> >>>     software engineers, we have to be a lot less cavalier about
> >>>     causing more work for them, and we need to prize stability of the
> >>>     core infrastructure more highly. That'd be a broader cultural
> >>>     change, and that goes beyond process: it's policy.
> >>>
> >>>
> >>> The way things are shaping up, we've had 17 years of rock solid
> >>> stability, 1 release that incorporated changes that were designed to
> >>> minimize impact, to the point that the majority of the objections
> >>> against them are of the form where people would prefer that we broke
> >>> _more_ code, to get a more sensible state. Going forward, it looks
> >>> like the next 2 GHC releases will have basically nothing affecting the
> >>> Prelude, and there will be another punctuation in the equilibrium
> >>> around 8.4 as the next set of changes kicks in over 8.4 and 8.6 That
> >>> gives 2 years worth of advance notice of pending changes, and a pretty
> >>> strong guarantee from the committee that you should be able to
> >>> maintain code with a 3 release window without running afoul of
> >>> warnings or needing CPP.
> >>>
> >>> So, out of curiosity, what additional stability policy is it that you
> >>> seek?
> >> Thanks to you and Dan [1], I now have a greater understanding and
> >> appreciation for where the committee has been coming from. My new
> >> understanding is that the changes that were formalized in AMP, FTP, and
> >> MRP were the basis for the committee's creation. It also seems that
> >> there are more changes in the pipeline that have not yet been made into
> >> proposals, e.g., pulling (>>) out of Control.Monad [2]. Part of
> >> "stability" is signaling change as far ahead as possible. The committee
> >> has put a lot of effort into this, which I appreciate! However, as each
> >> of these proposal has come down the pipeline, I never realized that they
> >> were part of a larger master plan.
> >>
> >> 1) What is the master plan, and where is it documented, even if this
> >> document is not up to the standard of a proposal? What is the final
> >> target, and when might we expect it to be reached? What is in the
> >> pipeline after MRP?
> >>
> >> Relatedly, guidance on how to write code now so that it will be
> >> compatible with future changes helps mitigate the stability issue.
> >>
> >> 2) How can I write code that makes use of the Prelude so that it will
> >> work with every new GHC release over the next 3 years? 5 years? For
> >> example, how can I write a Monad instance now, knowing the changes that
> >> are coming, so that the instance will work with every new GHC release
> >> for the next 3 years? 5 years? If the answer is "you can't," then when
> >> might I be able to do such a thing? As of 8.4? 8.6? I'm embarrassed to
> >> say I don't know the answer!
> >>
> >> Finally, if none of these changes broke Prelude backwards compatibility,
> >> far fewer people would be complaining :) Of course, we can't always make
> >> progress without breaking things, but a more deliberative process might
> >> offer an opportunity to make progress while still preserving backwards
> >> compatibility. Take AMP for example. There were at least two [3] [4]
> >> proposals for preserving backwards compatibility. Investigating them
> >> would have taken time and delayed AMP, yes, but why the rush?
> >>
> >> 3) Can we have a process that allows more deliberation over, and wider
> >> publicity for, changes that break backwards compatibility? The goal of
> >> such a process would not be to prevent change, but to allow more time to
> >> find possible solution to the issue of backwards compatibility.
> >>
> >> My proposal for a low-traffic mailing list where all proposals were
> >> announced was meant to provide wider publicity.
> >>
> >> Personally, I think these proposals do indeed fix a lot of warts in the
> >> language. As a researcher who uses actively uses Haskell every day,
> >> these warts have had approximately zero impact on me for the past
> >> (almost) decade, and I would be perfectly content if they were never
> >> fixed. The only pain I can recall enduring is having to occasionally
> >> write an orphan Applicative instance. I have been importing Prelude
> >> hiding mapM for years. I have been importing Control.Applicative for
> >> years. Neither has been painful. Dealing with AMP? I'm working on a
> >> collaborative research project that is stuck on 7.8 because of AMP. I
> >> agree, that seems silly, but whether or not it is silly, it is an impact
> >> I feel.
> >>
> >> One way to look at these proposals is to ask the question "Wouldn't the
> >> language be nicer if all these changes were made?" Another is to ask the
> >> question "Does the fact that these changes have not been made make your
> >> life as a Haskell programmer more difficult in any significant way?" I
> >> answer "yes" to the former and "no" to the latter. Is our stance that
> >> answering "yes" to the former question is enough to motivate braking
> >> change? Shouldn't a answer "no" to the latter question cause some
> >> hesitation?
> >>
> >> Maybe there are a lot of people who answer "yes" to both questions. I
> >> would like to know! But does having return in the Monad class really
> >> cause anyone anything other than existential pain?
> >>
> >> Cheers,
> >> Geoff
> >>
> >> [1]
> https://mail.haskell.org/pipermail/libraries/2015-October/026390.html
> >> [2]
> https://mail.haskell.org/pipermail/libraries/2015-September/026158.html
> >> [3] https://ghc.haskell.org/trac/ghc/wiki/InstanceTemplates
> >> [4] https://ghc.haskell.org/trac/ghc/wiki/IntrinsicSuperclasses
>
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151022/a4671fa2/attachment-0001.html>

From mainland at apeiron.net  Thu Oct 22 16:59:31 2015
From: mainland at apeiron.net (Geoffrey Mainland)
Date: Thu, 22 Oct 2015 12:59:31 -0400
Subject: Breaking Changes and Long Term Support Haskell
In-Reply-To: <CAJumaK_8J9MY-0REkAyB65SH8PxeuD7jvo4=AmxSbTysSpcNcw@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk>
 <562765FE.6070808@nottingham.ac.uk>
 <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net>
 <a2781834655f4e358b95c6c5fd53e2ac@DB4PR30MB030.064d.mgd.msft.net>
 <5627A4A8.7070107@apeiron.net>
 <CAHEA9tMB4vgyijZBt-PWEU-SPVvm2ouw1vgntkwss38e5tSh9Q@mail.gmail.com>
 <56280F3A.7070902@apeiron.net>
 <CAHZrzdr0DFFXCcVdOQcudgURNxQ+b7Dt3-NCxqfud1Ugej9DfQ@mail.gmail.com>
 <CAJumaK_7ctgnU1cw0BZM-fourh2yaNuO+K2fc-krNNXss11WDg@mail.gmail.com>
 <5628E4D2.5040904@apeiron.net>
 <CABSPmx2fwvZxgeu5b3Rrh8dd3+Lv9Zz8EnrAkoSofZ9_rp5cig@mail.gmail.com>
 <5629027F.2070607@apeiron.net>
 <CAJumaK_8J9MY-0REkAyB65SH8PxeuD7jvo4=AmxSbTysSpcNcw@mail.gmail.com>
Message-ID: <562915F3.5000505@apeiron.net>


>     I outlined one possible path to avoid this kind of issue: spend more
>     time thinking about ways to maintain compatibility. We had
>     proposals for
>     doing this with AMP.
>
>
> And on the other hand we also had a concrete proposal that didn't
> require language changes that was ridiculously popular. People had
> been talking about Applicative as a superclass of Monad for a decade
> before we finally acted upon the AMP. People had been talking about
> superclass defaulting for a decade. When do you cut off discussion and
> ship the proposal that has overwhelming support? If there is no
> process that enables this you can stall the process indefinitely by
> raising objections of this form. Such a situation is not without costs
> all its own.
>

I agree. It was certainly within the power of the committee to start a
clock and say something like "if we don't have a patch to GHC that
provides backwards compatibility for AMP within 1 year, we will push out
AMP as-is." Had I understand the implications of AMP at the time, or
even been aware that AMP was happening (I was actually actively working
on the GHC code base during that period), that certainly would have been
motivation for me to do something about it! *That* would be how one
could cut off discussion and ship a proposal.

I am not against changing the Prelude! But it sure would be nice if
-XHaskell98 gave me a Haskell 98 Prelude and -XHaskell2010 gave me a
Haskell 2010 Prelude, both of which could be used with external packages
that themselves used the more modern Prelude. Maybe that's impossible.
Setting a firm deadline to finding a solution to the compatibility issue
would have been a way to compromise. Ideally, changing the Prelude
wouldn't require breaking code written to use an older version of the
Prelude. Yes, attaining that goal would require more work.

Evolving the Prelude and maintaining compatibility are not necessarily
mutually exclusive options.

Cheers,
Geoff

From evan at evanrutledgeborden.dreamhosters.com  Thu Oct 22 17:20:21 2015
From: evan at evanrutledgeborden.dreamhosters.com (evan@evan-borden.com)
Date: Thu, 22 Oct 2015 13:20:21 -0400
Subject: Breaking Changes and Long Term Support Haskell
In-Reply-To: <562915F3.5000505@apeiron.net>
References: <87io6zmr2x.fsf@gnu.org>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk>
 <562765FE.6070808@nottingham.ac.uk>
 <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net>
 <a2781834655f4e358b95c6c5fd53e2ac@DB4PR30MB030.064d.mgd.msft.net>
 <5627A4A8.7070107@apeiron.net>
 <CAHEA9tMB4vgyijZBt-PWEU-SPVvm2ouw1vgntkwss38e5tSh9Q@mail.gmail.com>
 <56280F3A.7070902@apeiron.net>
 <CAHZrzdr0DFFXCcVdOQcudgURNxQ+b7Dt3-NCxqfud1Ugej9DfQ@mail.gmail.com>
 <CAJumaK_7ctgnU1cw0BZM-fourh2yaNuO+K2fc-krNNXss11WDg@mail.gmail.com>
 <5628E4D2.5040904@apeiron.net>
 <CABSPmx2fwvZxgeu5b3Rrh8dd3+Lv9Zz8EnrAkoSofZ9_rp5cig@mail.gmail.com>
 <5629027F.2070607@apeiron.net>
 <CAJumaK_8J9MY-0REkAyB65SH8PxeuD7jvo4=AmxSbTysSpcNcw@mail.gmail.com>
 <562915F3.5000505@apeiron.net>
Message-ID: <CABmRwSCyn6S1dA1Y87vxOV1B33ccjHd_vRjmarg-shnR_Kf96Q@mail.gmail.com>

> I am not against changing the Prelude! But it sure would be nice if
> -XHaskell98 gave me a Haskell 98 Prelude and -XHaskell2010 gave me a
> Haskell 2010 Prelude, both of which could be used with external packages
> that themselves used the more modern Prelude.
>

This sounds like quite a herculean task. Changes in base type-classes would
wreak havoc between preludes from differing timelines.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151022/a81d00ce/attachment.html>

From ekmett at gmail.com  Thu Oct 22 17:29:34 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Thu, 22 Oct 2015 13:29:34 -0400
Subject: Breaking Changes and Long Term Support Haskell
In-Reply-To: <562915F3.5000505@apeiron.net>
References: <87io6zmr2x.fsf@gnu.org>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk>
 <562765FE.6070808@nottingham.ac.uk>
 <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net>
 <a2781834655f4e358b95c6c5fd53e2ac@DB4PR30MB030.064d.mgd.msft.net>
 <5627A4A8.7070107@apeiron.net>
 <CAHEA9tMB4vgyijZBt-PWEU-SPVvm2ouw1vgntkwss38e5tSh9Q@mail.gmail.com>
 <56280F3A.7070902@apeiron.net>
 <CAHZrzdr0DFFXCcVdOQcudgURNxQ+b7Dt3-NCxqfud1Ugej9DfQ@mail.gmail.com>
 <CAJumaK_7ctgnU1cw0BZM-fourh2yaNuO+K2fc-krNNXss11WDg@mail.gmail.com>
 <5628E4D2.5040904@apeiron.net>
 <CABSPmx2fwvZxgeu5b3Rrh8dd3+Lv9Zz8EnrAkoSofZ9_rp5cig@mail.gmail.com>
 <5629027F.2070607@apeiron.net>
 <CAJumaK_8J9MY-0REkAyB65SH8PxeuD7jvo4=AmxSbTysSpcNcw@mail.gmail.com>
 <562915F3.5000505@apeiron.net>
Message-ID: <CAJumaK-dmQ+w8ywkVhG0QtggjRx-3=YeNFD9Q8BkHsj73VbYOw@mail.gmail.com>

On Thu, Oct 22, 2015 at 12:59 PM, Geoffrey Mainland <mainland at apeiron.net>
wrote:

>
> >     I outlined one possible path to avoid this kind of issue: spend more
> >     time thinking about ways to maintain compatibility. We had
> >     proposals for
> >     doing this with AMP.
> >
> >
> > And on the other hand we also had a concrete proposal that didn't
> > require language changes that was ridiculously popular. People had
> > been talking about Applicative as a superclass of Monad for a decade
> > before we finally acted upon the AMP. People had been talking about
> > superclass defaulting for a decade. When do you cut off discussion and
> > ship the proposal that has overwhelming support? If there is no
> > process that enables this you can stall the process indefinitely by
> > raising objections of this form. Such a situation is not without costs
> > all its own.
> >
>
> I agree. It was certainly within the power of the committee to start a
> clock and say something like "if we don't have a patch to GHC that
> provides backwards compatibility for AMP within 1 year, we will push out
> AMP as-is." Had I understand the implications of AMP at the time, or
> even been aware that AMP was happening (I was actually actively working
> on the GHC code base during that period), that certainly would have been
> motivation for me to do something about it! *That* would be how one
> could cut off discussion and ship a proposal.
>

I freely admit that there is room for improvement in the process. We're all
learning here.

The current Semigroup-Monoid proposal more or less fits the bill you are
looking for here. We have a roadmap today that migrates an existing package
with several years worth of back support into base more or less unmodified,
and then in 3 releases starts requiring instances. You can think of that 3
release clock as precisely what you are looking for here.

If we get an implementation of superclass defaulting or some other
mechanism that can mitigate the extra couple of lines of code that this
proposal will tax users with, within that timeline, we'd gladly incorporate
it into the proposal.


> I am not against changing the Prelude! But it sure would be nice if
> -XHaskell98 gave me a Haskell 98 Prelude and -XHaskell2010 gave me a
> Haskell 2010 Prelude, both of which could be used with external packages
> that themselves used the more modern Prelude.


It would definitely be a preferable state of affairs. Unfortunately, at
least with the tools available to us today, such a plan is incompatible
with any plan that introduces a new superclass. It also cuts off plans that
ever factors an existing class into two, such as the MonadFail proposals.
We simply do not at this time have the technical capabilities that would
support such a system. If they showed up in GHC we can adapt plans to fit.


> Maybe that's impossible.
> Setting a firm deadline to finding a solution to the compatibility issue
> would have been a way to compromise. Ideally, changing the Prelude
> wouldn't require breaking code written to use an older version of the
> Prelude. Yes, attaining that goal would require more work.
>

We looked around for a year for a roadmap that would get us there. None
presented itself. In the end we wound up shedding the core libraries status
of the haskell98 and haskell2010 packages as the 3-4 different ways in
which one could write a Haskell2010 package all have different trade-offs
and can be maintained in user-land.

Examples:

* A hardline version of haskell2010 with a Monad and Num that fully
complies with the report, but which doesn't work with Monad and Num
instances supplied by other libraries. This needs RebindableSyntax, so it
doesn't quite work right. With compiler support for rebinding syntax to a
particular library instead of to whatever is in scope, such a thing might
be suitable for teaching a Haskell class.

* A pragmatic haskell2010 where the Monad has an Applicative superclass and
Num has the current semantic. This works with everything but doesn't
faithfully follow the report.

*  A middle-ground package that tries to use a superclass defaulting
mechanism that we don't have to supply missing Applicative superclasses
might resolve the Applicative-Monad issue in theory, but does nothing for
report compliance of our existing Num.

Each one of these solutions has flaws. Two of them require innovations in
the compiler that we don't have.


> Evolving the Prelude and maintaining compatibility are not necessarily
> mutually exclusive options.
>

Agreed, but as you can see above, maintaining compatibility isn't
necessarily always a viable option either.

-Edward
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151022/99d594d4/attachment.html>

From greg at gregorycollins.net  Thu Oct 22 17:37:40 2015
From: greg at gregorycollins.net (Gregory Collins)
Date: Thu, 22 Oct 2015 10:37:40 -0700
Subject: Breaking Changes and Long Term Support Haskell
In-Reply-To: <CAJumaK_7ctgnU1cw0BZM-fourh2yaNuO+K2fc-krNNXss11WDg@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk>
 <562765FE.6070808@nottingham.ac.uk>
 <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net>
 <a2781834655f4e358b95c6c5fd53e2ac@DB4PR30MB030.064d.mgd.msft.net>
 <5627A4A8.7070107@apeiron.net>
 <CAHEA9tMB4vgyijZBt-PWEU-SPVvm2ouw1vgntkwss38e5tSh9Q@mail.gmail.com>
 <56280F3A.7070902@apeiron.net>
 <CAHZrzdr0DFFXCcVdOQcudgURNxQ+b7Dt3-NCxqfud1Ugej9DfQ@mail.gmail.com>
 <CAJumaK_7ctgnU1cw0BZM-fourh2yaNuO+K2fc-krNNXss11WDg@mail.gmail.com>
Message-ID: <CAHZrzdrH-z=QMqAX80DMghdDvJhQTin-T2jDZCuipOsbUUt_1A@mail.gmail.com>

On Wed, Oct 21, 2015 at 11:40 PM, Edward Kmett <ekmett at gmail.com> wrote:

> All I'm saying is that if we want to appeal to or cater to working
>> software engineers, we have to be a lot less cavalier about causing more
>> work for them, and we need to prize stability of the core infrastructure
>> more highly. That'd be a broader cultural change, and that goes beyond
>> process: it's policy.
>>
>
> The way things are shaping up, we've had 17 years of rock solid stability
>

I have >95% confidence that all of the C++ programs I wrote 15 years ago
would build and work if I dusted them off and typed "make" today. I have
Haskell programs I wrote last year that I probably couldn't say that about.

So I don't buy that, at all, at least if we're discussing the topic of the
stability of the core infrastructure in general rather than changes being
made to the Prelude. It's been possible to write to Haskell 98 without too
much breakage, yes, but almost nobody actually does that; they write to
Haskell as defined by GHC + the boot libraries + Haskell platform +
Hackage, IMO with decreasing expectations of stability for each. The core
set breaks a lot. We definitely shouldn't adopt a posture to breaking
changes as conservative as the C++ committee's, and literally nobody in the
Haskell community is arguing against breaking changes in general, but as
I've pointed out, most of these breakages could have been avoided with more
careful engineering, and indeed, on many occasions the argument has been
made and it's fallen on deaf ears.

They can speak for themselves but I think for Mark and Johan, this is a
"straw that broke the camel's back" issue rather than anything to do with
the merits of removing return from Monad. I think the blowback just happens
to be so much stronger on MRP because the breaking change is so close to
the core of the language, and the benefits are so nebulous: fixing an
aesthetic problem has almost zero practical value, and ">> could be
slightly more efficient for some monads" is pretty weak sauce.

-- 
Gregory Collins <greg at gregorycollins.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151022/a53a36ea/attachment-0001.html>

From mainland at apeiron.net  Thu Oct 22 17:41:14 2015
From: mainland at apeiron.net (Geoffrey Mainland)
Date: Thu, 22 Oct 2015 13:41:14 -0400
Subject: Breaking Changes and Long Term Support Haskell
In-Reply-To: <CAJumaK-dmQ+w8ywkVhG0QtggjRx-3=YeNFD9Q8BkHsj73VbYOw@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk>
 <562765FE.6070808@nottingham.ac.uk>
 <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net>
 <a2781834655f4e358b95c6c5fd53e2ac@DB4PR30MB030.064d.mgd.msft.net>
 <5627A4A8.7070107@apeiron.net>
 <CAHEA9tMB4vgyijZBt-PWEU-SPVvm2ouw1vgntkwss38e5tSh9Q@mail.gmail.com>
 <56280F3A.7070902@apeiron.net>
 <CAHZrzdr0DFFXCcVdOQcudgURNxQ+b7Dt3-NCxqfud1Ugej9DfQ@mail.gmail.com>
 <CAJumaK_7ctgnU1cw0BZM-fourh2yaNuO+K2fc-krNNXss11WDg@mail.gmail.com>
 <5628E4D2.5040904@apeiron.net>
 <CABSPmx2fwvZxgeu5b3Rrh8dd3+Lv9Zz8EnrAkoSofZ9_rp5cig@mail.gmail.com>
 <5629027F.2070607@apeiron.net>
 <CAJumaK_8J9MY-0REkAyB65SH8PxeuD7jvo4=AmxSbTysSpcNcw@mail.gmail.com>
 <562915F3.5000505@apeiron.net>
 <CAJumaK-dmQ+w8ywkVhG0QtggjRx-3=YeNFD9Q8BkHsj73VbYOw@mail.gmail.com>
Message-ID: <56291FBA.1000604@apeiron.net>

On 10/22/2015 01:29 PM, Edward Kmett wrote:
> On Thu, Oct 22, 2015 at 12:59 PM, Geoffrey Mainland
> <mainland at apeiron.net <mailto:mainland at apeiron.net>> wrote:
>  
>
>     I am not against changing the Prelude! But it sure would be nice if
>     -XHaskell98 gave me a Haskell 98 Prelude and -XHaskell2010 gave me a
>     Haskell 2010 Prelude, both of which could be used with external
>     packages
>     that themselves used the more modern Prelude. 
>
>
> It would definitely be a preferable state of affairs. Unfortunately,
> at least with the tools available to us today, such a plan is
> incompatible with any plan that introduces a new superclass. It also
> cuts off plans that ever factors an existing class into two, such as
> the MonadFail proposals. We simply do not at this time have the
> technical capabilities that would support such a system. If they
> showed up in GHC we can adapt plans to fit.

Great!

Could we work to characterize what technical capabilities we would need
to support full backwards Prelude compatibility?

Here is my rough understanding of what we would need:

1) Some method for "default superclasses." This would solve the AMP issue.

2) A method for factoring existing classes into two (or more) parts.
This would solve the MonadFail problem.

3) A method for imposing extra superclass constraints on a class. This
would be needed for full Num compatibility. Seems much less important
that 1 and 2.

The most thought has gone into 1.

Are these three technical capabilities *all* that we would need? Perhaps
we also need a way to tie the current language (-XHaskell98,
-XHaskell2010) to a particular implementation of the Prelude.

Geoff

From ekmett at gmail.com  Thu Oct 22 18:25:31 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Thu, 22 Oct 2015 14:25:31 -0400
Subject: Breaking Changes and Long Term Support Haskell
In-Reply-To: <56291FBA.1000604@apeiron.net>
References: <87io6zmr2x.fsf@gnu.org>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk>
 <562765FE.6070808@nottingham.ac.uk>
 <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net>
 <a2781834655f4e358b95c6c5fd53e2ac@DB4PR30MB030.064d.mgd.msft.net>
 <5627A4A8.7070107@apeiron.net>
 <CAHEA9tMB4vgyijZBt-PWEU-SPVvm2ouw1vgntkwss38e5tSh9Q@mail.gmail.com>
 <56280F3A.7070902@apeiron.net>
 <CAHZrzdr0DFFXCcVdOQcudgURNxQ+b7Dt3-NCxqfud1Ugej9DfQ@mail.gmail.com>
 <CAJumaK_7ctgnU1cw0BZM-fourh2yaNuO+K2fc-krNNXss11WDg@mail.gmail.com>
 <5628E4D2.5040904@apeiron.net>
 <CABSPmx2fwvZxgeu5b3Rrh8dd3+Lv9Zz8EnrAkoSofZ9_rp5cig@mail.gmail.com>
 <5629027F.2070607@apeiron.net>
 <CAJumaK_8J9MY-0REkAyB65SH8PxeuD7jvo4=AmxSbTysSpcNcw@mail.gmail.com>
 <562915F3.5000505@apeiron.net>
 <CAJumaK-dmQ+w8ywkVhG0QtggjRx-3=YeNFD9Q8BkHsj73VbYOw@mail.gmail.com>
 <56291FBA.1000604@apeiron.net>
Message-ID: <CAJumaK-+BMM6PpUNCCwM5K43kB9HRUtQtj5hab4TLxV9VD-7GA@mail.gmail.com>

On Thu, Oct 22, 2015 at 1:41 PM, Geoffrey Mainland <mainland at apeiron.net>
wrote:

> On 10/22/2015 01:29 PM, Edward Kmett wrote:
> > On Thu, Oct 22, 2015 at 12:59 PM, Geoffrey Mainland
> > <mainland at apeiron.net <mailto:mainland at apeiron.net>> wrote:
> >
> >
> >     I am not against changing the Prelude! But it sure would be nice if
> >     -XHaskell98 gave me a Haskell 98 Prelude and -XHaskell2010 gave me a
> >     Haskell 2010 Prelude, both of which could be used with external
> >     packages
> >     that themselves used the more modern Prelude.
> >
> >
> > It would definitely be a preferable state of affairs. Unfortunately,
> > at least with the tools available to us today, such a plan is
> > incompatible with any plan that introduces a new superclass. It also
> > cuts off plans that ever factors an existing class into two, such as
> > the MonadFail proposals. We simply do not at this time have the
> > technical capabilities that would support such a system. If they
> > showed up in GHC we can adapt plans to fit.
>
> Great!
>
> Could we work to characterize what technical capabilities we would need
> to support full backwards Prelude compatibility?
>
> Here is my rough understanding of what we would need:
>
> 1) Some method for "default superclasses." This would solve the AMP issue.
>
> 2) A method for factoring existing classes into two (or more) parts.
> This would solve the MonadFail problem.
>
> 3) A method for imposing extra superclass constraints on a class. This
> would be needed for full Num compatibility. Seems much less important
> that 1 and 2.
>
> The most thought has gone into 1.
>

> Are these three technical capabilities *all* that we would need? Perhaps
> we also need a way to tie the current language (-XHaskell98,
> -XHaskell2010) to a particular implementation of the Prelude.
>

I don't have a concrete plan here. I'm not even sure one can be achieved
that works. I'd say that the burden of figuring out such a thing falls on
the party that can create a plan, pitch it to the community and potentially
implement it.

If I enumerate a set of conditions here I'm basically implying that I'd
agree to any plan that incorporated them. I'm just not prepared to make
that commitment sight-unseen to something with unknown warts and
implications.

I can, however, say that it is plausible that what you have enumerated
above could potentially address the outstanding issues, but I don't know
how good of a compromise the result would be.

-Edward
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151022/3abb6306/attachment.html>

From ekmett at gmail.com  Thu Oct 22 18:44:54 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Thu, 22 Oct 2015 14:44:54 -0400
Subject: Breaking Changes and Long Term Support Haskell
In-Reply-To: <CAHZrzdrH-z=QMqAX80DMghdDvJhQTin-T2jDZCuipOsbUUt_1A@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <alpine.DEB.2.02.1510011830520.7958@sputnik>
 <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk>
 <562765FE.6070808@nottingham.ac.uk>
 <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net>
 <a2781834655f4e358b95c6c5fd53e2ac@DB4PR30MB030.064d.mgd.msft.net>
 <5627A4A8.7070107@apeiron.net>
 <CAHEA9tMB4vgyijZBt-PWEU-SPVvm2ouw1vgntkwss38e5tSh9Q@mail.gmail.com>
 <56280F3A.7070902@apeiron.net>
 <CAHZrzdr0DFFXCcVdOQcudgURNxQ+b7Dt3-NCxqfud1Ugej9DfQ@mail.gmail.com>
 <CAJumaK_7ctgnU1cw0BZM-fourh2yaNuO+K2fc-krNNXss11WDg@mail.gmail.com>
 <CAHZrzdrH-z=QMqAX80DMghdDvJhQTin-T2jDZCuipOsbUUt_1A@mail.gmail.com>
Message-ID: <CAJumaK8ghOSqCenWQ0xA_p=X=CNpNHwLxu1VcrdpLq7JG=48fQ@mail.gmail.com>

On Thu, Oct 22, 2015 at 1:37 PM, Gregory Collins <greg at gregorycollins.net>
wrote:

>
> On Wed, Oct 21, 2015 at 11:40 PM, Edward Kmett <ekmett at gmail.com> wrote:
>
>> All I'm saying is that if we want to appeal to or cater to working
>>> software engineers, we have to be a lot less cavalier about causing more
>>> work for them, and we need to prize stability of the core infrastructure
>>> more highly. That'd be a broader cultural change, and that goes beyond
>>> process: it's policy.
>>>
>>
>> The way things are shaping up, we've had 17 years of rock solid stability
>>
>
> I have >95% confidence that all of the C++ programs I wrote 15 years ago
> would build and work if I dusted them off and typed "make" today. I have
> Haskell programs I wrote last year that I probably couldn't say that about.
>
> So I don't buy that, at all, at least if we're discussing the topic of the
> stability of the core infrastructure in general rather than changes being
> made to the Prelude. It's been possible to write to Haskell 98 without too
> much breakage, yes, but almost nobody actually does that; they write to
> Haskell as defined by GHC + the boot libraries + Haskell platform +
> Hackage, IMO with decreasing expectations of stability for each. The core
> set breaks a lot.
>

I definitely agree here.

We have a lot of libraries in the Haskell Platform that have fairly liberal
change policies. On the other hand, we have a policy of "maintainer
decides" around issues. This yields a fairly decentralized change
management process, with different maintainers who have different views.
The Platform gives us a central pool of packages that are generally the
"best of breed" in their respective spaces, but gives us few stability
guarantees.

Heck, every release I wind up having to change whatever code I have that
uses template-haskell or Typeable.

On the other hand, it isn't clear with a larger "core" platform with harder
stability guarantees that we have a volunteer force that can and would sign
up for the long slog of maintenance without that level of autonomy.


> We definitely shouldn't adopt a posture to breaking changes as
> conservative as the C++ committee's, and literally nobody in the Haskell
> community is arguing against breaking changes in general, but as I've
> pointed out, most of these breakages could have been avoided with more
> careful engineering, and indeed, on many occasions the argument has been
> made and it's fallen on deaf ears.
>

I would argue that there are individual maintainers that give lie to that
statement. In many ways Johan himself has served as a counter-example
there. The libraries he has maintained have acted as a form of bedrock with
long maintenance windows. On the other hand, the burden of maintaining that
stability seems to have ultimately burned him out.

They can speak for themselves but I think for Mark and Johan, this is a
> "straw that broke the camel's back" issue rather than anything to do with
> the merits of removing return from Monad. I think the blowback just happens
> to be so much stronger on MRP because the breaking change is so close to
> the core of the language, and the benefits are so nebulous. fixing an
> aesthetic problem has almost zero practical value
>

I personally don't care about the return side of the equation.

Herbert's MRP proposal was an attempt by him to finish out the changes
started by AMP so that a future Haskell Report can read cleanly. Past
reports have been remarkably free of historical baggage.

I'd personally readily sacrifice "progress" there in the interest of
harmony. Herbert as haskell-prime chair possibly feels differently.


> and ">> could be slightly more efficient for some monads" is pretty weak
> sauce.
>

The issue right now around (>>) is that it has knock-on effects that run
pretty far and wide. "Weak sauce" or not, it means through second order
consequences that we can't move the useless mapM and sequence to the top
level from their current status as memberrs of Traversable and that users
have to care about which of two provably equivalent things that they are
using, at all times.

It means that code that calls mapM will be less efficient and that mapM_
behaves in a manner with rather radically different space and time behavior
than mapM today and not in a consistently good way.

-Edward
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151022/1c1cc4be/attachment.html>

From spam at scientician.net  Thu Oct 22 18:52:49 2015
From: spam at scientician.net (Bardur Arantsson)
Date: Thu, 22 Oct 2015 20:52:49 +0200
Subject: Breaking Changes and Long Term Support Haskell
In-Reply-To: <CAHZrzdrH-z=QMqAX80DMghdDvJhQTin-T2jDZCuipOsbUUt_1A@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <6C299172-B95C-44C0-A664-F92AD11218B6@me.com>
 <B39B2C3C-B782-4841-9710-ECDFED067579@visions-york.org>
 <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com>
 <CACQVYRBEWNR+nYGhn6h=6SKAnU9CUDWY_X6sKUx562uyXCnGzg@mail.gmail.com>
 <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk>
 <etPan.56128a31.41b8da8.7b73@mbp.local>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk>
 <562765FE.6070808@nottingham.ac.uk>
 <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net>
 <a2781834655f4e358b95c6c5fd53e2ac@DB4PR30MB030.064d.mgd.msft.net>
 <5627A4A8.7070107@apeiron.net>
 <CAHEA9tMB4vgyijZBt-PWEU-SPVvm2ouw1vgntkwss38e5tSh9Q@mail.gmail.com>
 <56280F3A.7070902@apeiron.net>
 <CAHZrzdr0DFFXCcVdOQcudgURNxQ+b7Dt3-NCxqfud1Ugej9DfQ@mail.gmail.com>
 <CAJumaK_7ctgnU1cw0BZM-fourh2yaNuO+K2fc-krNNXss11WDg@mail.gmail.com>
 <CAHZrzdrH-z=QMqAX80DMghdDvJhQTin-T2jDZCuipOsbUUt_1A@mail.gmail.com>
Message-ID: <n0bba1$jg2$1@ger.gmane.org>

On 10/22/2015 07:37 PM, Gregory Collins wrote:
> On Wed, Oct 21, 2015 at 11:40 PM, Edward Kmett <ekmett at gmail.com> wrote:
> 
>> All I'm saying is that if we want to appeal to or cater to working
>>> software engineers, we have to be a lot less cavalier about causing more
>>> work for them, and we need to prize stability of the core infrastructure
>>> more highly. That'd be a broader cultural change, and that goes beyond
>>> process: it's policy.
>>>
>>
>> The way things are shaping up, we've had 17 years of rock solid stability
>>
> 
> I have >95% confidence that all of the C++ programs I wrote 15 years ago
> would build and work if I dusted them off and typed "make" today. I have
> Haskell programs I wrote last year that I probably couldn't say that about.
> 

I wouldn't be so confident, if I were you :). Did you use *any* external
libraries in your project? You'll probably find that no distibution
actually ships the versions you used. Did you have any
implemenetation-defined behavior in your project? That behavior may well
have changed with a more up-to-date compiler -- and good luck getting
that old compiler running on any current platform. (&c.)

It would be interesting as a data point if you could just try a few
projects.

Regards,



From mainland at apeiron.net  Thu Oct 22 19:06:32 2015
From: mainland at apeiron.net (Geoffrey Mainland)
Date: Thu, 22 Oct 2015 15:06:32 -0400
Subject: Breaking Changes and Long Term Support Haskell
In-Reply-To: <CAJumaK-+BMM6PpUNCCwM5K43kB9HRUtQtj5hab4TLxV9VD-7GA@mail.gmail.com>
References: <87io6zmr2x.fsf@gnu.org>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk>
 <562765FE.6070808@nottingham.ac.uk>
 <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net>
 <a2781834655f4e358b95c6c5fd53e2ac@DB4PR30MB030.064d.mgd.msft.net>
 <5627A4A8.7070107@apeiron.net>
 <CAHEA9tMB4vgyijZBt-PWEU-SPVvm2ouw1vgntkwss38e5tSh9Q@mail.gmail.com>
 <56280F3A.7070902@apeiron.net>
 <CAHZrzdr0DFFXCcVdOQcudgURNxQ+b7Dt3-NCxqfud1Ugej9DfQ@mail.gmail.com>
 <CAJumaK_7ctgnU1cw0BZM-fourh2yaNuO+K2fc-krNNXss11WDg@mail.gmail.com>
 <5628E4D2.5040904@apeiron.net>
 <CABSPmx2fwvZxgeu5b3Rrh8dd3+Lv9Zz8EnrAkoSofZ9_rp5cig@mail.gmail.com>
 <5629027F.2070607@apeiron.net>
 <CAJumaK_8J9MY-0REkAyB65SH8PxeuD7jvo4=AmxSbTysSpcNcw@mail.gmail.com>
 <562915F3.5000505@apeiron.net>
 <CAJumaK-dmQ+w8ywkVhG0QtggjRx-3=YeNFD9Q8BkHsj73VbYOw@mail.gmail.com>
 <56291FBA.1000604@apeiron.net>
 <CAJumaK-+BMM6PpUNCCwM5K43kB9HRUtQtj5hab4TLxV9VD-7GA@mail.gmail.com>
Message-ID: <562933B8.3020207@apeiron.net>

On 10/22/2015 02:25 PM, Edward Kmett wrote:
>
> On Thu, Oct 22, 2015 at 1:41 PM, Geoffrey Mainland
> <mainland at apeiron.net <mailto:mainland at apeiron.net>> wrote:
>
>     On 10/22/2015 01:29 PM, Edward Kmett wrote:
>     > On Thu, Oct 22, 2015 at 12:59 PM, Geoffrey Mainland
>     > <mainland at apeiron.net <mailto:mainland at apeiron.net>
>     <mailto:mainland at apeiron.net <mailto:mainland at apeiron.net>>> wrote:
>     >
>     >
>     >     I am not against changing the Prelude! But it sure would be
>     nice if
>     >     -XHaskell98 gave me a Haskell 98 Prelude and -XHaskell2010
>     gave me a
>     >     Haskell 2010 Prelude, both of which could be used with external
>     >     packages
>     >     that themselves used the more modern Prelude.
>     >
>     >
>     > It would definitely be a preferable state of affairs. Unfortunately,
>     > at least with the tools available to us today, such a plan is
>     > incompatible with any plan that introduces a new superclass. It also
>     > cuts off plans that ever factors an existing class into two, such as
>     > the MonadFail proposals. We simply do not at this time have the
>     > technical capabilities that would support such a system. If they
>     > showed up in GHC we can adapt plans to fit.
>
>     Great!
>
>     Could we work to characterize what technical capabilities we would
>     need
>     to support full backwards Prelude compatibility?
>
>     Here is my rough understanding of what we would need:
>
>     1) Some method for "default superclasses." This would solve the
>     AMP issue.
>
>     2) A method for factoring existing classes into two (or more) parts.
>     This would solve the MonadFail problem.
>
>     3) A method for imposing extra superclass constraints on a class. This
>     would be needed for full Num compatibility. Seems much less important
>     that 1 and 2.
>
>     The most thought has gone into 1.
>
>
>     Are these three technical capabilities *all* that we would need?
>     Perhaps
>     we also need a way to tie the current language (-XHaskell98,
>     -XHaskell2010) to a particular implementation of the Prelude.
>
>  
> I don't have a concrete plan here. I'm not even sure one can be
> achieved that works. I'd say that the burden of figuring out such a
> thing falls on the party that can create a plan, pitch it to the
> community and potentially implement it.
>
> If I enumerate a set of conditions here I'm basically implying that
> I'd agree to any plan that incorporated them. I'm just not prepared to
> make that commitment sight-unseen to something with unknown warts and
> implications.
>
> I can, however, say that it is plausible that what you have enumerated
> above could potentially address the outstanding issues, but I don't
> know how good of a compromise the result would be. 
>
> -Edward

I don't have a concrete plan either, not am I sure that one is possible.
But I don't see how having a conversation about how one might achieve
backwards compatibility would commit anyone to anything. Any eventual
proposal would have to go through the same approval process as every
other proposal. And even if we did have a hypothetical draft proposal
that you had at some point stated you approved of in some way, you would
always be free to change your mind!

Isn't the libraries list exactly where this sort of conversation should
happen?

Cheers,
Geoff

From simonpj at microsoft.com  Thu Oct 22 19:14:18 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 22 Oct 2015 19:14:18 +0000
Subject: Breaking Changes and Long Term Support Haskell
In-Reply-To: <562933B8.3020207@apeiron.net>
References: <87io6zmr2x.fsf@gnu.org>
 <A5593C08-0BDD-4A10-B207-1B98581DAD5C@serpentine.com>
 <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk>
 <562765FE.6070808@nottingham.ac.uk>
 <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net>
 <a2781834655f4e358b95c6c5fd53e2ac@DB4PR30MB030.064d.mgd.msft.net>
 <5627A4A8.7070107@apeiron.net>
 <CAHEA9tMB4vgyijZBt-PWEU-SPVvm2ouw1vgntkwss38e5tSh9Q@mail.gmail.com>
 <56280F3A.7070902@apeiron.net>
 <CAHZrzdr0DFFXCcVdOQcudgURNxQ+b7Dt3-NCxqfud1Ugej9DfQ@mail.gmail.com>
 <CAJumaK_7ctgnU1cw0BZM-fourh2yaNuO+K2fc-krNNXss11WDg@mail.gmail.com>
 <5628E4D2.5040904@apeiron.net>
 <CABSPmx2fwvZxgeu5b3Rrh8dd3+Lv9Zz8EnrAkoSofZ9_rp5cig@mail.gmail.com>
 <5629027F.2070607@apeiron.net>
 <CAJumaK_8J9MY-0REkAyB65SH8PxeuD7jvo4=AmxSbTysSpcNcw@mail.gmail.com>
 <562915F3.5000505@apeiron.net>
 <CAJumaK-dmQ+w8ywkVhG0QtggjRx-3=YeNFD9Q8BkHsj73VbYOw@mail.gmail.com>
 <56291FBA.1000604@apeiron.net>
 <CAJumaK-+BMM6PpUNCCwM5K43kB9HRUtQtj5hab4TLxV9VD-7GA@mail.gmail.com>
 <562933B8.3020207@apeiron.net>
Message-ID: <299e396754324ef298bbd711a19aa636@DB4PR30MB030.064d.mgd.msft.net>

| >     Are these three technical capabilities *all* that we would need?
| >     Perhaps
| >     we also need a way to tie the current language (-XHaskell98,
| >     -XHaskell2010) to a particular implementation of the Prelude.
| >
| >
| > I don't have a concrete plan here. I'm not even sure one can be
| > achieved that works. I'd say that the burden of figuring out such a
| > thing falls on the party that can create a plan, pitch it to the
| > community and potentially implement it.

In fact there is more than one concrete plan: https://ghc.haskell.org/trac/ghc/wiki/IntrinsicSuperclasses

All are complex, only partially designed, entirely unimplemented (and the implementation will be non-trivial), and lacking an active champion.  The one I link to above is probably the leading contender, but it feels too complicated to me.

Simon


From david.feuer at gmail.com  Sat Oct 24 18:07:51 2015
From: david.feuer at gmail.com (David Feuer)
Date: Sat, 24 Oct 2015 14:07:51 -0400
Subject: Add stricter accumulating map
In-Reply-To: <CAMgWh9s-oecE8bEn1gfPUTs12PEoshvmbiQYHcbOUV3QY4vU-w@mail.gmail.com>
References: <CAMgWh9t1zF6JCRwtpJ4FsJPhDvLwbh9Sg8E=bos==d-8CMe8kg@mail.gmail.com>
 <CAMgWh9s-oecE8bEn1gfPUTs12PEoshvmbiQYHcbOUV3QY4vU-w@mail.gmail.com>
Message-ID: <CAMgWh9vmpBVc3Afbjf44uOrnLGmT9xveEpM=Umm05OyLn-GG2w@mail.gmail.com>

mapAccumL is a generally useful operation on Traversable containers. The
only version currently offered uses (a copy of) lazy state to support
streaming left-to-right consumption. This does not, however, seem terribly
appropriate/efficient for other usage patterns (e.g., a FIFO queue with
right view, or a Map). Could we add a version that uses a copy of
Control.Monad.Trans.State.Strict to support those too?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151024/3e12e333/attachment.html>

From anfarmer at fb.com  Mon Oct 26 22:38:18 2015
From: anfarmer at fb.com (Andrew Farmer)
Date: Mon, 26 Oct 2015 22:38:18 +0000
Subject: Data.OldList
Message-ID: <D253F969.1418%anfarmer@fb.com>

I was wondering what the plan for Data.OldList was. Is this just a transitional module for FTP-related migration, or can I count on it being maintained indefinitely?

Thanks!
Andrew

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151026/ac6c410e/attachment.html>

From ekmett at gmail.com  Tue Oct 27 06:04:50 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Tue, 27 Oct 2015 02:04:50 -0400
Subject: Data.OldList
In-Reply-To: <D253F969.1418%anfarmer@fb.com>
References: <D253F969.1418%anfarmer@fb.com>
Message-ID: <CAJumaK90_KazJvrap==_QKGhk+zfo1y4SuHE+A=CtWLTPdDjTg@mail.gmail.com>

While I can say we don't have any immediate intention of killing it off,
like virtually everything in the GHC namespace we haven't officially
blessed it as anything fully supported and long-term stable.

GHC.OldList was shipped mostly for internal reasons. Since there wasn't a
library discussion about it, it didn't become Data.OldList in the public
export list, that is just the module name it has internally in base.

There are three potential fates I can see. We might keep it where it is,
seek to move more (or all) of it into GHC.List if we can do so while avoid
import cycles, or declare parts of it officially maintained as a part of
the more public-facing Data hierarchy in something like Data.OldList or
Data.List.Old.

I personally have little preference between these three and could likely be
swayed by a strong argument. That third suggestion could be taken up as an
adjunct to a proposal to clean up the generalized combinators in Data.List,
which would be the most likely forcing function on making a decision here.

-Edward

On Mon, Oct 26, 2015 at 6:38 PM, Andrew Farmer <anfarmer at fb.com> wrote:

> I was wondering what the plan for Data.OldList was. Is this just a
> transitional module for FTP-related migration, or can I count on it being
> maintained indefinitely?
>
> Thanks!
> Andrew
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151027/712c2dc4/attachment.html>

From cma at bitemyapp.com  Thu Oct 29 04:14:03 2015
From: cma at bitemyapp.com (Christopher Allen)
Date: Wed, 28 Oct 2015 23:14:03 -0500
Subject: Maintainership of cassava
Message-ID: <CADnndOpOhkNDPKuLwkYDmgR-PG7U3c4vGBj0znUGYozDVQYzXA@mail.gmail.com>

It wasn't listed in Johan's personal libraries he'd like to investigate
personally and it's not part of CLC.

Only uploader for the cassava package on Hackage at the moment is him.

I pinged a week ago via email, no reply. Pinged on Twitter, no reply. Seems
to be online (tweeted earlier today), but hasn't replied to any queries
about the status of the library.

Cheers,
Chris Allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151028/babe211d/attachment.html>

From roma at ro-che.info  Thu Oct 29 15:34:13 2015
From: roma at ro-che.info (Roman Cheplyaka)
Date: Thu, 29 Oct 2015 17:34:13 +0200
Subject: Proposal: make minimumBy/maximumBy go through foldl', not foldr1
Message-ID: <56323C75.20301@ro-che.info>

I just realized (thanks to this reddit thread[1]) that minimumBy is now
implemented through foldr1. Previously (before FTP), minimumBy from Data.List
used foldl1, while minimumBy from Data.Foldable used foldr1.

I think that the way these were merged was a mistake.

Let's admit that the absolute majority of use cases for minimumBy are numbers,
for which the comparison functions are strict in both arguments. Even for
something like Bool, where comparison could potentially be in one of the
arguments, the standard compare method is derived and is strict.

Now, for Foldable, there isn't necesarily a connection between the direction and
the way fold is performed. For example, for Data.Map.Map both folds are
tail-recursive. Yet foldr is non-tail-recursive at least for:

- good old lists
- anything that uses the same convention for foldl/foldr as lists
- anything that defines its foldable instance through conversion to lists
- anything that uses the default implementation of foldr/foldr1

I also put a simple microbenchmark[2] to show the difference in performance;
on it, the proposed implementation is more than 20x faster than the current one.

[1]: https://www.reddit.com/r/haskell/comments/3qpefo/a_very_unfortunate_error_message/
[2]: http://lpaste.net/714261956202070016

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151029/61bf2977/attachment.sig>

From roma at ro-che.info  Thu Oct 29 15:56:14 2015
From: roma at ro-che.info (Roman Cheplyaka)
Date: Thu, 29 Oct 2015 17:56:14 +0200
Subject: Proposal: make minimumBy/maximumBy go through foldl', not foldr1
In-Reply-To: <56323C75.20301@ro-che.info>
References: <56323C75.20301@ro-che.info>
Message-ID: <5632419E.6090704@ro-che.info>

To clarify: the implementation I used in the benchmark is monomorphic.
(I could have used foldl1' from Data.List instead). A polymorphic
implementation could compose that with Data.Foldable.toList, unless
someone comes up with an even faster polymorphic version.

On 10/29/2015 05:34 PM, Roman Cheplyaka wrote:
> I just realized (thanks to this reddit thread[1]) that minimumBy is now
> implemented through foldr1. Previously (before FTP), minimumBy from Data.List
> used foldl1, while minimumBy from Data.Foldable used foldr1.
> 
> I think that the way these were merged was a mistake.
> 
> Let's admit that the absolute majority of use cases for minimumBy are numbers,
> for which the comparison functions are strict in both arguments. Even for
> something like Bool, where comparison could potentially be in one of the
> arguments, the standard compare method is derived and is strict.
> 
> Now, for Foldable, there isn't necesarily a connection between the direction and
> the way fold is performed. For example, for Data.Map.Map both folds are
> tail-recursive. Yet foldr is non-tail-recursive at least for:
> 
> - good old lists
> - anything that uses the same convention for foldl/foldr as lists
> - anything that defines its foldable instance through conversion to lists
> - anything that uses the default implementation of foldr/foldr1
> 
> I also put a simple microbenchmark[2] to show the difference in performance;
> on it, the proposed implementation is more than 20x faster than the current one.
> 
> [1]: https://www.reddit.com/r/haskell/comments/3qpefo/a_very_unfortunate_error_message/
> [2]: http://lpaste.net/714261956202070016
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151029/6c592ee8/attachment.sig>

From mail at joachim-breitner.de  Thu Oct 29 18:06:55 2015
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 29 Oct 2015 19:06:55 +0100
Subject: Proposal: make minimumBy/maximumBy go through foldl', not foldr1
In-Reply-To: <56323C75.20301@ro-che.info>
References: <56323C75.20301@ro-che.info>
Message-ID: <1446142015.2347.4.camel@joachim-breitner.de>

Hi,

Am Donnerstag, den 29.10.2015, 17:34 +0200 schrieb Roman Cheplyaka:
> I just realized (thanks to this reddit thread[1]) that minimumBy is now
> implemented through foldr1. Previously (before FTP), minimumBy from Data.List
> used foldl1, while minimumBy from Data.Foldable used foldr1.
>
> I think that the way these were merged was a mistake.

this has also been raised by Neil at
https://ghc.haskell.org/trac/ghc/ticket/10830

Also note?https://ghc.haskell.org/trac/ghc/ticket/3416?where it is
stated that the report demands minimum (and hence minimumBy) to be
lazy.

Ignoring that argument, and that of not changing libraries light-
harted, I do think that foldl1' would be the better choice here; users
who rely on laziness here are likely in the minority and it would be
reasonable to expect them to manually use foldl1 or foldr1.

BTW, why is there no fold' method in Foldable that leaves the
associativity (left, right, or mixed in case of a tree) to the Foldable
instance?


Greetings,
Joachim

-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151029/b17834a7/attachment.sig>

From david.feuer at gmail.com  Thu Oct 29 18:15:07 2015
From: david.feuer at gmail.com (David Feuer)
Date: Thu, 29 Oct 2015 14:15:07 -0400
Subject: Proposal: make minimumBy/maximumBy go through foldl', not foldr1
In-Reply-To: <1446142015.2347.4.camel@joachim-breitner.de>
References: <56323C75.20301@ro-che.info>
 <1446142015.2347.4.camel@joachim-breitner.de>
Message-ID: <CAMgWh9vhwraoQqthnEPFN7RMFhR0ZQ6spYy1tS=y6PDM_GznqQ@mail.gmail.com>

I think it would be very nice to offer a few folds tailored to specific
strictness patterns. I'm not sure of the best interface, however.
On Oct 29, 2015 2:07 PM, "Joachim Breitner" <mail at joachim-breitner.de>
wrote:

> Hi,
>
> Am Donnerstag, den 29.10.2015, 17:34 +0200 schrieb Roman Cheplyaka:
> > I just realized (thanks to this reddit thread[1]) that minimumBy is now
> > implemented through foldr1. Previously (before FTP), minimumBy from
> Data.List
> > used foldl1, while minimumBy from Data.Foldable used foldr1.
> >
> > I think that the way these were merged was a mistake.
>
> this has also been raised by Neil at
> https://ghc.haskell.org/trac/ghc/ticket/10830
>
> Also note https://ghc.haskell.org/trac/ghc/ticket/3416 where it is
> stated that the report demands minimum (and hence minimumBy) to be
> lazy.
>
> Ignoring that argument, and that of not changing libraries light-
> harted, I do think that foldl1' would be the better choice here; users
> who rely on laziness here are likely in the minority and it would be
> reasonable to expect them to manually use foldl1 or foldr1.
>
> BTW, why is there no fold' method in Foldable that leaves the
> associativity (left, right, or mixed in case of a tree) to the Foldable
> instance?
>
>
> Greetings,
> Joachim
>
> --
> Joachim ?nomeata? Breitner
>   mail at joachim-breitner.de ? http://www.joachim-breitner.de/
>   Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
>   Debian Developer: nomeata at debian.org
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151029/854f3b63/attachment.html>

From bart.massey at gmail.com  Thu Oct 29 18:29:28 2015
From: bart.massey at gmail.com (Bart Massey)
Date: Thu, 29 Oct 2015 18:29:28 +0000
Subject: Proposal: make minimumBy/maximumBy go through foldl', not foldr1
In-Reply-To: <CAMgWh9vhwraoQqthnEPFN7RMFhR0ZQ6spYy1tS=y6PDM_GznqQ@mail.gmail.com>
References: <56323C75.20301@ro-che.info>
 <1446142015.2347.4.camel@joachim-breitner.de>
 <CAMgWh9vhwraoQqthnEPFN7RMFhR0ZQ6spYy1tS=y6PDM_GznqQ@mail.gmail.com>
Message-ID: <CAA6gtpkkpf+eq2MinU=xnq4VAc4zmW5b3kDtnYa_vy-qZm7NZw@mail.gmail.com>

I'm super-confused here. It is claimed that the Haskell 98 Report requires
List.minimumBy and List.maximumBy to be lazy, but the sample
implementations given there use foldl1 (
https://www.haskell.org/onlinereport/list.html) and I can't find anyplace
in the report where that's explicitly said to be wrong. What am I missing?

On Thu, Oct 29, 2015 at 11:15 AM David Feuer <david.feuer at gmail.com> wrote:

> I think it would be very nice to offer a few folds tailored to specific
> strictness patterns. I'm not sure of the best interface, however.
> On Oct 29, 2015 2:07 PM, "Joachim Breitner" <mail at joachim-breitner.de>
> wrote:
>
>> Hi,
>>
>> Am Donnerstag, den 29.10.2015, 17:34 +0200 schrieb Roman Cheplyaka:
>> > I just realized (thanks to this reddit thread[1]) that minimumBy is now
>> > implemented through foldr1. Previously (before FTP), minimumBy from
>> Data.List
>> > used foldl1, while minimumBy from Data.Foldable used foldr1.
>> >
>> > I think that the way these were merged was a mistake.
>>
>> this has also been raised by Neil at
>> https://ghc.haskell.org/trac/ghc/ticket/10830
>>
>> Also note https://ghc.haskell.org/trac/ghc/ticket/3416 where it is
>> stated that the report demands minimum (and hence minimumBy) to be
>> lazy.
>>
>> Ignoring that argument, and that of not changing libraries light-
>> harted, I do think that foldl1' would be the better choice here; users
>> who rely on laziness here are likely in the minority and it would be
>> reasonable to expect them to manually use foldl1 or foldr1.
>>
>> BTW, why is there no fold' method in Foldable that leaves the
>> associativity (left, right, or mixed in case of a tree) to the Foldable
>> instance?
>>
>>
>> Greetings,
>> Joachim
>>
>> --
>> Joachim ?nomeata? Breitner
>>   mail at joachim-breitner.de ? http://www.joachim-breitner.de/
>>   Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
>>   Debian Developer: nomeata at debian.org
>>
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151029/51b5bcd6/attachment-0001.html>

From sumit.sahrawat.apm13 at iitbhu.ac.in  Thu Oct 29 18:31:35 2015
From: sumit.sahrawat.apm13 at iitbhu.ac.in (Sumit Sahrawat, Maths & Computing,
 IIT (BHU))
Date: Fri, 30 Oct 2015 00:01:35 +0530
Subject: Proposal: make minimumBy/maximumBy go through foldl', not foldr1
In-Reply-To: <CAA6gtpkkpf+eq2MinU=xnq4VAc4zmW5b3kDtnYa_vy-qZm7NZw@mail.gmail.com>
References: <56323C75.20301@ro-che.info>
 <1446142015.2347.4.camel@joachim-breitner.de>
 <CAMgWh9vhwraoQqthnEPFN7RMFhR0ZQ6spYy1tS=y6PDM_GznqQ@mail.gmail.com>
 <CAA6gtpkkpf+eq2MinU=xnq4VAc4zmW5b3kDtnYa_vy-qZm7NZw@mail.gmail.com>
Message-ID: <CAJbEW8P4DAKCm5aNAs5h3B_Pcwzu1V1T6wpmd6+kvbM7FFhw+g@mail.gmail.com>

foldl1 is lazy, whereas foldl1' is strict. The primes are usually used to
indicate strictness.

On 29 October 2015 at 23:59, Bart Massey <bart.massey at gmail.com> wrote:

> I'm super-confused here. It is claimed that the Haskell 98 Report requires
> List.minimumBy and List.maximumBy to be lazy, but the sample
> implementations given there use foldl1 (
> https://www.haskell.org/onlinereport/list.html) and I can't find anyplace
> in the report where that's explicitly said to be wrong. What am I missing?
>
> On Thu, Oct 29, 2015 at 11:15 AM David Feuer <david.feuer at gmail.com>
> wrote:
>
>> I think it would be very nice to offer a few folds tailored to specific
>> strictness patterns. I'm not sure of the best interface, however.
>> On Oct 29, 2015 2:07 PM, "Joachim Breitner" <mail at joachim-breitner.de>
>> wrote:
>>
>>> Hi,
>>>
>>> Am Donnerstag, den 29.10.2015, 17:34 +0200 schrieb Roman Cheplyaka:
>>> > I just realized (thanks to this reddit thread[1]) that minimumBy is now
>>> > implemented through foldr1. Previously (before FTP), minimumBy from
>>> Data.List
>>> > used foldl1, while minimumBy from Data.Foldable used foldr1.
>>> >
>>> > I think that the way these were merged was a mistake.
>>>
>>> this has also been raised by Neil at
>>> https://ghc.haskell.org/trac/ghc/ticket/10830
>>>
>>> Also note https://ghc.haskell.org/trac/ghc/ticket/3416 where it is
>>> stated that the report demands minimum (and hence minimumBy) to be
>>> lazy.
>>>
>>> Ignoring that argument, and that of not changing libraries light-
>>> harted, I do think that foldl1' would be the better choice here; users
>>> who rely on laziness here are likely in the minority and it would be
>>> reasonable to expect them to manually use foldl1 or foldr1.
>>>
>>> BTW, why is there no fold' method in Foldable that leaves the
>>> associativity (left, right, or mixed in case of a tree) to the Foldable
>>> instance?
>>>
>>>
>>> Greetings,
>>> Joachim
>>>
>>> --
>>> Joachim ?nomeata? Breitner
>>>   mail at joachim-breitner.de ? http://www.joachim-breitner.de/
>>>   Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
>>>   Debian Developer: nomeata at debian.org
>>>
>>>
>>> _______________________________________________
>>> Libraries mailing list
>>> Libraries at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>
>>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>


-- 
Regards

Sumit Sahrawat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151030/050d56a4/attachment.html>

From bart.massey at gmail.com  Thu Oct 29 18:55:59 2015
From: bart.massey at gmail.com (Bart Massey)
Date: Thu, 29 Oct 2015 18:55:59 +0000
Subject: Proposal: make minimumBy/maximumBy go through foldl', not foldr1
In-Reply-To: <CAJbEW8P4DAKCm5aNAs5h3B_Pcwzu1V1T6wpmd6+kvbM7FFhw+g@mail.gmail.com>
References: <56323C75.20301@ro-che.info>
 <1446142015.2347.4.camel@joachim-breitner.de>
 <CAMgWh9vhwraoQqthnEPFN7RMFhR0ZQ6spYy1tS=y6PDM_GznqQ@mail.gmail.com>
 <CAA6gtpkkpf+eq2MinU=xnq4VAc4zmW5b3kDtnYa_vy-qZm7NZw@mail.gmail.com>
 <CAJbEW8P4DAKCm5aNAs5h3B_Pcwzu1V1T6wpmd6+kvbM7FFhw+g@mail.gmail.com>
Message-ID: <CAA6gtpmw+TJijFmc877KJRDWJ+oahXAKX6dqWoQzqaX7=-hejw@mail.gmail.com>

Oh, right: I missed the prime. Apologies for cluttering the discussion.

On Thu, Oct 29, 2015 at 11:31 AM Sumit Sahrawat, Maths & Computing, IIT
(BHU) <sumit.sahrawat.apm13 at iitbhu.ac.in> wrote:

> foldl1 is lazy, whereas foldl1' is strict. The primes are usually used to
> indicate strictness.
>
> On 29 October 2015 at 23:59, Bart Massey <bart.massey at gmail.com> wrote:
>
>> I'm super-confused here. It is claimed that the Haskell 98 Report
>> requires List.minimumBy and List.maximumBy to be lazy, but the sample
>> implementations given there use foldl1 (
>> https://www.haskell.org/onlinereport/list.html) and I can't find
>> anyplace in the report where that's explicitly said to be wrong. What am I
>> missing?
>>
>> On Thu, Oct 29, 2015 at 11:15 AM David Feuer <david.feuer at gmail.com>
>> wrote:
>>
>>> I think it would be very nice to offer a few folds tailored to specific
>>> strictness patterns. I'm not sure of the best interface, however.
>>> On Oct 29, 2015 2:07 PM, "Joachim Breitner" <mail at joachim-breitner.de>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> Am Donnerstag, den 29.10.2015, 17:34 +0200 schrieb Roman Cheplyaka:
>>>> > I just realized (thanks to this reddit thread[1]) that minimumBy is
>>>> now
>>>> > implemented through foldr1. Previously (before FTP), minimumBy from
>>>> Data.List
>>>> > used foldl1, while minimumBy from Data.Foldable used foldr1.
>>>> >
>>>> > I think that the way these were merged was a mistake.
>>>>
>>>> this has also been raised by Neil at
>>>> https://ghc.haskell.org/trac/ghc/ticket/10830
>>>>
>>>> Also note https://ghc.haskell.org/trac/ghc/ticket/3416 where it is
>>>> stated that the report demands minimum (and hence minimumBy) to be
>>>> lazy.
>>>>
>>>> Ignoring that argument, and that of not changing libraries light-
>>>> harted, I do think that foldl1' would be the better choice here; users
>>>> who rely on laziness here are likely in the minority and it would be
>>>> reasonable to expect them to manually use foldl1 or foldr1.
>>>>
>>>> BTW, why is there no fold' method in Foldable that leaves the
>>>> associativity (left, right, or mixed in case of a tree) to the Foldable
>>>> instance?
>>>>
>>>>
>>>> Greetings,
>>>> Joachim
>>>>
>>>> --
>>>> Joachim ?nomeata? Breitner
>>>>   mail at joachim-breitner.de ? http://www.joachim-breitner.de/
>>>>   Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
>>>>   Debian Developer: nomeata at debian.org
>>>>
>>>>
>>>> _______________________________________________
>>>> Libraries mailing list
>>>> Libraries at haskell.org
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>>
>>>> _______________________________________________
>>> Libraries mailing list
>>> Libraries at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>>
>
>
> --
> Regards
>
> Sumit Sahrawat
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151029/e37e0e13/attachment.html>