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

[Joachim Breitner]

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/