Hi, Am Mittwoch, den 18.10.2017, 20:36 +0100 schrieb Roman Leshchinskiy:
It is indeed a commitment but there must be some commitment to stability. If the Haskell' committee came up with Haskell 2017, surely GHC would commit to supporting that … Of course, the real fix for this is to have a proper language standard. I'm just proposing a partial workaround for not having one.
I think this implies (and I agree) that it’s the Haskell' committee’s task to take existing language extensions, decide whether they are mature enough to be standardized, go through the work of actually specifying them rigorously. This would yield a distinction between “new, fancy, evolving, use-at-your-own-risk” extensions and “mature, can safely be used in production” extensions. Unfortuantely, Haskell' (AFAIK) not only has do take stability and specificatability into account, but also portability: Does a certain extension makes sense independent of GHC. This is orthogonal to the above, and I expect that there are stable, unportable extensions. So this naturally leads to Richard’s suggestion: Am Mittwoch, den 18.10.2017, 15:44 -0400 schrieb Richard Eisenberg:
I think with one tweak, Roman and I could be in nice agreement: list only a subset of extensions as stable. For example, I think RankNTypes is nice and stable. Depending on your level of tolerance for possible problems, GADTs might also be stable. (We *don't* have a specification of that extension, despite trying.) I don't think anyone would argue that PolyKinds is stable, even before GHC 8 came along Would that satisfy everyone? GHC can advertise a subset of extensions for which Simon M's (1) and (2) hold; the rest of the extensions are like Simon M's (3). We, as a committee, are responsible for this labeling and for keeping it up to date.
This sounds good, mostly. But would we have had the foresight to recognize that the `ExplicitNamespaces` extension was incomplete in the sense that it only applied to import and export lists, when it obviously should have applied to fixity declarations and various pragmas as well? The way out there might be to try our best, and if we get it wrong and mark an extension as stable too early, we’ll just have to add a new pragma for the improved ones… so that seems like a good compromise. The other failure mode would be that we will have _too strict_ requirements for marking extensions as stable, so that production code will inevitably have to use non-stable extensions, and not much is gained. All in all, it might work.
Perhaps we could even have a public place where users could request that we label some extension as stable and we could consider the request.
Naturally, that could just be a proposal and follow the same process. Regards, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/