Are there GHC extensions we'd like to incorporate wholesale?

[Cale Gibbard]

This question implicitly has two parts:

1) Are there GHC extensions which the Report ought to describe in their
entirety? To this question, I would say "yes" - pretty much anything which
can be done in that direction will be productive, it's more a question of
what people are willing to put the work into.

2) Are there extensions which ought to stop being extensions? To this
question, I would argue it would be best to leave it for a time when the
extension is already fully described as an extension in the Report. It may
also be best to leave the answer up to the implementations. It is much
easier to argue for something like that once the extension has been on by
default in GHC and all other implementations for a while and most everyone
seems happy leaving it on.
On May 2, 2016 23:45, "Gershom B" <gershomb at gmail.com> wrote:

> 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 (johnw at 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 at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
> >
>
> _______________________________________________
> 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/20160503/2b7c7b0a/attachment-0001.html>