That's good vocabulary.
One other dimension:
* Is the extension *stable* or *experimental*.
By "stable* I mean that we will make efforts not to gratuitously change its meaning. By "experimental" I mean that its meaning may change in future, or the extension may disappear altogether.
Consequence: if you are building a long-lived library, you probably want to avoid relying on experimental features, because they may change or disappear, in which case you'll have to update your library.
Most features we discuss are intended to be stable. The OverloadedRecordUpdate sounds more experimental at this stage.
| That leaves the question of whether we should allow for any permanent
| extensions.
I didn't understand this bit. We have *lots* of permanent extensions. Indeed everything in GHC2021 is permanent by definition (we've made them part of the GHC2021 language) isn't it?
Simon
| -----Original Message-----
| From: ghc-steering-committee On Behalf Of Eric Seidel
| Sent: 05 March 2021 01:39
| To: ghc-steering-committee@haskell.org
| Subject: Re: [ghc-steering-committee] What is an extension? (was:
| Modification to record dot syntax propsal)
|
| On Thu, Mar 4, 2021, at 15:01, Richard Eisenberg wrote:
| > I think this all comes back to: What does an extension mean? I think
| > it means that users are opting into a language feature. For me, the
| > existence of an extension emphatically does *not* mean that the
| > extension is potentially part of some future standard. I think this
| > viewpoint is different for others of us, and it's worth having a
| > conversation about this. I may start that conversation soon, if no
| one
| > beats me to it.
|
| Let's go ahead and have this conversation. Here are a few questions
| that come to mind:
|
| - Does an extension *expand* the language or *change* it? In other
| words, does an extension strictly accept more programs than before, or
| can it change the meaning of existing programs, or even reject
| previously valid programs?
|
| - Is an extension *transitional* or *permanent*? Do we expect the
| extension to eventually be on-by-default and effectively disappear, or
| will it continue to be opt-in?
|
| - Is an extension *contained* within a module or is it *infectious*?
| Does my choice of extensions when writing a module affect which
| extensions downstream clients must enable? (I would say most
| extensions are contained, e.g. you can apply a type family without
| enabling TypeFamilies or match on a pattern synonym without enabling
| PatternSynonyms. However, you cannot call a function that takes an
| implicit parameter without enabling ImplicitParams.)
|
| The "no-fork" criterion for evaluating proposals argues that all
| extensions should be transitional, but does not address the other
| questions. I think extensions that change the language or are
| infectious should meet a higher bar to be accepted, but we should not
| reject them outright. If we agree that the proposal would improve the
| language, we should allow for some disruption. I don't think we should
| aim for backwards compatibility at any cost.
|
| That leaves the question of whether we should allow for any permanent
| extensions. I think the most important aspect of the "no-fork"
| criterion is that permanent extensions that change the language or
| infect downstream modules are bad. This is where you start to create
| truly incompatible dialects of the language. During the GHC2021
| discussion, a few of us (myself included) voiced support for something
| along the lines of language levels: extensions that add more advanced
| features to the language like FFI or fancy types, and that you might
| want to contain to a subset of modules to facilitate reasoning about
| your code. In other words, permanent extensions are acceptable so long
| as they both expand the language and are contained within a module.
|
| So I think there are three classes of reasonable extensions:
|
| 1. transitional AND expand AND contained: this class is hopefully
| uncontroversial 2. transitional AND (change OR infectious): we should
| have the ability to make big changes, but should use it judiciously 3.
| permanent AND expand AND contained: extensions are a handy way to
| indicate that a module deals with more advanced areas of the language
| (and can serve to isolate those concerns)
|
| Eric
| _______________________________________________
| ghc-steering-committee mailing list
| ghc-steering-committee@haskell.org
| https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
| .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
| committee&data=04%7C01%7Csimonpj%40microsoft.com%7Ce1d6aea762ee415
| 54ba308d8df7788ee%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6375050
| 51854197326%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
| IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=33rA74unELy12hNzQKI%
| 2BBkrv%2Fwt3067zTiFoM4j6lXI%3D&reserved=0
