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@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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime