<div dir="ltr">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.<div><br></div><div>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 <a href="http://haskellbook.com/">http://haskellbook.com/</a> 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.</div><div><br></div><div>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.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 21, 2015 at 10:48 AM, <a href="mailto:evan@evan-borden.com">evan@evan-borden.com</a> <span dir="ltr"><<a href="mailto:evan@evanrutledgeborden.dreamhosters.com" target="_blank">evan@evanrutledgeborden.dreamhosters.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">I'd also like to raise my concerns about an LTS solution.</p>
<p dir="ltr">#1 incremental change is far more consumable than large blocks of change. We all know the fable of python 3, perl 6, etc.</p>
<p dir="ltr">#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.</p><div class="HOEnZb"><div class="h5">
<div class="gmail_quote">On Oct 21, 2015 10:43 AM, "Geoffrey Mainland" <<a href="mailto:mainland@apeiron.net" target="_blank">mainland@apeiron.net</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 10/21/2015 07:30 AM, Simon Peyton Jones wrote:<br>
> Friends<br>
><br>
> 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:<br>
><br>
> | Proposal 2: After a suitable period of discussion on the libraries list, the<br>
> | Core Libraries Committee will summarize the arguments for and against a<br>
> | proposal and post it, along with a (justified) preliminary decision, to a<br>
> | low-traffic, announce-only email list. After another suitable period of<br>
> | discussion, they will issue a final decision. What is a suitable period of<br>
> | time? Perhaps that depends on the properties of the proposal, such as<br>
> | whether it breaks backwards compatibility.<br>
><br>
> 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.<br>
><br>
> | Personally, I think AMP was the right thing to do, but I don't think FTP was<br>
> | the right thing.<br>
><br>
> 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.<br>
><br>
> 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<br>
><br>
> * transparency;<br>
> * clarity about what decisions are on the table;<br>
> * broad consultation about decisions that affect<br>
> a broad constituency; and<br>
> * a decent opportunity to debate them without having<br>
> to be involved in massive email threads. Let's try do to that.<br>
><br>
> Simon<br>
><br>
> PS: For what it's worth I'm less keen on Geoff's other proposal:<br>
><br>
> | Proposal 3: A decision regarding any proposal that significantly affects<br>
> | backwards compatibility is within the purview of the Haskell Prime<br>
> | Committee, not the Core Libraries Committee.<br>
><br>
> *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.<br>
<br>
For the record, I am also not sure Proposal 3 is a good idea :)<br>
<br>
However, I do think we could clarify what the respective<br>
responsibilities of the core libraries committee and Haskell Prime<br>
committees are.<br>
<br>
One possible choice is that the core libraries committee is responsible<br>
for changes to the core libraries that do not affect libraries in the<br>
report. It is meant to be nimble, able to quickly deal with the large<br>
volume of library changes that do not impact backwards compatibility.<br>
<br>
In this scenario, the Haskell Prime committee, using a longer<br>
deliberative process, would consider the more impactful library changes<br>
and batch them up into new reports.<br>
<br>
You are absolutely correct that moving the question to the Haskell Prime<br>
committee risks pushing the issue around. The idea behind the separation<br>
outlined above is to reduce the treadmill; the two bodies use different<br>
processes, with different time frames, to arrive at decisions. Some<br>
library decisions may deserve a longer deliberative process.<br>
<br>
Cheers,<br>
Geoff<br>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div>
</div></div><br>_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr">Chris Allen<br><div><span style="font-size:12.8000001907349px">Currently working on </span><a href="http://haskellbook.com" target="_blank">http://haskellbook.com</a></div></div></div></div></div></div>
</div>