[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`)
mark.lentczner at gmail.com
Tue Oct 6 21:15:10 UTC 2015
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.
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>
>> 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
> * 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
> 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
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe