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

[Mark Lentczner]

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>