[prev in list] [next in list] [prev in thread] [next in thread]
List: haskell-cafe
Subject: Re: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP (was: Monad of no `ret
From: Mike Meyer <mwm () mired ! org>
Date: 2015-10-06 23:24:15
Message-ID: CAD=7U2C0a9US=mSeko44ThXD2=xXqA5GqQgweF3wq3X98SYsYw () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Tue, Oct 6, 2015 at 4:15 PM Mark Lentczner <mark.lentczner@gmail.com>
wrote:
>
> On Thu, Sep 24, 2015 at 2:43 PM, Herbert Valerio Riedel <hvr@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?
[Attachment #5 (text/html)]
<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Oct 6, 2015 at 4:15 PM \
Mark Lentczner <<a \
href="mailto:mark.lentczner@gmail.com">mark.lentczner@gmail.com</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br>On Thu, Sep 24, \
2015 at 2:43 PM, Herbert Valerio Riedel <span dir="ltr"><<a \
href="mailto:hvr@gnu.org" target="_blank">hvr@gnu.org</a>></span> \
wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div \
style="overflow:hidden">TLDR: To complete the AMP, turn `Monad(return)` method into \
a<br> top-level binding aliasing \
`Applicative(pure)`.<br></div></blockquote><div><br></div><div>Sure... if we had a \
language that no one uses and could keep reforming like putty until it is perfect. \
But we don't.</div><div><br></div><div>A modest \
proposal:</div><div><br></div><div>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.</div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>#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?</div><div><br></div><div>#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?<br></div></div></div>
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic