IMO, the committee should not focus on most these at the moment, because there are easier wins to be had - most of the open proposed ones have problems that make the discussion veer from "Very Obvious" to "Not so obvious". I know they're popular, but doing this is going to require a lot more discussion.
A few points: - MPTCs. I'm OK with this by itself but it's not very useful without some constituent thing like Fundeps or type families. Richard, when you say there's an incoherence problem, can you be more specific? The more recent one I was reminded of was that FlexibleInstances can violate coherence, but that's a bit more subtle - maybe that's what you meant? I'm not sure if it's enough to keep it out. See https://gist.github.com/rwbarton/dd8e51dce2a262d17a80 for an example. - OverloadedStrings are less trivial than you think. Because: $ ghci GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help Prelude> :set -XOverloadedStrings Prelude> length "foo" <interactive>:3:1: No instance for (Foldable t0) arising from a use of ‘length’ The type variable ‘t0’ is ambiguous ... Yes, I know, the FTP, etc etc etc. However, that makes a lot of simple code examples break in the case of overloaded functions that can't pick the right base type. There's obviously still some back and forth to be done, perhaps the FTP could be refined for Haskell2020. Anyway, my point is this is less initially trivial than it might seem to some. - GADTs are an extension I like dearly, but I think they are also not so simple. I think the Haskell report is fairly careful, as it stands, not to dictate much about inference strategies. GADTs surface these changes, for example, by ensuring let is not generalized. I think the committee could come to something on this perhaps, but it is not so simple. Deviating from this is something we can decide to do, but not easily. - Richard touched on it only as an side, but GADT syntax would be excellent. I would even like it to be enshrined by the standard as the default (perhaps modulo ExistentialQuantification). In fact I like it so much that it gets its own bullet point. That's for another day, just saying. - Type families, I think, are not as well understood and have changed far too quickly, in recent memory, to talk about this early on, as Richard said. I think that at the moment we should focus on making the process easy so we can keep our motivation up. Taking on large extensions is going to lead to bikeshedding and drain people, I think, which would be a real bad thing to happen after so much hubbub. I know many people on the committee are probably going to have feelings similar to the above. If we are going to talk about "wholesale incorporation", there are many simplier, much more obvious extensions. Plus, these will give us a chance to go at the process and try to find something that works for us. Or at least makes us all equally unhappy (the definition of good compromise). Much easier to test out how we want things to go when the stakes are much lower. I like the list Michael Sloan suggested elsewhere, or something like it. Many many more obvious extensions to be had: - RecursiveDo - LambdaCase - TupleSections (surprisingly popular, in the "would use frequently if always on"-category, it seems) - GADTSyntax (already definitively asserted as great) - BinaryLiterals - EmptyCase - InstanceSigs - ParallelListComp I seem to remember MultiWayIf having some kind of weird interaction with the lexer to make it abide by the proper block rules, but I'd probably also vote for it anyway. I intentionally left off anything that didn't seem somewhat blindingly obvious, and some that you might think suspiciously absent I know for a fact someone might pipe up and say "But wait!" -- Anyway, the point is to get some easy wins. Maybe others are ones we incorporate wholesale too, but let's just target a couple really clear ones. The thread about the RFC/editing process is still ongoing, but I think we could easily add the above ones with only a couple rounds of intense, heated debate, and that would be a good warm up. Traditionally, I think proposals were actually sent including what were basically literal deltas to the Haskell Report, pretty much, including how it would be described and added. Obviously we want source control to do that now. I'd be willing to be a guinea pig and submit a couple of the above ones for some trial runs on the process, if people think this is an OK place to start. We'll probably have to nail the exact RFC method down, though, in the other thread on the list. I also probably wouldn't get to it until the end of this week, so that's likely for the best anyway. On Mon, May 2, 2016 at 8:33 PM, Richard Eisenberg <e...@cis.upenn.edu> wrote: > Great questions. Here's my take: > > For something to be incorporated into the standard, we'd need to be able to > give a concrete, precise description of how the extension changes the set of > correct Haskell programs. We also need to consider how the extension changes > properties of the language, like predictability of performance or class > coherence. > > For the four you mention, here are my thoughts: > > MultiParamTypeClasses: Can't these be used to create incoherence? I seem to > recall hearing this once. I'm in general in favor of including these, but > would want to reflect on the coherence question a bit. > > OverloadedStrings: This seems very straightforward. But it's quite easy to > conceive of times when I wouldn't want this feature in the language. If the > extension becomes part of the standard, is there a way to turn it off? If > not, Haskell2020 would not be a conservative extension of Haskell2010. > > GADTs: While GADTSyntax seems straightforward, GADT type inference is far > from. Do we have a description of GADT type inference that doesn't rely on > thinking about variable unification? Even if we're OK putting unification > into the standard, GHC's current inference capabilities are still not very > finely mapped. (Note that the inference algorithm in the OutsideIn paper is > incomplete with respect to the specification in that paper.) > > TypeFamilies: I think there's quite a bit more to understand about type > families before they could be standardized. First off, they come in many > flavors (associated, open, closed). Do we want to include all of the flavors? > How do partial type families really operate? I wrote a blog post [1] > exploring this topic and had more questions than answers. What about > termination checking? Or do we want to allow non-terminating definitions and > discard decidability of type inference? > > Of course, I recognize that John picked just a few arbitrary popular > extensions. But even these extensions have a lot of dark corners, and my > answers above are just to highlight that there's real work to be done, even > with very popular extensions. > > Richard > > [1]: https://typesandkinds.wordpress.com/2015/09/09/what-are-type-families/ > > On May 2, 2016, at 6:57 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 > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime