Breaking Changes and Long Term Support Haskell

Wed Oct 21 16:04:13 UTC 2015

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.

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 http://haskellbook.com/ 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.

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.

On Wed, Oct 21, 2015 at 10:48 AM, evan at evan-borden.com <
evan at evanrutledgeborden.dreamhosters.com> wrote:

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

-- 
Chris Allen
Currently working on http://haskellbook.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151021/a5e13a6a/attachment.html>