Quo vadis?

[Mario Blažević]

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.