Re: 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`)

On Thu, Sep 24, 2015 at 2:43 PM, Herbert Valerio Riedel 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 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 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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries