[ghc-steering-committee] Language Extension Policy – Round 2

Wed Apr 26 11:00:00 UTC 2023

Dear all,

I'm currently on holiday. I've scheduled this email to be sent before I
left. Remember to vote if you haven't voted yet: I'll be back next week and
tally the results some time during said week. Let me take the opportunity
to send in my votes.

1.1: yes
1.2: yes
1.2.Y: yes: extensions rolled in GHC20xx are clearly marked as no longer
experimental. GHC20xx can have a stronger policy for backward compatibility
clearly marking extensions which are at risk of making non-forward
compatible code.

2.1: no
2.2: no
2.2.N: I think I'd push such code-style rules into a linter

3.1: no I think that the report has lost relevance in practice. Nobody is
willing to come up with the next version, and GHC20xx has taken its place
3.2: yes
3.2.Y: no, I'd say GHC20xx embodies the opposite of this use-case

4.1: no
4.2: no
4.2.N: like (2), I'd rather use a linter

5.1: yes
5.2: no
5.2.N: I'd name things in the manual. Actually, this is something Haskell
has historically been rather good at.

6.1: yes for those who can't be avoided (e.g. printing unicode, but not
parsing unicode)
6.2: no
6.2.N: It should simply be a flag. E.g. for printing unicode in error
messages this is something that you may want to configure globally for your
machine rather than for a project.

7.1: yes
7.2: no, though extensions have proved decent at it, so not a hill I would
die on
7.2.N: version bounds seem to me sufficient, and since they are still
necessary, I don't see why we would need to pay attention to this aspect in
the design of extensions.

8.1: yes
8.2: yes
8.2.Y: yes. As I imagine that pegging to a particular GHC20xx version would
keep the deprecated feature going.

9.1: no, though I admit it can be argued.
9.2: yes
9.2.Y: yes, if we keep support GHC20xx version indefinitely we'd de facto
keep deprecated behaviour indefinitely.

10.1: no
10.2: yes. Not that I think that extensions are a good way to do this, but
I can't think of a better way.
10.2.Y: no

11.1: yes
11.2: yes
11.2.Y: yes, as these extensions can eventually become the standard
behaviour.

12.1: yes
12.2: yes
12.2.Y: no

13.1: no (but this is obviously a ship that has long sailed)
13.2: yes
13.2.Y: no

On Thu, 20 Apr 2023 at 11:42, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> Am Mittwoch, dem 19.04.2023 um 14:20 +0200 schrieb Arnaud Spiwack:
> > The 13 use-cases are
> >
> > 1. Gain early access to experimental or unstable features
> >    (e.g. because they're working on a research prototype, or because
> >    the feature is valuable enough to them to forgo some stability)
>
> 1: Yes, worthwhile usecase.
> 2: Yes, Extensions serve this well.
> 2Y: By definition GHC20xx doesn’t help, because it doesn’t touch
> experimental or unstable features.
>
> > 2. Restrict the use of more complex features (e.g. for easier
> >    onboarding of new developers or as educators to teach a
> >    well-delimited subset of the language)
>
> 1: No, I don’t think that’s a task that the compiler is necessary best
> suited for. At least not at the current “accidential” complexity – if
> there was a push for real language levels as a first-class, well
> designed feature, things would be different.
>
> 2: No. They kinda work, but maybe warning flags are more suitable.
>
> 2N: Waring flags or, maybe better, external tools (hlint).
>
> > 3. Restrict the use of novel features since the last established
> >    standard/report.
>
> 1: Yes, worthwhile to support. Although I’d phrase it dually: It’s
> worthwhile for GHC to support, in addition to “current GHC Haskell”,
> the standardized dialects.
>
> 2: Yes, kinda.
> 2Y: Yes, at least in the general sense that GHC20xx, like Haskell2021,
> selects a language dialect alltogether, instead of having to turn off
> and on individual flags.
>
> > 4. Restrict the use to features that they don't like (e.g.
> > controversial
> >    features like RecordWildcard or ImplicitParameters)
>
> Same answers as for 2.
>
> > 5. Name/refer to a particular feature when talking/writing/searching
> >    about it.
>
> 1: Yes, very useful to have names for things!
>
> 2: I’m unsure. The extension names work quite well. But if this would
> be come an actively supported use-case (rather than an accidential
> one), should we come up with names for existing things as well?
> (-XWhereBindings). It doens’t seem to be a good idea to couple “well-
> identified feature with a clear name” and “compiler flag”
>
> > 6. Restrict the use of features which require support from outside
> >    the Haskell ecosystem that can't be taken for granted (I think
> > this
> >    concerns only UnicodeSyntax)
>
> Again similar to 2. I don’t see anything wrong with GHC just accepting
> unicode syntax when it encounters them, just like it accepts non-ASCII
> variable names.
>
> (This is independent of whether GHC should print syntax in Unicode
> style unless asked to do it, but that’s not a language design
> question.)
>
> > 7. As library authors, to signal which features the library actually
> >    uses, hence which version of GHC the library is compatible with.
>
>
> 1: Yes, useful.
>
> 2: Possibly, but that would require a more defined story about
> backwards compatibility within an extension. Can we change extensions?
> Or only those that are somehow labeled to be more stable?
>
> 2Y: It could help if “being in GHC20xx” is used as a proxy for “kinda
> stable”, which is a prerequisite for this signallingto work reliably.
>
> 2N: That said, I don’t see much benefit of using this indirect compat
> signalling over just stating in the library which GHC versions it is
> known to work with, just like we do with library dependencies.
>
> > 8. Retain access to deprecated features to smooth out migration over
> >    the deprecation period.
>
> 1: Yes, useful. Similar to question 3
>
> 2: Yes
> 2Y: Yes, by using an older GHC20xx one pins an older feature set,
> possibly including deprecated versions. This decouples “upgrading GHC”
> and “adopting the code base to the new dialect”, which should make life
> easier for developers.
>
> > 9. Retain access to deprecated features indefinitely.
>
> 1: Unsure. Depends on how commonly used it is, and how expensive it is
> to carry around.
>
> > 10. Change the default behaviour of (part of) the language
> >     (e.g. StrictData, I think some of the dependent Haskell work
> > falls
> >     in this category, but I can't pinpoint an example)
>
> 1: I’m leaning to say no. Haskell + StrictData is a different language,
> and one that we can’t envision to be the default (I’d say). That use
> case should ideally be addressed in a different way that is a language
> extension, not a language change.
>
> 2: No
> 2N: Annotations maybe, or a new keyword?
>
> > 11. Extend the language in a way that is not backward compatible
> >     (e.g. OverloadedList, probably some dependent Haskell things too)
>
> 1: Strong yes. Barring ourselves from making changes that may affect
> some existing programs is no longer avoiding success at all costs.
>
> 2: Yes
> 2Y: Yes, definitely: It means that the programmer is in control when to
> apply a change like OverloadedStrings which may require some code
> changes.
>
> > 12. Enable features whose mere presence has a performance impact
> >     (e.g. Template Haskell, and that's probably it)
>
> 1: Yes.
>
> 2: No, a dedicated pragma would probably be cleaner, but willing to
> entertain that single odd case.
>
> It would also be more consistent to always _parse_ the TH syntax (to
> avoid breakage when it is enabled, and to make reading code less
> ambiguous), and simply fail if the pragma is not set given.
>
>
> > 13. CPP (this one is very unique isn't it?)
>
> 1: Yes
> 2: Again, dedicated pragma might be cleaner. Also helps programs
> parsing Haskell programs if the information is _always_ local in the
> file.
>
>
>
>
> Cheers,
> Joachim
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230426/76c3eae3/attachment.html>