Re: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
91 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

RE: [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`)

Simon Peyton Jones

I think there are several different conversations going on at once in this thread.  I think it’s worth keeping them separate.

 

·         Haskell Prime.  The intention there is to take a set of language features that are already in wide use in GHC (i.e. have demonstrably proved valuable), work out any dark corners, formalise them, and embody the result in a new Haskell Report.   That puts a useful stake in the ground, empowers alternative implementations of Haskell, gives confidence all round.

 

I think it’d be unusual for the Haskell Prime committee to specify a new feature of the language, one that had not been field tested.

·         Libraries.  AMP, BBP, and Monad(return) are small but fundamental changes to the core libraries.  I think there was a consensus (not universal in the case of BBP) that the change was good.  Yet AMP and BBP (esp) were controversial.  The issues were mostly around how to make the transition; and, given that the transition is expensive, whether the cost/benefit tradeoff justifies the change.  The question of moving ‘return’ out of Monad is in this category.

The Core Libraries Committee was formed explicitly to handle this stuff. So my prior assumption was that the CLC would handle the Monad(return) question, not Haskell Prime.

 

Mark’s suggestion of a “stable” GHC 7.10 and a new GHC 8.0 is a reasonable one. But I for one would find it hard to promise to back-port every bug fix, especially as the two code bases diverge (which they will). 

 

Here is another idea.  GHC knows very little about Monad.  It would take work, but it probably wouldn’t be impossible to make the same GHC work with two different ‘base’ libraries, each with a different definitions of the Monad class.  That would not solve the problem: you still could not use one library that used old Monad with another library that used new Monad.   But at least it’d decouple it from which version of GHC you were using.  I stress: it would take some work to make this go, and I’d prefer not to do this.

 

Returning to ‘return’, my instinct is that when these pervasive breaking library changes come up, we should batch them into larger clumps.  The “treadmill” complaint is real: small change A made me re-release my library; then small change B came along; and so on.  Perhaps if we saved them up this would be less of an issue, for two reasons.  First, the work happens once rather than many times.  Second, the benefits of the change is the sum of the benefits of the little component changes, and so is more attractive to library authors and library clients.

 

That line of thinking would suggest that the Core Libraries Committee might want to maintain a list of well-worked out agreed changes that are being “saved up” for execution at some later date.

 

Simon

 

 

From: Haskell-Cafe [mailto:[hidden email]] On Behalf Of Mike Meyer
Sent: 07 October 2015 00:24
To: Mark Lentczner; Johan Tibell
Cc: Haskell Libraries; haskell cafe; [hidden email] List
Subject: Re: [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`)

 

On Tue, Oct 6, 2015 at 4:15 PM Mark Lentczner <[hidden email]> wrote:


On Thu, Sep 24, 2015 at 2:43 PM, Herbert Valerio Riedel <[hidden email]> 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?


_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

Bardur Arantsson-2
In reply to this post by José Manuel Calderón Trilla
On 10/07/2015 12:56 AM, José Manuel Calderón Trilla wrote:

> Hello all,
>
> I agree with Henrik, I'm very keen on giving the new Haskell committee a
> shot.
>
> While some may not think that Haskell2010 was a success, I think it would
> be difficult to argue that Haskell98 was anything but a resounding success
> (even if you don't think the language was what it could have been!).
> Haskell98 stabilized the constant changes of the proceeding 7 years. The
> stability brought with it books and courses, and the agreed-upon base of
> the language allowed _research_ to flourish as well. Having an agreed base
> allowed the multiple implementations to experiment with different methods
> of implementing what the standard laid out.
>

I didn't mean to be too negative about Haskell2010 -- I think
Haskell2010 *was* a success, albeit a *limited* one, but I'm doubtful
that these things can be designed by committee, especially without
prototypes. The C++ community has realized this since C++11 was
finalized and are pursuing a much more aggresive evolution of both the
language and standard libraries as a consequence -- it has practically
become a requirement to have a working prototype in at least one
compiler before a language extension/change is even considered. C++ had
been completely stagnant since 1998 and there were some disasterous
decisions as a result of design-by-committee. "template export", nuff said.

That the new Haskell' committee is being spearheaded by the
apparently-untiring HVR does inspire some confidence, but as I say...
we'll see :). I'm actually an optimist, but I've just been disappointed
soooo many times...

Regarding the textbook/course argument: Look, I think(!) I understand
what you're saying, but any serious developer these days is going to be
*used* to adapting to change. *Everything* in practical (full-stack)
development these days changes so fast that it doesn't matter whether
Monad loses "return" or not. Do you have any idea how fast frontend
(JavaScript, mainly) developers have to (and are!) adapting to change?
I'm not saying it's necessarily a good thing, but it's happening and
people are used to it. There are backwards-incompatible changes in e.g.
React almost tri-monthly[1] and yet people adapt even though this is in
a *dynamically type-checked* language! (Besides, I didn't expect
university to teach me anything practical as in "trade school". I wanted
to learn *principles* and *ideas*.)

I can also sympathize with *educators* having to adapt their course
materials and such, but I think that should be par for the course...?

Please consider that the the way practical development really happens[2]
has changed and that the argument for stability has shifted somewhat.

Regards,

Bárður

[1] A rough guesstimation of the pace. They have a deprecation period of
1 release. I have to say that Facebook are also dogfooding, I think the
0.14 release post says that they have something like 15000(!) React
components at this point.

[2] I guess I should qualify that with "... in code bases <1 MLOC", but
would that might be a bit snarky? :)


_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

Bardur Arantsson-2
On 10/07/2015 10:54 PM, Bardur Arantsson wrote:
> That the new Haskell' committee is being spearheaded by the
> apparently-untiring HVR [...]

Sorry, I should have continued: ... and hopefully joined by some
motivated, skilled and experienced individuals if the self-nominations
are anything to go by[1]. I'm a bit unclear on who gets to vote for the
nominees, but maybe I missed something. Maybe we're working towards
representative democracy here :)

Still... I remain skeptical of committees unless they delegate to
sub-committees (like "new C++" is doing).

Regards,

[1] I'm not sure who was on the old Haskell' committe, but I'm
absolutely sure the same could have been said of them.

_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

Brandon Allbery
In reply to this post by Bardur Arantsson-2

On Wed, Oct 7, 2015 at 4:54 PM, Bardur Arantsson <[hidden email]> wrote:
Please consider that the the way practical development really happens[2]

...among web developers, who of course are the only real developers?

Have you considered that there are developers who are not web developers?
The past day has convinced me that the web devs have relegated everyone else to fake-non-programmer status and actively want them out of the community because fake programmers don't benefit you real programmers.

I had heard that the financial users generally refused to have anything to do with the Haskell community.
Now I know why.

I wonder how many of them, if any indeed are left after past breaking changes, are in the process of switching to OCaml. I'm sure you consider that a good thing, because they're obviously just holding back "real programmers".

--
brandon s allbery kf8nh                               sine nomine associates
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP

Edward Kmett-2
In reply to this post by Malcolm Wallace-2


On Tue, Oct 6, 2015 at 3:02 PM, Malcolm Wallace <[hidden email]> wrote:

On 6 Oct 2015, at 17:47, Herbert Valerio Riedel wrote:
> At the risk of stating the obvious: I don't think it matters from which
> group a given argument comes from as its validity doesn't depend on the
> messenger.

In that case, I think you are misunderstanding the relevance of Johan's argument here.  Let me try to phrase it differently.  Some people who can reasonably claim to have experience with million-line plus codebases are warning that this change is too disruptive, and makes maintenance harder than it ought to be.  On the other hand, of the people who say the change is not really disruptive, none of them have (yet?) made claims to have experience of the maintenance of extremely large-scale codebases.

Very well. Let me offer a view from the "other side of the fence."

I personally maintain about 1.3 million lines of Haskell, and over 120 packages on hackage. It took me less than a half a day to get everything running with 7.10, and about two days to build -Wall clean. In that first day I actually had to spend vastly more time fixing things related to changes in Typeable, template-haskell and a tweaked corner case in the typechecker than anything AMP/FTP related. In the end I had to add two type signatures.

Most of the patches to go -Wall clean looked like

+#if __GLASGOW_HASKELL__ < 710
import Control.Applicative
import Data.Monoid
+#endif

Maybe 10% were more complicated.

-Edward

_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP

Edward Kmett-2
In reply to this post by Herbert Valerio Riedel


On Wed, Oct 7, 2015 at 3:35 AM, Herbert Valerio Riedel <[hidden email]> wrote:
--8<---------------cut here---------------start------------->8---
import Control.Applicative as A (Applicative(..))

data Maybe' a = Nothing' | Just' a

instance Functor Maybe' where
    fmap f (Just' v) = Just' (f v)
    fmap _ Nothing'  = Nothing'

instance A.Applicative Maybe' where
    pure = Just'
    f1 <*> f2   = f1 >>= \v1 -> f2 >>= (pure . v1)

instance Monad Maybe' where
    Nothing' >>= _  = Nothing'
    Just' x  >>= f  = f x

    return = pure -- "deprecated" since GHC 7.10
--8<---------------cut here---------------end--------------->8---


Alternately,

import Control.Applicative
import Prelude

data Maybe' a = Nothing' | Just' a

instance Functor Maybe' where
    fmap f (Just' v) = Just' (f v)
    fmap _ Nothing'  = Nothing'

instance Applicative Maybe' where

 
-- hvr
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime


_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP

Edward Kmett-2
In reply to this post by Gershom Bazerman
The part of the MRP proposal that I actively care about because it fixes a situation that actually causes harm is moving (>>) to the top level.

Why?

Right now (*>) and (>>) have different default definitions. This means that code runs often with different asymptotics depending on which one you pick. Folks often define one but not the other.

This means that the performance of mapM_ and traverse_ needlessly differ. It means that we can't simply weaken the type constraint on mapM_ and sequence_ to Applicative, it as a knock-on consequence it means we can't migrate mapM and sequence out of Traversable to top level definitions and thereby simply provide folks with more efficient parallelizable mapping when they reach for the 'obvious tool'.

return itself lurking in the class doesn't matter to me all that much as it doesn't break anybody's asymptotics and it already has a sensible definition in terms of pure as a default, so effectively you can write code as if MRP was already in effect today. It is a wart, but one that could be burned off on however long a time table we want if we choose to proceed.

-Edward

On Wed, Oct 7, 2015 at 5:13 PM, Mark Lentczner <[hidden email]> wrote:

On Wed, Oct 7, 2015 at 9:38 AM, Erik Hesselink <[hidden email]> wrote:
While I don't think it detracts from your argument, it seems you
misread the original proposal. At no point will it remove `return`
completely. It would be moved out of the `Monad` class and be made
into a top-level definition instead, so you would still be able to use
it.

Then why bother?
If you don't intend to regard code that uses "return" as old, out-dated, in need of updating, etc....
If you don't intend to correct people on #haskell to use pure instead of return...
If you don't tsk tsk all mentions of it in books.... 
If you don't intend to actually deprecate it.
Why bother?

But seriously, why do you think that "you would still be able to use it"? That is true for only the simplest of code - and untrue for anyone who has a library that defines a Monad - or anyone who has a library that they want to keep "up to date". Do you really want to have a library where all your "how to use this" code has return in the examples? Shouldn't now be pure? Do I now need -XCPP just for Haddock? and my wiki page? And what gets shown in Hackage? This is just a nightmare for a huge number of libraries, and especially many commonly used ones.

Why bother!


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries



_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP

Edward Kmett-2
In reply to this post by Sven Panne-2
On Tue, Oct 6, 2015 at 1:41 PM, Sven Panne <[hidden email]> wrote:
2015-10-06 18:47 GMT+02:00 Herbert Valerio Riedel <[hidden email]>:
[...] That's because -Wall-hygiene (w/o opting out of harmless) warnings
across multiple GHC versions is not considered a show-stopper.

That's your personal POV, I'm more leaning towards "-Wall -Werror". I've seen too many projects where neglecting warning over an extended period of time made fixing them basically impossible at the end. Anyway, I think that a sane ecosystem should allow *both* POVs, the sloppy one and the strict one.

Note: You haven't been able to upload a package that has -Werror turned on in the cabal file for a couple of years now -- even if it is only turned on on the test suite, so any -Werror discipline you choose to enforce is purely local.

-Edward

_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP

Yuras Shumovich
In reply to this post by Edward Kmett-2
On Sat, 2015-10-10 at 15:25 -0400, Edward Kmett wrote:
> The part of the MRP proposal that I actively care about because it
> fixes a
> situation that *actually causes harm* is moving (>>) to the top
> level.

Sorry if I'm missing something, but moving (>>) is not part of the
proposal. At least it is not mentioned on the wiki page:

https://ghc.haskell.org/trac/ghc/wiki/Proposal/MonadOfNoReturn

Is the wiki outdated?

> return itself lurking in the class doesn't matter to me all that much
> as it
> doesn't break anybody's asymptotics and it already has a sensible
> definition in terms of pure as a default, so effectively you can
> write code
> as if MRP was already in effect today. It is a wart, but one that
> could be
> burned off on however long a time table we want if we choose to
> proceed.

So the cost of not moving `return` to the top level is zero?

For me the cost of moving it is pretty small, just an hour or two.
Probably recompiling all the dependencies when switching to newer
version of GHC will take longer. (Actually I'm still using 7.8 at
work.) But the cost is definitely nonzero.

The proposal (as written on the wiki page) provides two arguments for
the change:

There is no reason to include `return` into the next standard. That is
true. But we can leave `return` is `GHC` as a compiler specific
extension for backward compatibility, can't we?

The second argument is `ApplicativeDo`, but I don't see the point.
Breaking existing code "in order to benefit existing code" looks a bit
strange.

Could someone please clarify what is the cost of not moving `return`
out of `Monad`?

Sorry if it is already answered somewhere else, it is hard to find
anything in such the huge email thread.

Thanks,
Yuras.

_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP

Edward Kmett-2
On Sat, Oct 10, 2015 at 4:12 PM, Yuras Shumovich <[hidden email]> wrote:
On Sat, 2015-10-10 at 15:25 -0400, Edward Kmett wrote:
> The part of the MRP proposal that I actively care about because it
> fixes a
> situation that *actually causes harm* is moving (>>) to the top
> level.

Sorry if I'm missing something, but moving (>>) is not part of the
proposal. At least it is not mentioned on the wiki page:

https://ghc.haskell.org/trac/ghc/wiki/Proposal/MonadOfNoReturn

Is the wiki outdated?

It arose during the original thread discussing the MRP but wasn't included in the 'proposal as written' that was sent out.


In many ways that proposal would do better 'on its own' than as part of the MRP.

> return itself lurking in the class doesn't matter to me all that much
> as it
> doesn't break anybody's asymptotics and it already has a sensible
> definition in terms of pure as a default, so effectively you can
> write code
> as if MRP was already in effect today. It is a wart, but one that
> could be
> burned off on however long a time table we want if we choose to
> proceed.

So the cost of not moving `return` to the top level is zero?

For me the cost of moving it is pretty small, just an hour or two.
Probably recompiling all the dependencies when switching to newer
version of GHC will take longer. (Actually I'm still using 7.8 at
work.) But the cost is definitely nonzero.

The proposal (as written on the wiki page) provides two arguments for
the change:

There is no reason to include `return` into the next standard. That is
true.

Nobody is saying that we should remove return from the language. The proposal was to move it out of the class -- eventually. Potentially on a very very long time line.

But we can leave `return` is `GHC` as a compiler specific extension for backward compatibility, can't we?

This is effectively the status quo. There is a default definition of return in terms of pure today. The longer we wait the more tenable this proposal gets in many ways as fewer and fewer people start trying to support compilers versions below 7.10. Today isn't that day.

There are some niggling corner cases around viewing its continued existence as a compiler "extension" though, even just around the behavior when you import the class with Monad(..) you get more or less than you'd expect.

Could someone please clarify what is the cost of not moving `return` out of `Monad`?

The cost of doing nothing is maintaining a completely redundant member inside the class for all time and an ever-so-slightly more expensive dictionaries for Monad, so retaining return in the class does no real harm operationally. 

While I'm personally somewhat in favor of its eventual migration on correctness grounds and believe it'd be nice to be able to justify the state of the world as more than a series of historical accidents when I put on my libraries committee hat I have concerns. 

I'm inclined to say at the least that IF we do decide to proceed on this, at least the return component should be on a long time horizon, with a clock tied to the release of a standard, say a Haskell2020. I stress IF, because I haven't had a chance to go through and do any sort of detailed tally or poll to get a sense of if there is a sufficient mandate. There is enough of a ruckus being raised that it is worth proceeding cautiously if we proceed at all.

-Edward

_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP

Yuras Shumovich
On Sat, 2015-10-10 at 16:39 -0400, Edward Kmett wrote:

> On Sat, Oct 10, 2015 at 4:12 PM, Yuras Shumovich <
> [hidden email]>
> wrote:
>
> > There is no reason to include `return` into the next standard. That
> > is
> > true.
>
>
> Nobody is saying that we should remove return from the language. The
> proposal was to move it out of the class -- eventually. Potentially
> on a
> very very long time line.

Yes, I meant there were no reason to include `return` into `Monad`
class in the next standard.


> There are some niggling corner cases around viewing its continued
> existence
> as a compiler "extension" though, even just around the behavior when
> you
> import the class with Monad(..) you get more or less than you'd
> expect.

Indeed that is a good argument.


> The cost of doing nothing is maintaining a completely redundant
> member
> inside the class for all time

Well, it is just a single line of code. Of course, as any other
technical dept, it can beat you later, e.g. it can make some other
modification harder. But in the worst case it will cost one more
deprecation circle.


> and an ever-so-slightly more expensive
> dictionaries for Monad

Do you mean that moving `return` to the top level will give us
noticeable performance improvement?


> so retaining return in the class does no real harm
> operationally.

IMO that is the reason for the "ruckus".


Thank you for the detailed answer.

Yuras


>
> While I'm personally somewhat in favor of its eventual migration on
> correctness grounds and believe it'd be nice to be able to justify
> the
> state of the world as more than a series of historical accidents when
> I put
> on my libraries committee hat I have concerns.
>
> I'm inclined to say at the least that IF we do decide to proceed on
> this,
> at least the return component should be on a long time horizon, with
> a
> clock tied to the release of a standard, say a Haskell2020. I stress
> IF,
> because I haven't had a chance to go through and do any sort of
> detailed
> tally or poll to get a sense of if there is a sufficient mandate.
> There is
> enough of a ruckus being raised that it is worth proceeding
> cautiously if
> we proceed at all.
>
> -Edward
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: [Haskell-cafe] Haskell ecosystem improvements meta-propsal

Alan & Kim Zimmerman
In reply to this post by Gershom Bazerman
Here is another example of a language change RFC process

https://github.com/rust-lang/rfcs

Alan

On Wed, Oct 7, 2015 at 9:21 AM, Mike Meyer <[hidden email]> wrote:
On Wed, Oct 7, 2015 at 1:45 AM Mark Lentczner <[hidden email]> wrote:
On Tue, Oct 6, 2015 at 7:24 PM, Mike Meyer <[hidden email]> wrote:
I've dealt with the IETF RFC process and the Python PEP process, and both of them worked better than that.

While both those are good examples of mostly working organizations shepherding foundational technical standard(s) along... there is one thing more important than their processes: Their stance. Both organizations have a very strong engineering discipline of keeping deployed things working without change. I don't think it is enough to simply model their process.

Well, until Python 3, anyway.

My goal wasn't to recreate the engineering discipline that deployed things keep working without change as you upgrade the ecosystem, it's to provide a mechanism so the community can more easily engage with the evolution of the ecosystem. Hopefully this will make it easier for the community to move things forward in a desirable manner. But it's a process, and leaves the question of whether the desire is for more stability or a less stagnant language up to the users of the process.

I don't necessarily want to model the IETF or PEP processes. Those are a starting point. I tried to abstract the initial points out enough that the final result could be either one of them, or something totally unrelated that's a better fit for the Haskell community.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe



_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

Henrik Nilsson-2
In reply to this post by Bryan O'Sullivan
Hi all,

Geoffrey Mainland wrote;

 > What worries me most is that we have started to see very valuable
 > members of our community publicly state that they are reducing their
 > community involvement.

That worries me too. A lot. To quote myself from an earlier
e-mail in this thread:

 > Therefore, please let us defer further discussion and
 > ultimate decision on MRP to the resurrected
 > HaskellPrime committee, which is where it properly
 > belongs. Otherwise, the Haskell community itself might
 > be one of the things that MRP breaks.

Geoffrey further wrote:

 > 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.

I thus definitely support this, at least for anything related to
the libraries covered by the Haskell report.

Indeed, I strongly suspect that many people who did not actively
follow the libraries discussions did so because they simply did not
think that changes to the central libraries as defined in the Haskell
report, at least not breaking changes, were in the remit of the
libraries committee, and were happy to leave discussions on any
other libraries to the users of those libraries. And as a consequence
they were taken by surprise by AMP etc.

So before breaking anything more, that being code, research papers,
books, what people have learned, or even the community itself, it is
time to very carefully think about what the appropriate processes
should be for going forward.

Best,

/Henrik

--
Henrik Nilsson
School of Computer Science
The University of Nottingham
[hidden email]




This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it.

Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.

_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

RE: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

Augustsson, Lennart
I'd say, of course, libraries covered by the Haskell report are not in the remit of the libraries committee.

-----Original Message-----
From: Libraries [mailto:[hidden email]] On Behalf Of Henrik Nilsson
Sent: 21 October 2015 09:25
To: Geoffrey Mainland; Bryan O'Sullivan; Gershom B
Cc: [hidden email]; [hidden email] List; Graham Hutton; Haskell Libraries; haskell cafe
Subject: Re: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

Hi all,

Geoffrey Mainland wrote;

 > What worries me most is that we have started to see very valuable  > members of our community publicly state that they are reducing their  > community involvement.

That worries me too. A lot. To quote myself from an earlier e-mail in this thread:

 > Therefore, please let us defer further discussion and  > ultimate decision on MRP to the resurrected  > HaskellPrime committee, which is where it properly  > belongs. Otherwise, the Haskell community itself might  > be one of the things that MRP breaks.

Geoffrey further wrote:

 > 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.

I thus definitely support this, at least for anything related to the libraries covered by the Haskell report.

Indeed, I strongly suspect that many people who did not actively follow the libraries discussions did so because they simply did not think that changes to the central libraries as defined in the Haskell report, at least not breaking changes, were in the remit of the libraries committee, and were happy to leave discussions on any other libraries to the users of those libraries. And as a consequence they were taken by surprise by AMP etc.

So before breaking anything more, that being code, research papers, books, what people have learned, or even the community itself, it is time to very carefully think about what the appropriate processes should be for going forward.

Best,

/Henrik

--
Henrik Nilsson
School of Computer Science
The University of Nottingham
[hidden email]




This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it.

Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at http://www.standardchartered.com/en/incorporation-details.html

Insofar as this communication contains any market commentary, the market commentary has been prepared by sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied for any other purpose, and is subject to the relevant disclaimers available at http://wholesalebanking.standardchartered.com/en/utility/Pages/d-mkt.aspx

Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign on the term sheet to acknowledge in respect of the same.

Please visit http://wholesalebanking.standardchartered.com/en/capabilities/financialmarkets/Pages/doddfrankdisclosures.aspx for important information with respect to derivative products.
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: Breaking Changes and Long Term Support Haskell

Henrik Nilsson-2
In reply to this post by Henrik Nilsson-2
Hi all,

Jeremy wrote:

 > There seems to be a fair amount of friction between those who want to
 > introduce new features or fix significant historical warts in the base
 > libraries - even if this requires breaking changes - and those who
 > insist on no significant breaking changes in new releases, regardless
 > of the reason or how much warning was given.

With respect, and without commenting on the merits of the proposal that
is then outlined (Long-Term Support Haskell), I don't think this is
an accurate description of the two main positions in the debate at all.

Most of those who have argued against MRP, for example, have made it
very clear that they are not at all against any breaking change. But
they oppose breaking changes to Haskell itself, including central
libraries, as defined by the Haskell report, unless the benefits are
very compelling indeed.

Speaking for myself, I have had to clarify this position a number
of times now, as there has been a tendency by the some proponents of
the proposed changes to suggest that those who disagree are against
all changes, the long term implication being that Haskell would
"stagnate and die".

And in the light of the above, I felt compelled to clarify this
position again.

It's not about no more changes ever. It is about ensuring that
changes are truly worthwhile and have wide support.

Best,

/Henrik

--
Henrik Nilsson
School of Computer Science
The University of Nottingham
[hidden email]




This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it.

Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.

_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

RE: Breaking Changes and Long Term Support Haskell

Augustsson, Lennart
I'd like to vehemently agree with Henrik here. :)

Personally, I think AMP was the right thing to do, but I don't think FTP was the right thing.
And I don't think changes that break code are necessarily bad either, just some of them.

(To clarify, I'm against the Foldable class, but not Traversable.  It would have been quite feasible to have the latter, but not the former.)

  -- Lennart


-----Original Message-----
From: Haskell-prime [mailto:[hidden email]] On Behalf Of Henrik Nilsson
Sent: 21 October 2015 11:17
To: [hidden email] List; Haskell Libraries
Subject: Re: Breaking Changes and Long Term Support Haskell

Hi all,

Jeremy wrote:

 > There seems to be a fair amount of friction between those who want to  > introduce new features or fix significant historical warts in the base  > libraries - even if this requires breaking changes - and those who  > insist on no significant breaking changes in new releases, regardless  > of the reason or how much warning was given.

With respect, and without commenting on the merits of the proposal that is then outlined (Long-Term Support Haskell), I don't think this is an accurate description of the two main positions in the debate at all.

Most of those who have argued against MRP, for example, have made it very clear that they are not at all against any breaking change. But they oppose breaking changes to Haskell itself, including central libraries, as defined by the Haskell report, unless the benefits are very compelling indeed.

Speaking for myself, I have had to clarify this position a number of times now, as there has been a tendency by the some proponents of the proposed changes to suggest that those who disagree are against all changes, the long term implication being that Haskell would "stagnate and die".

And in the light of the above, I felt compelled to clarify this position again.

It's not about no more changes ever. It is about ensuring that changes are truly worthwhile and have wide support.

Best,

/Henrik

--
Henrik Nilsson
School of Computer Science
The University of Nottingham
[hidden email]




This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it.

Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.

_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at http://www.standardchartered.com/en/incorporation-details.html

Insofar as this communication contains any market commentary, the market commentary has been prepared by sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied for any other purpose, and is subject to the relevant disclaimers available at http://wholesalebanking.standardchartered.com/en/utility/Pages/d-mkt.aspx

Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign on the term sheet to acknowledge in respect of the same.

Please visit http://wholesalebanking.standardchartered.com/en/capabilities/financialmarkets/Pages/doddfrankdisclosures.aspx for important information with respect to derivative products.
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

RE: Breaking Changes and Long Term Support Haskell

Simon Peyton Jones
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.
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Committee M.O. Change Proposals (was: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`)

Herbert Valerio Riedel-3
In reply to this post by Bryan O'Sullivan
Hello,

On 2015-10-21 at 02:39:57 +0200, Geoffrey Mainland wrote:

[...]

> In effect, only those who actively follow the libraries list have had a
> voice in these decisions. Maybe that is what the community wants. I hope
> not. How then can people like me (and Henrik and Graham) have a say
> without committing to actively following the libraries list?
>  
> We have a method to solve this: elected representatives. Right now the
> Core Libraries Committee elects its own members; perhaps it is time for
> that to change.

[...]

> Proposal 1: Move to community election of the members of the Core
> Libraries Committee. Yes, I know this would have its own issues.

How exactly do public elections of representatives address the problem
that some people feel left out? Have you considered nominating yourself
or somebody else you have confidence in for the core libraries
committee? You'd still have to find somebody to represent your
interests, regardless of whether the committee is self-elected or
direct-elected.

Here's some food for thought regarding language design by voting or its
indirect form via a directly elected language committee:

Back in February there was a large-scale survey which resulted (see [2]
for more details) in a rather unequivocal 4:1 majority *for* going
through with the otherwise controversial FTP implementation. If the
community elections would result in a similar spirit, you'd could easily
end up with a similarly 4:1 pro-change biased committee. Would you
consider that a well balanced committee formation?

> 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.

That generally sounds like a good compromise, if this actually helps
reaching the otherwise unreachable parts of the community and have their
voices heard.

> 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.

I don't see how that would change much. The prior Haskell Prime
Committee has been traditionally self-elected as well. So it's just the
label of the committee you'd swap out.

In the recent call of nominations[1] for Haskell Prime, the stated area
of work for the new nominations was to take care of the *language* part,
because that's what we are lacking the workforce for.

Since its creation for the very purpose of watching over the core
libraries, the core-libraries-committee has been almost exclusively busy
with evaluating and deciding about changes to the `base` library and
overseeing their implementation. Transferring this huge workload to the
new Haskell Prime committee members who have already their hands full
with revising the language part would IMO just achieve to reduce the
effectiveness of the upcoming Haskell Prime committee, and therefore
increase the risk of failure in producing an adequate new Haskell Report
revision.

Regards,
  H.V.Riedel

 [1]: https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html
 [2]: https://mail.haskell.org/pipermail/haskell-cafe/2015-February/118336.html
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: Committee M.O. Change Proposals

Geoffrey Mainland
On 10/21/2015 07:55 AM, Herbert Valerio Riedel wrote:
> Hello, > > On 2015-10-21 at 02:39:57 +0200, Geoffrey Mainland wrote: > > [...]
> >> In effect, only those who actively follow the libraries list have
had a >> voice in these decisions. Maybe that is what the community
wants. I hope >> not. How then can people like me (and Henrik and
Graham) have a say >> without committing to actively following the
libraries list? >>  >> We have a method to solve this: elected
representatives. Right now the >> Core Libraries Committee elects its
own members; perhaps it is time for >> that to change. > > [...] > >>
Proposal 1: Move to community election of the members of the Core >>
Libraries Committee. Yes, I know this would have its own issues. > > How
exactly do public elections of representatives address the problem >
that some people feel left out? Have you considered nominating yourself
> or somebody else you have confidence in for the core libraries >
committee? You'd still have to find somebody to represent your >
interests, regardless of whether the committee is self-elected or >
direct-elected. > > Here's some food for thought regarding language
design by voting or its > indirect form via a directly elected language
committee: > > Back in February there was a large-scale survey which
resulted (see [2] > for more details) in a rather unequivocal 4:1
majority *for* going > through with the otherwise controversial FTP
implementation. If the > community elections would result in a similar
spirit, you'd could easily > end up with a similarly 4:1 pro-change
biased committee. Would you > consider that a well balanced committee
formation?

Thanks, all good points.

It is quite possible that direct elections would produce the exact same
committee. I wouldn't see that as a negative outcome at all! At least
that committee would have been put in place by direct election; I would
see that as strengthening their mandate.

I am very much aware of the February survey. I wonder if Proposal 2, had
it been in place at the time, would have increased participation in the
survey.

The recent kerfuffle has caught the attention of many people who don't
normally follow the libraries list. Proposal 1 is an attempt to give
them a voice. Yes, they would still need to find a candidate to
represent their interests. If we moved to direct elections, I would
consider running. However, my preference is that Proposal 3 go through
in some form, in which case my main concern would be the Haskell Prime
committee, and unfortunately nominations for that committee have already
closed.

>> 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. > >
That generally sounds like a good compromise, if this actually helps >
reaching the otherwise unreachable parts of the community and have their
> voices heard.

My hope is that a low-volume mailing list would indeed reach a wider
audience.

>> 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. > > I don't see how that
would change much. The prior Haskell Prime > Committee has been
traditionally self-elected as well. So it's just the > label of the
committee you'd swap out. > > In the recent call of nominations[1] for
Haskell Prime, the stated area > of work for the new nominations was to
take care of the *language* part, > because that's what we are lacking
the workforce for. > > Since its creation for the very purpose of
watching over the core > libraries, the core-libraries-committee has
been almost exclusively busy > with evaluating and deciding about
changes to the `base` library and > overseeing their implementation.
Transferring this huge workload to the > new Haskell Prime committee
members who have already their hands full > with revising the language
part would IMO just achieve to reduce the > effectiveness of the
upcoming Haskell Prime committee, and therefore > increase the risk of
failure in producing an adequate new Haskell Report > revision.

My understanding is that much of the work of the core libraries
committee does not "significantly affect backwards compatibility," at
least not to the extent that MRP does. If this is the case, the bulk of
their workload would not be transferred to the new Haskell Prime
committee. Is my understanding incorrect?

The intent of Proposal 3 was to transfer only a small fraction of the
issues that come before the core libraries committee to the Haskell
Prime committee. In any case, we would certainly need to clarify what
"significantly affects backwards compatibility" means.

Perhaps we should consider direct elections for the Haskell Prime
committee as well as changing their mandate to include some subset of
the changes proposed to libraries covered by the Haskell Report. My
understanding of the current state of affairs is that the Haskell Prime
committee is charged with producing a new report, but the core libraries
committee is in charge of the library part of that report. Is that
correct?

Cheers,
Geoff

> Regards, >   H.V.Riedel > >  [1]:
https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html
>  [2]:
https://mail.haskell.org/pipermail/haskell-cafe/2015-February/118336.html


_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: Committee M.O. Change Proposals

Geoffrey Mainland
In reply to this post by Herbert Valerio Riedel-3
Apologies for the previous mailer-mangled "draft"...

On 10/21/2015 07:55 AM, Herbert Valerio Riedel wrote:

> Hello,
>
> On 2015-10-21 at 02:39:57 +0200, Geoffrey Mainland wrote:
>
> [...]
>
>> In effect, only those who actively follow the libraries list have had a
>> voice in these decisions. Maybe that is what the community wants. I hope
>> not. How then can people like me (and Henrik and Graham) have a say
>> without committing to actively following the libraries list?
>>  
>> We have a method to solve this: elected representatives. Right now the
>> Core Libraries Committee elects its own members; perhaps it is time for
>> that to change.
> [...]
>
>> Proposal 1: Move to community election of the members of the Core
>> Libraries Committee. Yes, I know this would have its own issues.
> How exactly do public elections of representatives address the problem
> that some people feel left out? Have you considered nominating yourself
> or somebody else you have confidence in for the core libraries
> committee? You'd still have to find somebody to represent your
> interests, regardless of whether the committee is self-elected or
> direct-elected.
>
> Here's some food for thought regarding language design by voting or its
> indirect form via a directly elected language committee:
>
> Back in February there was a large-scale survey which resulted (see [2]
> for more details) in a rather unequivocal 4:1 majority *for* going
> through with the otherwise controversial FTP implementation. If the
> community elections would result in a similar spirit, you'd could easily
> end up with a similarly 4:1 pro-change biased committee. Would you
> consider that a well balanced committee formation?

Thanks, all good points.

It is quite possible that direct elections would produce the exact same
committee. I wouldn't see that as a negative outcome at all! At least
that committee would have been put in place by direct election; I would
see that as strengthening their mandate.

I am very much aware of the February survey. I wonder if Proposal 2, had
it been in place at the time, would have increased participation in the
survey.

The recent kerfuffle has caught the attention of many people who don't
normally follow the libraries list. Proposal 1 is an attempt to give
them a voice. Yes, they would still need to find a candidate to
represent their interests. If we moved to direct elections, I would
consider running. However, my preference is that Proposal 3 go through
in some form, in which case my main concern would be the Haskell Prime
committee, and unfortunately nominations for that committee have already
closed.

>> 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.
> That generally sounds like a good compromise, if this actually helps
> reaching the otherwise unreachable parts of the community and have their
> voices heard.

My hope is that a low-volume mailing list would indeed reach a wider
audience.

>> 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.
> I don't see how that would change much. The prior Haskell Prime
> Committee has been traditionally self-elected as well. So it's just the
> label of the committee you'd swap out.
>
> In the recent call of nominations[1] for Haskell Prime, the stated area
> of work for the new nominations was to take care of the *language* part,
> because that's what we are lacking the workforce for.
>
> Since its creation for the very purpose of watching over the core
> libraries, the core-libraries-committee has been almost exclusively busy
> with evaluating and deciding about changes to the `base` library and
> overseeing their implementation. Transferring this huge workload to the
> new Haskell Prime committee members who have already their hands full
> with revising the language part would IMO just achieve to reduce the
> effectiveness of the upcoming Haskell Prime committee, and therefore
> increase the risk of failure in producing an adequate new Haskell Report
> revision.

My understanding is that much of the work of the core libraries
committee does not "significantly affect backwards compatibility," at
least not to the extent that MRP does. If this is the case, the bulk of
their workload would not be transferred to the new Haskell Prime
committee. Is my understanding incorrect?

The intent of Proposal 3 was to transfer only a small fraction of the
issues that come before the core libraries committee to the Haskell
Prime committee. In any case, we would certainly need to clarify what
"significantly affects backwards compatibility" means.

Perhaps we should consider direct elections for the Haskell Prime
committee as well as changing their mandate to include some subset of
the changes proposed to libraries covered by the Haskell Report. My
understanding of the current state of affairs is that the Haskell Prime
committee is charged with producing a new report, but the core libraries
committee is in charge of the library part of that report. Is that correct?

Cheers,
Geoff

> Regards,
>   H.V.Riedel
>
>  [1]: https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html
>  [2]: https://mail.haskell.org/pipermail/haskell-cafe/2015-February/118336.html
>

_______________________________________________
Haskell-prime mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
12345