Something like (1) or (2) do seem attractive. But we have, for better or worse, always taken a non-rigid position on back-compat. If it seems the right thing to change a language feature slightly, we have typically done so. For the most part no one notices. Perhaps that’s because a far bigger issue is changes to the base library: those really do affect people. And because of that I don’t think we’ll ever be able to rename and typecheck all of Hackage with any old GHC; there’s always a version range involved. So I think I’m in favour of (3), but with breaches of (1,2) handled with explicit judgement rather than cavalier disregard. Simon From: ghc-steering-committee [mailto:ghc-steering-committee-bounces@haskell.org] On Behalf Of Simon Marlow Sent: 17 October 2017 08:54 To: Iavor Diatchki Cc: ghc-steering-committee@haskell.org Subject: Re: [ghc-steering-committee] Proposal: Type Fixity (#65), Consensus: accept, own language extension? The main reason I took a position on the issue of extension flags is to force the question: what should LANGUAGE mean? I think it's important to resolve this, to inform future decisions. Here are some options: 1. LANGUAGE fully specifies the grammar of the source file 2. LANGUAGE fully specifies the grammar and semantics of the source file 3. LANGUAGE tells the compiler what extensions are required, but otherwise provides no guarantees. The source file might not compile with a given version of GHC even if it supports all the extensions listed. In other words, LANGUAGE together with a GHC version range specifies the grammar and semantics of the source file. I think what we have right now is 3, because we change the meaning of extensions from version to version of GHC. There are advantages to 1 and 2: for example, if we had 1, then we could parse all of Hackage with haskell-src-exts (or at least identify the subset of source files that can be parsed via their LANGUAGE pragmas). If we had 2, then we could parse, rename and typecheck all of Hackage using haskell-src-exts, haskel-names, and haskell-type-exts. Perhaps we want to say that we can only *add* syntax to an existing extension, not change or remove it. This is a variant of 3 that requires only a lower bound on the GHC version required, not an upper bound, and it provides some of the benefits of 1 and 2: you just need a sufficiently recent version of haskell-src-exts et. al. Anyway, I mainly wanted to ensure that we're clear about what LANGUAGE means. If we believe the implications of 1 and 2 are too onerous (never changing extensions), so what we want is 3, so be it. Cheers Simon On 10 October 2017 at 03:54, Iavor Diatchki mailto:iavor.diatchki@gmail.com> wrote: Hello, my preference would be to add this to one of the existing extensions (either "explicit namespaces", or "type level operators"). Iavor On Sat, Oct 7, 2017 at 11:26 AM Joachim Breitner mailto:mail@joachim-breitner.de> wrote: Hi Committee, the discussion has ebbed down again. I observe that a clear majority is in favor. I don’t think there is a need for a formal vote, so I will proceed with this decision. Simon M brought up the next issue: Shall we require a separate language extension for this, or can it go under the hood of `ExplicitNamespaces`? So far Simon M expressed a strong preference for the former, while I am inclined to prefer the latter, and would like to hear a few more opinions on this detail (which certainly would set precedence for future decisions). Richard brought up the idea of versioned language extensions; that idea can certainly be investigated, but better independently. We have to deal with this proposal with the tools we have. Greetings, Joachim Am Mittwoch, den 20.09.2017, 12:23 -0400 schrieb Joachim Breitner:

Hi,

the type fixity proposal (https://github.com/ghc-proposals/ghc-proposals/pull/65https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F65&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaac52c0ae0f4e79724608d515343160%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636438236268085142&sdata=d2EZ83iPvWUWKhtgqBEEXId4xg%2FAYHD2VFh6oM%2BwmQo%3D&reserved=0) was met with mixed reactions.

* I recommended rejection and Manuel strongly agrees with me. * SPJ does not have strong opinions either way. * Richard is in favor, and Iavor agrees.

Our process says “If consensus is elusive, then we vote, with the Simons retaining veto power.” It looks like this might be such a case. Should we go ahead and vote, or is more discussion likely to sway some of us?

(I guess I can be swayed towards acceptance, especially if this proposal re-uses existing syntactic idioms from export lists with ExplicitNamespaces on.)

Greetings, Joachim

Am Sonntag, den 27.08.2017, 20:16 +0200 schrieb Joachim Breitner:

...

Dear Committee,

Ryan Scott’s proposal to allow fixity declaration to explicitly target values or types has been brought before us: https://github.com/RyanGlScott/ghc-proposals/blob/type-infix/0000-type-infix...https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FRyanGlScott%2Fghc-proposals%2Fblob%2Ftype-infix%2F0000-type-infix.rst&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaac52c0ae0f4e79724608d515343160%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636438236268085142&sdata=9deOwM4rC4Ckum0lvNirj44NMIqXKzoiUPyMg4DgJQU%3D&reserved=0 https://github.com/ghc-proposals/ghc-proposals/pull/65https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F65&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaac52c0ae0f4e79724608d515343160%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636438236268085142&sdata=d2EZ83iPvWUWKhtgqBEEXId4xg%2FAYHD2VFh6oM%2BwmQo%3D&reserved=0

I (the secretary) nominates myself as the shepherd, so I can right away continue giving a recommendation.

I propose to reject this proposal. The main reasons are: * it is not clear if there is a real use case for this. Has anyone ever complained about the status quo? The proposal does not motivate the need for a change well enough. (There is a related bug in TH, but that bug can probably simply be fixed.) * The status quo can be sold as a feature, rather than a short-coming. Namely that an operator has a fixed fixity, no matter what namespace it lives in. This matches morally what other languages do: In Gallina, fixity is assigned to names independent of their definition, AFAIK. * There is a non-trivial implementation and education overhead, a weight that is not pulled by the gains.

If we’d design Haskell from scratch, my verdict might possibly be different (but maybe we wouldn’t even allow types and values to share names then…)

Please contradict me or indicate consensus by staying silent.

Greetings, Joachim

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-- Joachim Breitner mail@joachim-breitner.demailto:mail@joachim-breitner.de http://www.joachim-breitner.de/https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaac52c0ae0f4e79724608d515343160%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636438236268085142&sdata=xvdf4zj1aKIfqxCMm%2B5DXZIrnha5Zu28YIngs3EFUE8%3D&reserved=0

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim Breitner mail@joachim-breitner.demailto:mail@joachim-breitner.de http://www.joachim-breitner.de/https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaac52c0ae0f4e79724608d515343160%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636438236268085142&sdata=xvdf4zj1aKIfqxCMm%2B5DXZIrnha5Zu28YIngs3EFUE8%3D&reserved=0

ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Yes, this is a very important question. Naturally, (2) makes the theorist in me very happy. But I advocate for (3), regardless: - This debate isn't only about extensions. As has been pointed out, `base` undergoes a non-trivial amount of churn between releases, and considering the compiler in a vacuum isn't realistic. Two versions of the compiler will accept (slightly) different versions of the language. (Or, in the case of GHC 7.8, drastically different versions of the language.) - I think we're handicapping ourselves at creating a cutting-edge language if we adopt (1) or (2). (3) allows us to, well, move fast and break things, and that model has been very successful for Haskell thus far. - Who gets hurt if we choose (3)? Surely, (3) means that, e.g., cabal files should properly specify GHC ranges. And we should aim for Simon M's original comment that evolution only adds features -- but we'll never really meet that standard, I don't think. - We could adopt versioned extensions, as I've previously brought up. Doing so might move us more toward (1) or (2). However, I would expect a version of GHC to support only one version of a given extension, and so then a file with, say, `{-# LANGUAGE PolyKinds-3 #-}` would be acceptable by only a small compiler version range (possibly containing only one major release), and then what will we have gained? - I like the idea of having the manual state the stability of extensions. (We should also state unambiguously the potential downside of extensions -- like declaring that UndecidableInstances may cause GHC to loop, but it doesn't allow you to shoot the gorillas.) But I don't think that an extension has to be set in stone after only two revisions. Sometimes experiments really do take years to carry out! So, I like the idea of alpha/beta/stable, but (in contrast to Manuel) I would let the feature designers choose when it's time to move the needle. Looking forward to seeing others' thoughts on this, Richard

On Oct 17, 2017, at 6:30 AM, Manuel M T Chakravarty wrote:

I completely agree with Simon: this is an important question.

I think, it would be good to have at least (1), but better (2).

Why? Because Haskell’ really doesn’t get anywhere and in its absence the guarantees provided by GHC are the only language stability there is. Maybe it is unfair to put this burden on the compiler, instead of on a separate language specification, but that is how it is.

Now, I reckon the main obstacle to (1) and (2) is that LANGUAGE extensions, when they appear first, are in flux, because they are often parts of experiments. Hence, I’d like to suggest that we might be able to lessen the tension between experimentation and stability by formally associating a ”stability” of one of ”alpha”, ”beta”, or ”stable” with each extension.

As we all know, these stability annotations don’t work at all on Hackage as nobody ever moves their packages away from ”experimental”. Hence, I suggest that we do not make this the choice of the person who proposes an extension, but part of our process. There are a few options, which might be worth considering.

For example, when a LANGUAGE extension is first proposed, it starts at ”alpha”. When latter a proposal is submitted to amend the extension, that amendment is approved by us only if it successfully argues that it improves the maturity of the extension such that it warrants ”beta” stability. And then, the same with ”stable” on the second amendment. Finally, ”stable” language extensions cannot be changed unless it is to fix a grave semantic error or similar.

Instead (or in addition) of bumping stability on every new proposal involving the extension, we could also adopt a time (or release) based scheme.

Cheers, Manuel

PS: BTW, we are pushing for getting to 6 monthly release of GHC. This means that without any guarantees across versions, we would potentially increase variability, which would be bad.

...

Simon Marlow mailto:marlowsd@gmail.com>:

The main reason I took a position on the issue of extension flags is to force the question: what should LANGUAGE mean? I think it's important to resolve this, to inform future decisions. Here are some options:

1. LANGUAGE fully specifies the grammar of the source file 2. LANGUAGE fully specifies the grammar and semantics of the source file 3. LANGUAGE tells the compiler what extensions are required, but otherwise provides no guarantees. The source file might not compile with a given version of GHC even if it supports all the extensions listed. In other words, LANGUAGE together with a GHC version range specifies the grammar and semantics of the source file.

I think what we have right now is 3, because we change the meaning of extensions from version to version of GHC. There are advantages to 1 and 2: for example, if we had 1, then we could parse all of Hackage with haskell-src-exts (or at least identify the subset of source files that can be parsed via their LANGUAGE pragmas). If we had 2, then we could parse, rename and typecheck all of Hackage using haskell-src-exts, haskel-names, and haskell-type-exts.

Perhaps we want to say that we can only *add* syntax to an existing extension, not change or remove it. This is a variant of 3 that requires only a lower bound on the GHC version required, not an upper bound, and it provides some of the benefits of 1 and 2: you just need a sufficiently recent version of haskell-src-exts et. al.

Anyway, I mainly wanted to ensure that we're clear about what LANGUAGE means. If we believe the implications of 1 and 2 are too onerous (never changing extensions), so what we want is 3, so be it.

Cheers Simon

On 10 October 2017 at 03:54, Iavor Diatchki mailto:iavor.diatchki@gmail.com> wrote:

Hello,

my preference would be to add this to one of the existing extensions (either "explicit namespaces", or "type level operators").

Iavor

On Sat, Oct 7, 2017 at 11:26 AM Joachim Breitner mailto:mail@joachim-breitner.de> wrote: Hi Committee,

the discussion has ebbed down again. I observe that a clear majority is in favor. I don’t think there is a need for a formal vote, so I will proceed with this decision.

Simon M brought up the next issue: Shall we require a separate language extension for this, or can it go under the hood of `ExplicitNamespaces`?

So far Simon M expressed a strong preference for the former, while I am inclined to prefer the latter, and would like to hear a few more opinions on this detail (which certainly would set precedence for future decisions).

Richard brought up the idea of versioned language extensions; that idea can certainly be investigated, but better independently. We have to deal with this proposal with the tools we have.

Greetings, Joachim

Am Mittwoch, den 20.09.2017, 12:23 -0400 schrieb Joachim Breitner:

...

Hi,

the type fixity proposal (https://github.com/ghc-proposals/ghc-proposals/pull/65 https://github.com/ghc-proposals/ghc-proposals/pull/65) was met with mixed reactions.

* I recommended rejection and Manuel strongly agrees with me. * SPJ does not have strong opinions either way. * Richard is in favor, and Iavor agrees.

Our process says “If consensus is elusive, then we vote, with the Simons retaining veto power.” It looks like this might be such a case. Should we go ahead and vote, or is more discussion likely to sway some of us?

(I guess I can be swayed towards acceptance, especially if this proposal re-uses existing syntactic idioms from export lists with ExplicitNamespaces on.)

Greetings, Joachim

Am Sonntag, den 27.08.2017, 20:16 +0200 schrieb Joachim Breitner:

...

Dear Committee,

Ryan Scott’s proposal to allow fixity declaration to explicitly target values or types has been brought before us: https://github.com/RyanGlScott/ghc-proposals/blob/type-infix/0000-type-infix... https://github.com/RyanGlScott/ghc-proposals/blob/type-infix/0000-type-infix... https://github.com/ghc-proposals/ghc-proposals/pull/65 https://github.com/ghc-proposals/ghc-proposals/pull/65

I (the secretary) nominates myself as the shepherd, so I can right away continue giving a recommendation.

I propose to reject this proposal. The main reasons are: * it is not clear if there is a real use case for this. Has anyone ever complained about the status quo? The proposal does not motivate the need for a change well enough. (There is a related bug in TH, but that bug can probably simply be fixed.) * The status quo can be sold as a feature, rather than a short-coming. Namely that an operator has a fixed fixity, no matter what namespace it lives in. This matches morally what other languages do: In Gallina, fixity is assigned to names independent of their definition, AFAIK. * There is a non-trivial implementation and education overhead, a weight that is not pulled by the gains.

If we’d design Haskell from scratch, my verdict might possibly be different (but maybe we wouldn’t even allow types and values to share names then…)

Please contradict me or indicate consensus by staying silent.

Greetings, Joachim

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-- Joachim Breitner mail@joachim-breitner.de mailto:mail@joachim-breitner.de http://www.joachim-breitner.de/ http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim Breitner mail@joachim-breitner.de mailto:mail@joachim-breitner.de http://www.joachim-breitner.de/ http://www.joachim-breitner.de/

---

ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

On Oct 18, 2017, at 2:44 AM, Roman Leschinskiy wrote:

GHC commits to supporting this semantics for, say, 4 years.

This is a very large commitment, in my view. Maintaining subtle differences in extensions is hard work, especially when the differences are not syntactic (which are admittedly much easier). For example, there have been quite a few bugs in keeping -XTypeInType and -XPolyKinds separate, and I don't think we have it fully working yet. There's one unstated assumption behind all this, for me: we're very, very, very cautious about ever changing the *dynamic* semantics (i.e. runtime behavior) between releases. That's potentially disastrous. It's annoying and frustrating when one version of GHC accepts a program while another rejects. But someone downstream can work around this, either with CPP or with cabal/stack settings that dictate GHC versions. However, a runtime behavior change might go uncaught and cause real bugs. So, when I say I advocate for Simon M's (3), I really mean 4. LANGUAGE tells the compiler what extensions are required and -- if the program is accepted -- its runtime behavior, but otherwise provides no guarantees. The source file might not compile with a given version of GHC even if it supports all the extensions listed. In other words, LANGUAGE together with a GHC version range specifies the grammar and static semantics of the source file. However, LANGUAGE alone (without the version range) specifies the runtime behavior of any resulting code. (This is just a small delta on Simon M's (3) with clarity around runtime behavior.) I'd love feedback from the more industrial users here. It's unsurprising that, from my viewpoint, I would advocate for looser guarantees. But part of why I think looser guarantees are OK is that I thought Stack had basically solved this problem for industrial users, in that several collaborators on a project have a stack.yaml that (among other things) fixes the GHC version. Yes, that team will occasionally want to upgrade, but upgrading will always cause some problems, problems that we as the GHC committee will work to mitigate. Until we take Java's approach to backward compatibility (I hope that's a long long way off!), upgrading will cause problems, no matter which of (1)-(4) we adopt. Richard

On Wed, Oct 18, 2017 at 3:08 PM, Richard Eisenberg wrote:

...

On Oct 18, 2017, at 2:44 AM, Roman Leschinskiy wrote:

GHC commits to supporting this semantics for, say, 4 years.

This is a very large commitment, in my view.

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. Alas, that isn't happening but there has to be a stable language which goes beyond Haskell 2010. It would be good if GHC took some initiative there. I do very much appreciate that it's more work but it's something that an industrial-strength compiler like GHC ought to provide, in my view. Imagine you have a very large code base, a large team working on it and other teams which work on bits of it. To maintain sanity, you have to ensure that everything is written in one dialect. You might pick Haskell 2010 but you'd be missing a lot of fairly crucial (at least, in my view) functionality. So you pick a blessed set of extensions which you enable by default and you disable everything else. Now, after a couple of years you decide to upgrade GHC. This is already a lot of work due to changes in RTS behaviour, dynamic linking, memory consumption etc. You'd *really* like your code to at least still compile and run. At the moment, it typically doesn't, unfortunately.

For example, there have been quite a few bugs in keeping -XTypeInType and -XPolyKinds separate, and I don't think we have it fully working yet.

This is (I think) exactly a case where, say, an -XPolyKinds-2017 would be helpful. It's not a problem if it turns on more than just PolyKinds. What's problematic is if a later version of GHC breaks your code because the meaning of the extension changed (even if it's now more correct than it used to be). Note that I don't advocate bug compatibility. I'd just like to be able to enable -XThis and have the assurance that GHC devs will *try* to maintain its semantics for a few years.

Yes, that team will occasionally want to upgrade, but upgrading will always cause some problems, problems that we as the GHC committee will work to mitigate. Until we take Java's approach to backward compatibility (I hope that's a long long way off!), upgrading will cause problems, no matter which of (1)-(4) we adopt.

There will always be some problems, yes, but problems like "20 modules sprinkled throughout my code base fail with weird type errors because -XThis no longer implies -XThat" are unnecessary and can be largely avoided by providing a stable dialect. How often you can upgrade GHC directly depends on how much pain an upgrade causes. For at least one commercial user, that frequency is currently around once every 3 years solely because of how painful upgrades are. 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. Roman

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/

If I may summarise the last few messages on this thread, it seems to me that, so far, everybody agrees that it would be beneficial to have two or more categories of extensions that come with different expectations of stability. (Whether that is by marking them as stable or annotating them with versions or years are details we will figure out.) Richard, I do understand your fear about not being able to move quickly, and I think, we all want to preserve that property of Haskell. However, I would like us to think about how we can preserve agility, while providing sufficient stability. (I know that is hard, but easy problems are boring, so let’s rise to the challenge.) As I said, in my previous message, I consider Haskell Prime to be dead (for all practical purposes). There will be no more Haskell standard. The closest thing to a Haskell standards committee —namely, the ”GHC Haskell” standards committee— is this group! The plan with LANGUAGE extensions was that they do migrate into the standard when they are stable. This is no longer going to happen. Hence, *we* owe it to GHC’s users to make that determination on an extension by extension basis and enforce it through the proposals process. Now, we can discuss the details: * What categories are there? * How long do extensions remain agile? * How do we make the determination when to promote an extension to a more stable category? Before we get too tied up in the details, I would like to discuss two higher-order points: * Do we all agree that we need categories of stabilities for extensions (for the reasons outlined above)? * Can we agree that we cannot leave it solely to extension authors to assign stabilities? (In particular, we already have lots of extensions and we need to take care of those.) Why not leave it to extension authors? They have no (direct) interest in stability. We are the gate keepers. It is our job. Cheers, Manuel PS: There is also the issue of libraries, but that is really the responsibilities of the Core Libraries Committee (and maybe we have to have a chat with them). PPS: This is also very much a beginner issue. Experts know from experience which extensions are stable. Newcomers often ask, what can I safely use? It’s not spelled out anywhere. (Ping Chris.)

Richard Eisenberg :

...

On Oct 18, 2017, at 4:49 PM, Joachim Breitner wrote:

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.

Yes, this is exactly what I was thinking. For example, TypeFamilies might have been marked as stable before closed type families came about... but then we would just have -XClosedTypeFamilies -- not so horrible.

...

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.

This, too, is exactly what I was thinking. Industrial users and book authors have the most to gain from an extension being marked as stable. I would expect that proposals would come from these groups marking extensions as stable, and then we could have a debate.

Richard _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

| If I may summarise the last few messages on this thread, it seems to | me that, so far, everybody agrees that it would be beneficial to have | two or more categories of extensions that come with different | expectations of stability. I'm much happier with this than with -XStaticPointers1 -XStaticPointers2 etc. Once we had such categories, we could use the GHC proposals process itself to allow people to propose moving a flag from 'experimental' to 'stable' or whatever. Simon | -----Original Message----- | From: ghc-steering-committee [mailto:ghc-steering-committee- | bounces@haskell.org] On Behalf Of Manuel M T Chakravarty | Sent: 19 October 2017 02:09 | To: Richard Eisenberg | Cc: ghc-steering-committee@haskell.org; Joachim Breitner | | Subject: Re: [ghc-steering-committee] Proposal: Type Fixity (#65), | Consensus: accept, own language extension? | | If I may summarise the last few messages on this thread, it seems to | me that, so far, everybody agrees that it would be beneficial to have | two or more categories of extensions that come with different | expectations of stability. (Whether that is by marking them as stable | or annotating them with versions or years are details we will figure | out.) | | Richard, I do understand your fear about not being able to move | quickly, and I think, we all want to preserve that property of | Haskell. However, I would like us to think about how we can preserve | agility, while providing sufficient stability. (I know that is hard, | but easy problems are boring, so let’s rise to the challenge.) | | As I said, in my previous message, I consider Haskell Prime to be dead | (for all practical purposes). There will be no more Haskell standard. | The closest thing to a Haskell standards committee —namely, the ”GHC | Haskell” standards committee— is this group! | | The plan with LANGUAGE extensions was that they do migrate into the | standard when they are stable. This is no longer going to happen. | Hence, *we* owe it to GHC’s users to make that determination on an | extension by extension basis and enforce it through the proposals | process. | | Now, we can discuss the details: | | * What categories are there? | * How long do extensions remain agile? | * How do we make the determination when to promote an extension to a | more stable category? | | Before we get too tied up in the details, I would like to discuss two | higher-order points: | | * Do we all agree that we need categories of stabilities for | extensions (for the reasons outlined above)? | * Can we agree that we cannot leave it solely to extension authors to | assign stabilities? (In particular, we already have lots of extensions | and we need to take care of those.) | | Why not leave it to extension authors? They have no (direct) interest | in stability. We are the gate keepers. It is our job. | | Cheers, | Manuel | | PS: There is also the issue of libraries, but that is really the | responsibilities of the Core Libraries Committee (and maybe we have to | have a chat with them). | | PPS: This is also very much a beginner issue. Experts know from | experience which extensions are stable. Newcomers often ask, what can | I safely use? It’s not spelled out anywhere. (Ping Chris.) | | > Richard Eisenberg : | >> On Oct 18, 2017, at 4:49 PM, Joachim Breitner wrote: | >> | >> 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. | >> | > | > Yes, this is exactly what I was thinking. For example, TypeFamilies | might have been marked as stable before closed type families came | about... but then we would just have -XClosedTypeFamilies -- not so | horrible. | > | >> 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. | > | > This, too, is exactly what I was thinking. Industrial users and book | authors have the most to gain from an extension being marked as | stable. I would expect that proposals would come from these groups | marking extensions as stable, and then we could have a debate. | > | > Richard | > _______________________________________________ | > ghc-steering-committee mailing list | > ghc-steering-committee@haskell.org | > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- | committ | > ee | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- | committee

The plan with LANGUAGE extensions was that they do migrate into the standard when they are stable. This is no longer going to happen. Hence, *we* owe it to GHC’s users to make that determination on an extension by extension basis and enforce it through the proposals process.

I agree.

Now, we can discuss the details: * What categories are there? * How long do extensions remain agile? * How do we make the determination when to promote an extension to a more stable category?

My suggestion would be to keep the categories minimal and focused on the way they function in the compiler-as-user-interface: - Must be manually enabled. We can (should?) accompany unstable or potentially unsafe extensions with warnings describing those caveats, but I don't think building an ontology of stableness would be productive. - Must be manually disabled. I would love to nominate ScopedTypeVariables for this but I'm sure there are caveats to STV I haven't yet encountered. This status implies the extension is a candidate for eventual incorporation. - Incorporated. Cannot be disabled in GHC Haskell, considered part of the language (standard?) proper now. If you wanted to extend an extension in the defaulted state, you would create a new extension and it starts at the first stage. The new extension modifying an existing feature must prove itself to be stable and worthwhile of defaulting or later incorporation independently of the feature it modified.

* Can we agree that we cannot leave it solely to extension authors to assign stabilities? (In particular, we already have lots of extensions and we need to take care of those.) Why not leave it to extension authors? They have no (direct) interest in stability. We are the gate keepers. It is our job.

I agree with this, extension authors cannot be solely responsible for ascertaining how stable something is or where it is on the path to becoming defaulted or incorporated.

PPS: This is also very much a beginner issue. Experts know from experience which extensions are stable. Newcomers often ask, what can I safely use? It’s not spelled out anywhere. (Ping Chris.)

There are three main areas where the extensions issue tends to rankle me: 1. As a working user of Haskell that touches a lot of libraries, does a lot of throw-away projects as experiments, I've had to start using hpack (http://hackage.haskell.org/package/hpack) to generate my Cabal files. Some of the motivation for that has been to have a single global list of default-extensions that apply to all of the project's build/test/bench target stanzas. I do this often enough that I copy and paste the default-extensions list between projects not even bothering to weed out the unnecessary ones on the assumption I'll need them eventually anyway. This might seem careless but I toss up a lot of experiments, tutorials, and demonstrations and I don't want to keep having to restart my REPL session because I forgot something. Example of my copied-and-pasted default-extensions: default-extensions: - ConstraintKinds - DataKinds - DeriveFunctor - DeriveGeneric - FlexibleContexts - FlexibleInstances - FunctionalDependencies - GADTs - ImplicitParams - LambdaCase - MultiParamTypeClasses - OverloadedStrings - PartialTypeSignatures - QuasiQuotes - RankNTypes - RecordWildCards - TemplateHaskell - TypeFamilies - TypeOperators - ScopedTypeVariables - UndecidableInstances I realize not all of these are benign. I'll cross that bridge when it someday bites me after over 5 years of using Haskell. I think the only nasty/dead-end ones I've run into have been incoherent instances (Hail Oleg) and impredicative types. Which I hear could be fixed maybe? That'd be neat. FWIW, SafeHaskell is not representative of what's considered "safe" for GHC extensions among the Haskell users I talk to. Different understanding/standard of "safe", possibly partly because we don't have reproducible builds anyway? Stephen Diehl's Haskell tutorial is the usual citation for what extensions are benign/potentially dangerous: http://dev.stephendiehl.com/hask/#the-benign 2. Extensions get weaponized in PL polemics as incontrovertible proof of how "complicated" GHC Haskell is or how much Haskell "needs" before it's a complete language. I admit this isn't strictly within our remit but it is very tiresome. 3. #2 then leads to: new people terrified of turning on an extension even when it's benign and exactly what they want to do at that particular moment. Even in cases where GHC is telling them to do it. Related to new-people-fear is new users believing extensions must be hopelessly complicated if they extend an already seemingly difficult-to-learn language. I don't think we'll ever be totally rid of extensions and I'm not sure it'd be a good thing if we were. If we could make extension-spam the exception rather than the rule on the non-libraries I work on I think that would be a tremendous improvement to peoples' perception of complexity and difficulty. And to be clear, I think it's mostly perception. I've been able to teach RankNTypes to otherwise new Haskell users quite successfully in the past, with the main prerequisites being a sound understanding of polymorphism and variable binding. Thank you Manuel, this is great. On Wed, Oct 18, 2017 at 8:08 PM, Manuel M T Chakravarty wrote:

If I may summarise the last few messages on this thread, it seems to me that, so far, everybody agrees that it would be beneficial to have two or more categories of extensions that come with different expectations of stability. (Whether that is by marking them as stable or annotating them with versions or years are details we will figure out.)

Richard, I do understand your fear about not being able to move quickly, and I think, we all want to preserve that property of Haskell. However, I would like us to think about how we can preserve agility, while providing sufficient stability. (I know that is hard, but easy problems are boring, so let’s rise to the challenge.)

As I said, in my previous message, I consider Haskell Prime to be dead (for all practical purposes). There will be no more Haskell standard. The closest thing to a Haskell standards committee —namely, the ”GHC Haskell” standards committee— is this group!

The plan with LANGUAGE extensions was that they do migrate into the standard when they are stable. This is no longer going to happen. Hence, *we* owe it to GHC’s users to make that determination on an extension by extension basis and enforce it through the proposals process.

Now, we can discuss the details:

* What categories are there? * How long do extensions remain agile? * How do we make the determination when to promote an extension to a more stable category?

Before we get too tied up in the details, I would like to discuss two higher-order points:

* Do we all agree that we need categories of stabilities for extensions (for the reasons outlined above)? * Can we agree that we cannot leave it solely to extension authors to assign stabilities? (In particular, we already have lots of extensions and we need to take care of those.)

Why not leave it to extension authors? They have no (direct) interest in stability. We are the gate keepers. It is our job.

Cheers, Manuel

PS: There is also the issue of libraries, but that is really the responsibilities of the Core Libraries Committee (and maybe we have to have a chat with them).

PPS: This is also very much a beginner issue. Experts know from experience which extensions are stable. Newcomers often ask, what can I safely use? It’s not spelled out anywhere. (Ping Chris.)

...

Richard Eisenberg :

...

On Oct 18, 2017, at 4:49 PM, Joachim Breitner wrote:

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.

Yes, this is exactly what I was thinking. For example, TypeFamilies might have been marked as stable before closed type families came about... but then we would just have -XClosedTypeFamilies -- not so horrible.

...

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.

This, too, is exactly what I was thinking. Industrial users and book authors have the most to gain from an extension being marked as stable. I would expect that proposals would come from these groups marking extensions as stable, and then we could have a debate.

Richard _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-- Chris Allen Currently working on http://haskellbook.com