[ghc-steering-committee] What is an extension? (was: Modification to record dot syntax propsal)

[Eric Seidel]

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