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

[Simon Peyton Jones]

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 at seidel.io>
|  Sent: 05 March 2021 14:03
|  To: Simon Peyton Jones <simonpj at microsoft.com>
|  Cc: ghc-steering-committee at 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 at 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 at haskell.org> On Behalf Of Eric Seidel
|  > |  Sent: 05 March 2021 01:39
|  > |  To: ghc-steering-committee at 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 at 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