Quo vadis?

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

Quo vadis?

Mario Blažević-3
I could not attend ICFP this year. Has there been any discussion at all
of Haskell 2020 there? If so, can the rest of us get a summary?



_______________________________________________
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: Quo vadis?

Richard Eisenberg-4
There was no Haskell 2020 meeting this year at ICFP. Sadly, interest seems to have waned here...

Richard

> On Sep 26, 2018, at 8:18 AM, Mario Blažević <[hidden email]> wrote:
>
> I could not attend ICFP this year. Has there been any discussion at all of Haskell 2020 there? If so, can the rest of us get a summary?
>
>
>
> _______________________________________________
> 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: Quo vadis?

AntC
In reply to this post by Mario Blažević-3
There was no Haskell 2020 meeting this year at ICFP. Sadly, interest seems to have waned here...

Yes that is sad. So either Haskell 2020 won't happen, or it'll be only minor tweaks over H2010, as that was over H98.

It's hard to imagine any serious Haskelling without FlexibleInstances/FlexibleContexts, MultiParamTypeClasses, UndecidableInstances -- and yet all of those are beyond Haskell 2010. And they were available in at least 2 compilers by around 2000. (Possibly they weren't by then entirely polished. I saw a claim on a StackOverflow answer that Hugs, last release 2006, is not H2010 compliant: not true; indeed several of the H2010 changes since H98 were proposed by the Hugs dev team, and agreed by the GHC team because GHC had copied Hugs.)

I've had comments from non-Haskellers that they won't take Haskell seriously, because it seems to be a bunch of 'risky'/unstable/experimental features. Whereas I know those features have been stable at least a dozen years. And yet we still face the same conundrums as did H2010:

With FlexibleInstances we can write overlapping instances. With FlexibleContexts we can put overlapping constraints on an instance, even if the head's types are H98 (non-Flexible).

With MultiParamTypeClasses (which were anticipated in Wadler's very earliest 1988 proposal for typeclasses) we're bound to choose FunDeps and/or type families. FunDep instances either need repeated tyvars -- which brings us straight back to FlexibleInstances, or UndecidableInstances -- which will almost certainly lead to FlexibleInstances somewhere.

I feel those parts of Haskell have been in suspended animation/arrested development since ~2006: that was the last release of Hugs; the 'FunDeps via CHRs' paper [**]; the start of associated types/type families.

[**] AFAICT, that paper was a purely academic exercise: GHC was not changed in light of its findings, so has a bogus implementation of FunDeps that persists to this day. The paper did not address the combo of FunDeps + Overlaps, so said nothing about what had been a stable cottage industry of type-level programming since at least 2004 (the HList paper).

Is there a terms of ref for Haskell 2020? Would any of the above issues be within its scope? (Supposing there were any interest ...)


AntC

_______________________________________________
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: Quo vadis?

Mario Blažević-3
On 2018-10-04 09:41 PM, Anthony Clayden wrote:
> > There was no Haskell 2020 meeting this year at ICFP. Sadly, interest
> seems to have waned here...
> Yes that is sad. So either Haskell 2020 won't happen, or it'll be only
> minor tweaks over H2010, as that was over H98.

The former seems much more likely, judging by the pace so far.

     I hereby propose we formally disband the present Haskell 2020
committee. Our performance has been so dismal that I feel this is the
only course of action that gives Haskell 2020 any chance of fruition. A
new committee could then be formed with some more dedicated membership.

_______________________________________________
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: Quo vadis?

Henrik Nilsson-2
Hi,

On 10/05/2018 01:20 PM, Mario Blažević wrote:
>      I hereby propose we formally disband the present Haskell 2020
> committee. Our performance has been so dismal

It has.

And I should apologise in particular: I've just had far less time than
I thought over the past year for a variety of reasons.

> that I feel this is the
> only course of action that gives Haskell 2020 any chance of fruition. A
> new committee could then be formed with some more dedicated membership.

I'm less convinced about that, though. I believe those who signed up
for H2020 actually are people who believe in the value of an updated
standard and has core expertise to make it happen. I can't see how
giving up and forming a new group would speed things up or even
increase the chance of success.

Instead, what about focusing on identifying a couple of things that
absolutely would have to be in H2020 to make a new standard
worthwhile, like multi-parameter type classes, possibly GADTs,
then figure out what else is needed to support that (like what
Anthony Clayden sketched), and with that as a basis, find out
exactly what technical problems, if any, are hindering progress?

If this could be neatly summarized, then we'd actually be in a position
to make some progress.

/Henrik






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 contact the sender and delete the email and
attachment.

Any views or opinions expressed by the author of this email do not
necessarily reflect the views of the University of Nottingham. Email
communications with the University of Nottingham may be monitored
where permitted by law.




_______________________________________________
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: Quo vadis?

Mario Blažević-3
On 2018-10-05 09:10 AM, Henrik Nilsson wrote:

> Hi,
>
> On 10/05/2018 01:20 PM, Mario Blažević wrote:
>>      I hereby propose we formally disband the present Haskell 2020
>> committee. Our performance has been so dismal
>
> It has.
>
> And I should apologise in particular: I've just had far less time than
> I thought over the past year for a variety of reasons.
>
>> that I feel this is the
>> only course of action that gives Haskell 2020 any chance of fruition. A
>> new committee could then be formed with some more dedicated membership.
>
> I'm less convinced about that, though. I believe those who signed up
> for H2020 actually are people who believe in the value of an updated
> standard and has core expertise to make it happen.

     Regarding the beliefs, if we really represent the most zealous
group of Haskell enthusiasts, I have to say the community is in deep
trouble. I have no evidence, but I can only hope you're wrong.

     As for the expertise, my impression is that *everybody* who
self-nominated for the committee got accepted. My own self-nomination
e-mail [1] explicitly said that


> The main reason I'm applying is because I'm afraid that the commitee
> might disband like the previous one. If there are enough members
> already, feel free to ignore my nomination.

Yet I'm in. This was not a high bar to clear.


> I can't see how giving up and forming a new group would speed things
> up or even
> increase the chance of success.

     I was kinda hoping for a Simon ex machina, where a few
universally-accepted members of the community hand-pick a new committee.
Alternatively, we could come up with some stricter criteria for the next
committee before we disband but that assumes we can even get a quorum.

     Lest I'm suspected of some Machiavellian plot, let me be clear that
I refuse to be a part of the next committee, if my proposal should be
accepted. Honestly I feel that all members of the present committee with
any sense of shame should recuse themselves as well, but that's not up
to me.


> Instead, what about focusing on identifying a couple of things that
> absolutely would have to be in H2020 to make a new standard
> worthwhile, like multi-parameter type classes, possibly GADTs,
> then figure out what else is needed to support that (like what
> Anthony Clayden sketched), and with that as a basis, find out
> exactly what technical problems, if any, are hindering progress?
>
> If this could be neatly summarized, then we'd actually be in a position
> to make some progress.

     That is much the plan we agreed on over a year ago during ICFP
2018. The activity since then is plain to see.


[1]
http://mail.haskell.org/pipermail/haskell-prime/2015-September/003939.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: Quo vadis?

Haskell - Haskell-prime mailing list
I think the difficulty has always been in finding enough people who are

* Well-informed and well-qualified
* Willing to spend the time to standardise language features

GHC does not help the situation: it's a de-facto standard, which reduces the incentives to spend time in standardisation.

I don’t think we should blame anyone for not wanting to invest this time -- no shame here.  It is a very significant commitment, as I know from editing the Haskell 98 report and the incentives are weak.  Because of that, I am not very optimistic about finding such a group -- we have been abortively trying for several years.

If we want to change that, the first thing is to build a case that greater standardisation is not just an "abstract good" that we all subscribe to, but something whose lack is holding us back.

Simon

|  -----Original Message-----
|  From: Haskell-prime <[hidden email]> On Behalf Of
|  Mario Blaževic
|  Sent: 05 October 2018 17:47
|  To: [hidden email]
|  Subject: Re: Quo vadis?
|  
|  On 2018-10-05 09:10 AM, Henrik Nilsson wrote:
|  > Hi,
|  >
|  > On 10/05/2018 01:20 PM, Mario Blažević wrote:
|  >>      I hereby propose we formally disband the present Haskell 2020
|  >> committee. Our performance has been so dismal
|  >
|  > It has.
|  >
|  > And I should apologise in particular: I've just had far less time than
|  > I thought over the past year for a variety of reasons.
|  >
|  >> that I feel this is the
|  >> only course of action that gives Haskell 2020 any chance of fruition.
|  >> A new committee could then be formed with some more dedicated
|  membership.
|  >
|  > I'm less convinced about that, though. I believe those who signed up
|  > for H2020 actually are people who believe in the value of an updated
|  > standard and has core expertise to make it happen.
|  
|       Regarding the beliefs, if we really represent the most zealous group
|  of Haskell enthusiasts, I have to say the community is in deep trouble. I
|  have no evidence, but I can only hope you're wrong.
|  
|       As for the expertise, my impression is that *everybody* who self-
|  nominated for the committee got accepted. My own self-nomination e-mail
|  [1] explicitly said that
|  
|  
|  > The main reason I'm applying is because I'm afraid that the commitee
|  > might disband like the previous one. If there are enough members
|  > already, feel free to ignore my nomination.
|  
|  Yet I'm in. This was not a high bar to clear.
|  
|  
|  > I can't see how giving up and forming a new group would speed things
|  > up or even increase the chance of success.
|  
|       I was kinda hoping for a Simon ex machina, where a few universally-
|  accepted members of the community hand-pick a new committee.
|  Alternatively, we could come up with some stricter criteria for the next
|  committee before we disband but that assumes we can even get a quorum.
|  
|       Lest I'm suspected of some Machiavellian plot, let me be clear that
|  I refuse to be a part of the next committee, if my proposal should be
|  accepted. Honestly I feel that all members of the present committee with
|  any sense of shame should recuse themselves as well, but that's not up to
|  me.
|  
|  
|  > Instead, what about focusing on identifying a couple of things that
|  > absolutely would have to be in H2020 to make a new standard
|  > worthwhile, like multi-parameter type classes, possibly GADTs, then
|  > figure out what else is needed to support that (like what Anthony
|  > Clayden sketched), and with that as a basis, find out exactly what
|  > technical problems, if any, are hindering progress?
|  >
|  > If this could be neatly summarized, then we'd actually be in a
|  > position to make some progress.
|  
|       That is much the plan we agreed on over a year ago during ICFP 2018.
|  The activity since then is plain to see.
|  
|  
|  [1]
|  http://mail.haskell.org/pipermail/haskell-prime/2015-
|  September/003939.html
|  
|  _______________________________________________
|  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: Quo vadis?

Carter Schonwald
agreed...

i think theres still room for the current for the current committee to succeed (though depending on ambitions it should maybe slide into being 2022 standard perhaps?)

I cant speak for other members, but i'm still hopeful about putting together some of the language improvements to the standard in time for 2020, life and other commitments (in addition to living) permitting. 

I do think that its ultimately a social / communal activity, and humans are best motivated when thats in the clear. 
So the more progress some folks make, the more motivated one way or another other folks will be!



On Fri, Oct 5, 2018 at 1:05 PM Simon Peyton Jones via Haskell-prime <[hidden email]> wrote:
I think the difficulty has always been in finding enough people who are

* Well-informed and well-qualified
* Willing to spend the time to standardise language features

GHC does not help the situation: it's a de-facto standard, which reduces the incentives to spend time in standardisation.

I don’t think we should blame anyone for not wanting to invest this time -- no shame here.  It is a very significant commitment, as I know from editing the Haskell 98 report and the incentives are weak.  Because of that, I am not very optimistic about finding such a group -- we have been abortively trying for several years.

If we want to change that, the first thing is to build a case that greater standardisation is not just an "abstract good" that we all subscribe to, but something whose lack is holding us back.

Simon

|  -----Original Message-----
|  From: Haskell-prime <[hidden email]> On Behalf Of
|  Mario Blaževic
|  Sent: 05 October 2018 17:47
|  To: [hidden email]
|  Subject: Re: Quo vadis?

|  On 2018-10-05 09:10 AM, Henrik Nilsson wrote:
|  > Hi,
|  >
|  > On 10/05/2018 01:20 PM, Mario Blažević wrote:
|  >>      I hereby propose we formally disband the present Haskell 2020
|  >> committee. Our performance has been so dismal
|  >
|  > It has.
|  >
|  > And I should apologise in particular: I've just had far less time than
|  > I thought over the past year for a variety of reasons.
|  >
|  >> that I feel this is the
|  >> only course of action that gives Haskell 2020 any chance of fruition.
|  >> A new committee could then be formed with some more dedicated
|  membership.
|  >
|  > I'm less convinced about that, though. I believe those who signed up
|  > for H2020 actually are people who believe in the value of an updated
|  > standard and has core expertise to make it happen.

|       Regarding the beliefs, if we really represent the most zealous group
|  of Haskell enthusiasts, I have to say the community is in deep trouble. I
|  have no evidence, but I can only hope you're wrong.

|       As for the expertise, my impression is that *everybody* who self-
|  nominated for the committee got accepted. My own self-nomination e-mail
|  [1] explicitly said that


|  > The main reason I'm applying is because I'm afraid that the commitee
|  > might disband like the previous one. If there are enough members
|  > already, feel free to ignore my nomination.

|  Yet I'm in. This was not a high bar to clear.


|  > I can't see how giving up and forming a new group would speed things
|  > up or even increase the chance of success.

|       I was kinda hoping for a Simon ex machina, where a few universally-
|  accepted members of the community hand-pick a new committee.
|  Alternatively, we could come up with some stricter criteria for the next
|  committee before we disband but that assumes we can even get a quorum.

|       Lest I'm suspected of some Machiavellian plot, let me be clear that
|  I refuse to be a part of the next committee, if my proposal should be
|  accepted. Honestly I feel that all members of the present committee with
|  any sense of shame should recuse themselves as well, but that's not up to
|  me.


|  > Instead, what about focusing on identifying a couple of things that
|  > absolutely would have to be in H2020 to make a new standard
|  > worthwhile, like multi-parameter type classes, possibly GADTs, then
|  > figure out what else is needed to support that (like what Anthony
|  > Clayden sketched), and with that as a basis, find out exactly what
|  > technical problems, if any, are hindering progress?
|  >
|  > If this could be neatly summarized, then we'd actually be in a
|  > position to make some progress.

|       That is much the plan we agreed on over a year ago during ICFP 2018.
|  The activity since then is plain to see.


|  [1]
http://mail.haskell.org/pipermail/haskell-prime/2015-
|  September/003939.html

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

_______________________________________________
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: Quo vadis?

Mario Blažević-3
In reply to this post by Haskell - Haskell-prime mailing list
On 2018-10-05 01:05 PM, Simon Peyton Jones wrote:
> I think the difficulty has always been in finding enough people who are
>
> * Well-informed and well-qualified
> * Willing to spend the time to standardise language features
>
> GHC does not help the situation: it's a de-facto standard, which reduces the incentives to spend time in standardisation.
>
> I don’t think we should blame anyone for not wanting to invest this time -- no shame here.  It is a very significant commitment, as I know from editing the Haskell 98 report and the incentives are weak.  Because of that, I am not very optimistic about finding such a group -- we have been abortively trying for several years.


That sounds like we're stuck with the committee we have. In that case,
Simon, could you at least pull some strings to have the actual Haskell
Report placed in the same repository? This is a basic precondition if we
expect individual efforts to accomplish anything. The minimal steps to
actually updating the Haskell Report are:

1. write an RFC (we have some already),
2. have it provisionally accepted (not entirely clear how - would
    "no negative votes in 4 weeks" count?),
3. add the modification to the Haskell Report to the RFC,
4. receive the final approval,
5. merge the RFC into the report.

Steps #3 and #5 depend on having the report in the same repository with
the RFCs. This has been agreed over a year ago:

https://mail.haskell.org/pipermail/haskell-prime/2017-September/004319.html
https://mail.haskell.org/pipermail/haskell-prime/2017-October/thread.html
https://mail.haskell.org/pipermail/haskell-prime/2017-November/thread.html
https://mail.haskell.org/pipermail/haskell-prime/2018-March/004356.html


> If we want to change that, the first thing is to build a case that greater standardisation is not just an "abstract good" that we all subscribe to, but something whose lack is holding us back.

Neither an abstract good nor a good abstraction are something Haskell
has ever shied away from. I don't know if you're actually asking for a
list of "concrete goods"? To start with, every GHC extension that's
added to a standard means:

- one less item to type in the ubiquitous {-# LANGUAGE ScaryExtension
#-} pragma,
- one less item to understand for beginners,
- one less item whose necessity must be justified to the team, and
- one less item of whose future stability the management needs to be
convinced.

I could go on.

_______________________________________________
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: Quo vadis?

Philippa Cowderoy

On 08/10/2018 02:51, Mario Blažević wrote:

>
> Neither an abstract good nor a good abstraction are something Haskell
> has ever shied away from. I don't know if you're actually asking for a
> list of "concrete goods"? To start with, every GHC extension that's
> added to a standard means:
>
> - one less item to type in the ubiquitous {-# LANGUAGE ScaryExtension
> #-} pragma,
> - one less item to understand for beginners,
> - one less item whose necessity must be justified to the team, and
> - one less item of whose future stability the management needs to be
> convinced.
>

I suspect we need to follow the lead of other languages here and accept
that the LANGUAGE pragma is actually a necessity and a positive good for
engineering in the presence of changing language versions.

That would mean we should support more standardised pragmas in the vein
of the existing ones in the report, and perhaps that GHC should give
more information about the stability of extensions. Perhaps when an
extension was first introduced and the GHC versions in which the last
two changes more significant than "bug fix" happened? There might even
be a need for versioning of extensions.

I'd be remiss if I didn't suggest a candidate with a specific problem, a
specific goal and a possible solution to its problem. So, a modest proposal:

- Standardise OverloadedStrings as an available-but-disabled feature
- Allow default statements for the IsString class without
OverloadedStrings, using that type for all string literals
- At some future stage, we can use this to migrate away from [Char] as
the default string literal type
- The Haskell2010 pragma and its successors can be used to ensure code
written to standard doesn't suffer bit rot when migration happens
_______________________________________________
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: Quo vadis?

Philippa Cowderoy
In reply to this post by Haskell - Haskell-prime mailing list

On 05/10/2018 18:05, Simon Peyton Jones via Haskell-prime wrote:
> If we want to change that, the first thing is to build a case that greater standardisation is not just an "abstract good" that we all subscribe to, but something whose lack is holding us back.

To pick an example, I'm left wondering if we can achieve a minimal GADT
specification that doesn't have to stay too stable in the presence of
extensions. Changes in its behaviour would need documenting though and
documenting the behaviour of inference is notoriously difficult at present.

While I have some ideas about documenting inference, I remain as
infamously low on energy as ever - I'm not up to trying it with
Haskell2010, let alone GHC, and I wouldn't want to make a business case
for someone else trying it yet! I think it's a problem that sooner or
later standardised Haskell will need to address though: we're a long way
past the "Hindley-Milner plus simple, well-behaved constraints that
don't need annotations" approach that typeclasses helped push the limits
of.
_______________________________________________
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: Quo vadis?

Gershom Bazerman
In reply to this post by Mario Blažević-3
Mario: as a non-committee member but interested observer, if you yourself wanted to proceed to put the report in the repo, what obstacles would stand in your way, and could we clear them out so you could take charge of that task?

Cheers,
Gershom


On October 7, 2018 at 9:52:14 PM, Mario Blažević ([hidden email]) wrote:

On 2018-10-05 01:05 PM, Simon Peyton Jones wrote:
> I think the difficulty has always been in finding enough people who are
>
> * Well-informed and well-qualified
> * Willing to spend the time to standardise language features
>
> GHC does not help the situation: it's a de-facto standard, which reduces the incentives to spend time in standardisation.
>
> I don’t think we should blame anyone for not wanting to invest this time -- no shame here. It is a very significant commitment, as I know from editing the Haskell 98 report and the incentives are weak. Because of that, I am not very optimistic about finding such a group -- we have been abortively trying for several years.


That sounds like we're stuck with the committee we have. In that case,
Simon, could you at least pull some strings to have the actual Haskell
Report placed in the same repository? This is a basic precondition if we
expect individual efforts to accomplish anything. The minimal steps to
actually updating the Haskell Report are:

1. write an RFC (we have some already),
2. have it provisionally accepted (not entirely clear how - would
   "no negative votes in 4 weeks" count?),
3. add the modification to the Haskell Report to the RFC,
4. receive the final approval,
5. merge the RFC into the report.

Steps #3 and #5 depend on having the report in the same repository with
the RFCs. This has been agreed over a year ago:

https://mail.haskell.org/pipermail/haskell-prime/2017-September/004319.html
https://mail.haskell.org/pipermail/haskell-prime/2017-October/thread.html
https://mail.haskell.org/pipermail/haskell-prime/2017-November/thread.html
https://mail.haskell.org/pipermail/haskell-prime/2018-March/004356.html


> If we want to change that, the first thing is to build a case that greater standardisation is not just an "abstract good" that we all subscribe to, but something whose lack is holding us back.

Neither an abstract good nor a good abstraction are something Haskell
has ever shied away from. I don't know if you're actually asking for a
list of "concrete goods"? To start with, every GHC extension that's
added to a standard means:

- one less item to type in the ubiquitous {-# LANGUAGE ScaryExtension
#-} pragma,
- one less item to understand for beginners,
- one less item whose necessity must be justified to the team, and
- one less item of whose future stability the management needs to be
convinced.

I could go on.

_______________________________________________
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: Quo vadis?

Haskell - Haskell-prime mailing list
In reply to this post by Mario Blažević-3
|  That sounds like we're stuck with the committee we have. In that case,
|  Simon, could you at least pull some strings to have the actual Haskell
|  Report placed in the same repository?

Sounds like a good plan.  If the haskell-prime committee agreed to do this, and it's only a matter of doing it, then you just need someone with commit rights to the relevant repository. I don't know who that is (it certainly isn't me), but if you make them a PR, and ping them by email, it would be easy for them to execute.

Simon


|  -----Original Message-----
|  From: Mario Blažević <[hidden email]>
|  Sent: 08 October 2018 02:52
|  To: Simon Peyton Jones <[hidden email]>; [hidden email]
|  Subject: Re: Quo vadis?
|  
|  On 2018-10-05 01:05 PM, Simon Peyton Jones wrote:
|  > I think the difficulty has always been in finding enough people who
|  > are
|  >
|  > * Well-informed and well-qualified
|  > * Willing to spend the time to standardise language features
|  >
|  > GHC does not help the situation: it's a de-facto standard, which
|  reduces the incentives to spend time in standardisation.
|  >
|  > I don’t think we should blame anyone for not wanting to invest this
|  time -- no shame here.  It is a very significant commitment, as I know
|  from editing the Haskell 98 report and the incentives are weak.  Because
|  of that, I am not very optimistic about finding such a group -- we have
|  been abortively trying for several years.
|  
|  
|  That sounds like we're stuck with the committee we have. In that case,
|  Simon, could you at least pull some strings to have the actual Haskell
|  Report placed in the same repository? This is a basic precondition if we
|  expect individual efforts to accomplish anything. The minimal steps to
|  actually updating the Haskell Report are:
|  
|  1. write an RFC (we have some already),
|  2. have it provisionally accepted (not entirely clear how - would
|      "no negative votes in 4 weeks" count?), 3. add the modification to
|  the Haskell Report to the RFC, 4. receive the final approval, 5. merge
|  the RFC into the report.
|  
|  Steps #3 and #5 depend on having the report in the same repository with
|  the RFCs. This has been agreed over a year ago:
|  
|  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has
|  kell.org%2Fpipermail%2Fhaskell-prime%2F2017-
|  September%2F004319.html&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C227f
|  843099c5489509da08d62cc0a25f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7
|  C636745603204766102&amp;sdata=z3meiZAXQoKzsiOzPAjicdzLbL2vRp0NPgIsUFM2h%2
|  FY%3D&amp;reserved=0
|  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has
|  kell.org%2Fpipermail%2Fhaskell-prime%2F2017-
|  October%2Fthread.html&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C227f84
|  3099c5489509da08d62cc0a25f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6
|  36745603204766102&amp;sdata=ilw5EXJyblsVyqs3e7iczbTpG3TexjNY7nmSokMJFvM%3
|  D&amp;reserved=0
|  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has
|  kell.org%2Fpipermail%2Fhaskell-prime%2F2017-
|  November%2Fthread.html&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C227f8
|  43099c5489509da08d62cc0a25f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C
|  636745603204766102&amp;sdata=T5zS7b9Swyn%2FWPW8Yqt9XTOf38KSqYmMkgzglesjAR
|  Y%3D&amp;reserved=0
|  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has
|  kell.org%2Fpipermail%2Fhaskell-prime%2F2018-
|  March%2F004356.html&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C227f8430
|  99c5489509da08d62cc0a25f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636
|  745603204766102&amp;sdata=bSimqVnSL0Yp18LhYMJ9LsqnPWT4QmT%2BKpyRwAISbdY%3
|  D&amp;reserved=0
|  
|  
|  > If we want to change that, the first thing is to build a case that
|  greater standardisation is not just an "abstract good" that we all
|  subscribe to, but something whose lack is holding us back.
|  
|  Neither an abstract good nor a good abstraction are something Haskell has
|  ever shied away from. I don't know if you're actually asking for a list
|  of "concrete goods"? To start with, every GHC extension that's added to a
|  standard means:
|  
|  - one less item to type in the ubiquitous {-# LANGUAGE ScaryExtension #-}
|  pragma,
|  - one less item to understand for beginners,
|  - one less item whose necessity must be justified to the team, and
|  - one less item of whose future stability the management needs to be
|  convinced.
|  
|  I could go on.

_______________________________________________
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: Quo vadis?

Mario Blažević-3
In reply to this post by Gershom Bazerman
On 2018-10-07 11:36 PM, Gershom B wrote:
> Mario: as a non-committee member but interested observer, if you
> yourself wanted to proceed to put the report in the repo, what
> obstacles would stand in your way, and could we clear them out so you
> could take charge of that task?

My understanding is that the canonical home of the report is
https://github.com/haskell/haskell-report. Can somebody with the
knowledge confirm this? If so, I (or anybody else willing) can either:

1. submit a simple but rather large pull request that dumps the entire
source of the report into the https://github.com/haskell/rfcs/ repository,
2. use git subtree to add a fork of the report with full history to the
https://github.com/haskell/rfcs/ repository, or
3. use a Git submodule to host a fork of the report with full history.

I'm against option #3 because it would complicate the work with new
proposals, and in this situation we can't add anything that de-motivates
the potential contributors. From their perspective, options #1 and #2
are indistinguishable but #2 should be easier to merge back into the
canonical report whenever Haskell2020(+n) finally becomes official. So
#2 would be my choice.

Is anybody out there against this plan?

It's worth a mention that I would not actually merge the PR before
giving another chance to everybody to try the fork, but the plan is to
merge it into the master before we proceed with new proposal PRs. The
existing proposals, once accepted, would need to be refreshed from the
master by their authors.

_______________________________________________
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: Quo vadis?

Mario Blažević-3
In reply to this post by Philippa Cowderoy
On 2018-10-07 11:32 PM, Philippa Cowderoy wrote:

>
> I'd be remiss if I didn't suggest a candidate with a specific problem,
> a specific goal and a possible solution to its problem. So, a modest
> proposal:
>
> - Standardise OverloadedStrings as an available-but-disabled feature
> - Allow default statements for the IsString class without
> OverloadedStrings, using that type for all string literals
> - At some future stage, we can use this to migrate away from [Char] as
> the default string literal type
> - The Haskell2010 pragma and its successors can be used to ensure code
> written to standard doesn't suffer bit rot when migration happens


The second bullet point could use some clarification. Would you mind
commenting on the existing defaulting proposal at
https://github.com/haskell/rfcs/pull/18 ?


_______________________________________________
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: Quo vadis?

Philippa Cowderoy


On 09/10/2018 00:58, Mario Blažević wrote:

> On 2018-10-07 11:32 PM, Philippa Cowderoy wrote:
>>
>> I'd be remiss if I didn't suggest a candidate with a specific
>> problem, a specific goal and a possible solution to its problem. So,
>> a modest proposal:
>>
>> - Standardise OverloadedStrings as an available-but-disabled feature
>> - Allow default statements for the IsString class without
>> OverloadedStrings, using that type for all string literals
>> - At some future stage, we can use this to migrate away from [Char]
>> as the default string literal type
>> - The Haskell2010 pragma and its successors can be used to ensure
>> code written to standard doesn't suffer bit rot when migration happens
>
>
> The second bullet point could use some clarification. Would you mind
> commenting on the existing defaulting proposal at
> https://github.com/haskell/rfcs/pull/18 ?
>
>

I've been away from the overall process and I'm not in best health right
now, so it'll take a while to catch up but I'll do my best.

The gist (which someone else may have covered) is that it's not
overloading if you have exactly one type of string literals, even if we
let the user say which type it is. I've read enough to see I'll have to
have my thinking cap on while writing much more than that as a useful
comment though, not least because of the interaction with an imported
defaults mechanism that normally needs to work with a sequence of defaults.
_______________________________________________
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: Quo vadis?

Philippa Cowderoy
In reply to this post by Mario Blažević-3


On 09/10/2018 00:58, Mario Blažević wrote:

> On 2018-10-07 11:32 PM, Philippa Cowderoy wrote:
>>
>> I'd be remiss if I didn't suggest a candidate with a specific
>> problem, a specific goal and a possible solution to its problem. So,
>> a modest proposal:
>>
>> - Standardise OverloadedStrings as an available-but-disabled feature
>> - Allow default statements for the IsString class without
>> OverloadedStrings, using that type for all string literals
>> - At some future stage, we can use this to migrate away from [Char]
>> as the default string literal type
>> - The Haskell2010 pragma and its successors can be used to ensure
>> code written to standard doesn't suffer bit rot when migration happens
>
>
> The second bullet point could use some clarification. Would you mind
> commenting on the existing defaulting proposal at
> https://github.com/haskell/rfcs/pull/18 ?
>
>

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