Aha I see. You meant "transient" = extensions that we expect to include in GHCxxx one day "permanent" = extensions that we would never do that for, like OverlappingInstances, or Strict. Fine. I totally misunderstood that. I'm not sure of better names... Simon | -----Original Message----- | From: Eric Seidel <eric@seidel.io> | Sent: 05 March 2021 14:03 | To: Simon Peyton Jones <simonpj@microsoft.com> | Cc: ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] What is an extension? (was: | Modification to record dot syntax propsal) | | The transient vs permanent dimension is more aspirational than the | others. I would classify extensions that were included in GHC2021 as | transient. The hope is that these extensions eventually make it into | the next Haskell Report, and effectively disappear from our lexicon. | They’re no longer extensions to Haskell, they’re simply part of | Haskell. | | In contrast, extensions like Strict/StrictData have no hope of ever | making it into a future standard, and thus I’d call them permanent. | | Does that make sense? I’d welcome better terminology. | | Sent from my iPhone | | > On Mar 5, 2021, at 03:26, Simon Peyton Jones <simonpj@microsoft.com> | wrote: | > | > 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 <ghc-steering-committee- | > | bounces@haskell.org> 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%2Fma | > | il | > | .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | > | | > | | committee&data=04%7C01%7Csimonpj%40microsoft.com%7Ce1d6aea762ee4 | > | 15 | > | | > | | 54ba308d8df7788ee%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63750 | > | 50 | > | | 51854197326%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu | > | Mz | > | | IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=33rA74unELy12hNzQK | > | I% | > | 2BBkrv%2Fwt3067zTiFoM4j6lXI%3D&reserved=0