I agree that GHC extensions should be the starting point for new additions, as changes to the report should be based on established implementations (to ensure that changes are implementable and to ensure that they work out well for users).
1) background reading There were a few interesting threads on reddit the other day that may provide some fodder to think about. First, there was a survey of what extensions that people found useful and would like incorporated, as well as their concerns: https://www.reddit.com/r/haskell/comments/4fsuvu/can_we_have_xhaskell2016_which_turns_on_the_most/ (Feel free to disregard the confusion of how they described “Haskell2016” and the like for something closer to glasgow-exts-2016, as its extraneous to what makes this interesting). Second, the summary thread on the results: https://www.reddit.com/r/haskell/comments/4ggp8z/summary_of_the_xhaskell2016_feedback/ The summary results give a good indication of what extensions there might seem to be the most widespread sentiment to standardize. This thread also gives a link to Reid Barton’s lovely example of how FlexibleInstances can be used to violate coherence: https://www.reddit.com/r/haskell/comments/2agy14/type_classes_confluence_coherence_global/civ6y1g The same trick is supposed to apply to MPTCs. (In both cases, I imagine there can be a “fixup” that would prevent this, but that’s for another discussion). 2) suggestions for proceeding In any case, it seems to me (as a non-prime-committee member) that it would be good to proceed in two parallel tracks. First: A victim^H^H^H^H^H^H volunteer to pick a particularly low-hanging fruit (lambdacase, tuple sections, binary literals) and try to do a test-run of the proposal process to work out the kinks and set an example for others to follow. Perhaps a few could be worked on by different people at once. (As a datapoint, here is I think how an accepted proposal looked under the H2010 process: https://prime.haskell.org/wiki/NoNPlusKPatterns) (And I see that Austin has already volunteered! wonderful!) Second: Some high-level effort to categorize and pull together a dependency graph of the other extensions. A googledoc spreadsheet or a trello board might be a good “work arena” for this. I would want to separate extensions into for example buckets like “pure syntax” “typeclass related” “monad syntax” “deriving related” “higher-rank related” “record related” “concurrency related”. The idea would be that things in the same bucket would have a higher chance of interacting / potentially needing to be treated in tandem. That way, areas could be tackled at once, and the committee could “burndown” easy stuff, while perhaps individuals with expertise might want to try to work on the side to find “minimal, safe” paths through the thicket of complex extensions. (standardizing GADT syntax without yet adding type equality constraints to enable actual GADTs is a good example here. Another _might_ be for example allowing RankNTypes but specifying that compliant compilers need only accept such type signatures fully specified, but could optionally go above and beyond in inference, etc). Note that more complex proposals could always be worked out by interest groups working by themselves, and only presented to a larger audience once some kinks were ironed out, etc. Cheers, Gershom On May 2, 2016 at 6:57:46 PM, John Wiegley (jo...@newartisans.com) wrote: > I wonder if there are GHC extensions we'd like to promote as features in the > next report, as a starting point for discussing new additions. > > There are a few GHC features that have become part of the regular Haskell > landscape, such that it's hard to imagine a modern Haskell without them. For > example, MultiParamTypeClasses, OverloadedStrings, GADTs, TypeFamilies, etc. > > How much "work" is typically involved in promoting a feature to be in the > Report, and how do we determine when it's a bad idea? > > -- > John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F > http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime > _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
