[ghc-steering-committee] Proposal: Type Fixity (#65), Consensus: accept, own language extension?

[Joachim Breitner]

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 at joachim-breitner.de
  http://www.joachim-breitner.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20171018/56944a70/attachment.sig>