Quo vadis?

[Gershom B]

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ć (blamario at ciktel.net) 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
Haskell-prime at haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-prime/attachments/20181007/a85f71fe/attachment.html>