<div dir="ltr">Dear all,<br><br>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.<br><br>1.1: yes<br>1.2: yes<br>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.<br><br>2.1: no<br>2.2: no<br>2.2.N: I think I'd push such code-style rules into a linter<br><br>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<br>3.2: yes<br>3.2.Y: no, I'd say GHC20xx embodies the opposite of this use-case<br><br>4.1: no<br>4.2: no<br>4.2.N: like (2), I'd rather use a linter<br><br>5.1: yes<br>5.2: no<br>5.2.N: I'd name things in the manual. Actually, this is something Haskell has historically been rather good at.<br><br>6.1: yes for those who can't be avoided (e.g. printing unicode, but not parsing unicode)<br>6.2: no<br>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.<br><br>7.1: yes<br>7.2: no, though extensions have proved decent at it, so not a hill I would die on<br>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.<br><br>8.1: yes<br>8.2: yes<br>8.2.Y: yes. As I imagine that pegging to a particular GHC20xx version would keep the deprecated feature going.<br><br>9.1: no, though I admit it can be argued.<br>9.2: yes<br>9.2.Y: yes, if we keep support GHC20xx version indefinitely we'd de facto keep deprecated behaviour indefinitely.<br><br>10.1: no<br>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.<br>10.2.Y: no<br><br>11.1: yes<br>11.2: yes<br>11.2.Y: yes, as these extensions can eventually become the standard behaviour.<br><br>12.1: yes<br>12.2: yes<br>12.2.Y: no<br><br>13.1: no (but this is obviously a ship that has long sailed)<br>13.2: yes<br>13.2.Y: no</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 20 Apr 2023 at 11:42, Joachim Breitner <<a href="mailto:mail@joachim-breitner.de">mail@joachim-breitner.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
Am Mittwoch, dem 19.04.2023 um 14:20 +0200 schrieb Arnaud Spiwack:<br>
> The 13 use-cases are<br>
> <br>
> 1. Gain early access to experimental or unstable features<br>
> (e.g. because they're working on a research prototype, or because<br>
> the feature is valuable enough to them to forgo some stability)<br>
<br>
1: Yes, worthwhile usecase.<br>
2: Yes, Extensions serve this well.<br>
2Y: By definition GHC20xx doesn’t help, because it doesn’t touch<br>
experimental or unstable features.<br>
<br>
> 2. Restrict the use of more complex features (e.g. for easier<br>
> onboarding of new developers or as educators to teach a<br>
> well-delimited subset of the language)<br>
<br>
1: No, I don’t think that’s a task that the compiler is necessary best<br>
suited for. At least not at the current “accidential” complexity – if<br>
there was a push for real language levels as a first-class, well<br>
designed feature, things would be different.<br>
<br>
2: No. They kinda work, but maybe warning flags are more suitable.<br>
<br>
2N: Waring flags or, maybe better, external tools (hlint).<br>
<br>
> 3. Restrict the use of novel features since the last established<br>
> standard/report.<br>
<br>
1: Yes, worthwhile to support. Although I’d phrase it dually: It’s<br>
worthwhile for GHC to support, in addition to “current GHC Haskell”,<br>
the standardized dialects.<br>
<br>
2: Yes, kinda.<br>
2Y: Yes, at least in the general sense that GHC20xx, like Haskell2021,<br>
selects a language dialect alltogether, instead of having to turn off<br>
and on individual flags.<br>
<br>
> 4. Restrict the use to features that they don't like (e.g.<br>
> controversial<br>
> features like RecordWildcard or ImplicitParameters)<br>
<br>
Same answers as for 2.<br>
<br>
> 5. Name/refer to a particular feature when talking/writing/searching<br>
> about it.<br>
<br>
1: Yes, very useful to have names for things!<br>
<br>
2: I’m unsure. The extension names work quite well. But if this would<br>
be come an actively supported use-case (rather than an accidential<br>
one), should we come up with names for existing things as well?<br>
(-XWhereBindings). It doens’t seem to be a good idea to couple “well-<br>
identified feature with a clear name” and “compiler flag”<br>
<br>
> 6. Restrict the use of features which require support from outside<br>
> the Haskell ecosystem that can't be taken for granted (I think<br>
> this<br>
> concerns only UnicodeSyntax)<br>
<br>
Again similar to 2. I don’t see anything wrong with GHC just accepting<br>
unicode syntax when it encounters them, just like it accepts non-ASCII<br>
variable names.<br>
<br>
(This is independent of whether GHC should print syntax in Unicode<br>
style unless asked to do it, but that’s not a language design<br>
question.)<br>
<br>
> 7. As library authors, to signal which features the library actually<br>
> uses, hence which version of GHC the library is compatible with.<br>
<br>
<br>
1: Yes, useful.<br>
<br>
2: Possibly, but that would require a more defined story about<br>
backwards compatibility within an extension. Can we change extensions?<br>
Or only those that are somehow labeled to be more stable?<br>
<br>
2Y: It could help if “being in GHC20xx” is used as a proxy for “kinda<br>
stable”, which is a prerequisite for this signallingto work reliably.<br>
<br>
2N: That said, I don’t see much benefit of using this indirect compat<br>
signalling over just stating in the library which GHC versions it is<br>
known to work with, just like we do with library dependencies.<br>
<br>
> 8. Retain access to deprecated features to smooth out migration over<br>
> the deprecation period.<br>
<br>
1: Yes, useful. Similar to question 3<br>
<br>
2: Yes<br>
2Y: Yes, by using an older GHC20xx one pins an older feature set,<br>
possibly including deprecated versions. This decouples “upgrading GHC”<br>
and “adopting the code base to the new dialect”, which should make life<br>
easier for developers.<br>
<br>
> 9. Retain access to deprecated features indefinitely.<br>
<br>
1: Unsure. Depends on how commonly used it is, and how expensive it is<br>
to carry around.<br>
<br>
> 10. Change the default behaviour of (part of) the language<br>
> (e.g. StrictData, I think some of the dependent Haskell work<br>
> falls<br>
> in this category, but I can't pinpoint an example)<br>
<br>
1: I’m leaning to say no. Haskell + StrictData is a different language,<br>
and one that we can’t envision to be the default (I’d say). That use<br>
case should ideally be addressed in a different way that is a language<br>
extension, not a language change.<br>
<br>
2: No<br>
2N: Annotations maybe, or a new keyword?<br>
<br>
> 11. Extend the language in a way that is not backward compatible<br>
> (e.g. OverloadedList, probably some dependent Haskell things too)<br>
<br>
1: Strong yes. Barring ourselves from making changes that may affect<br>
some existing programs is no longer avoiding success at all costs.<br>
<br>
2: Yes<br>
2Y: Yes, definitely: It means that the programmer is in control when to<br>
apply a change like OverloadedStrings which may require some code<br>
changes.<br>
<br>
> 12. Enable features whose mere presence has a performance impact<br>
> (e.g. Template Haskell, and that's probably it)<br>
<br>
1: Yes.<br>
<br>
2: No, a dedicated pragma would probably be cleaner, but willing to<br>
entertain that single odd case.<br>
<br>
It would also be more consistent to always _parse_ the TH syntax (to<br>
avoid breakage when it is enabled, and to make reading code less<br>
ambiguous), and simply fail if the pragma is not set given.<br>
<br>
<br>
> 13. CPP (this one is very unique isn't it?)<br>
<br>
1: Yes<br>
2: Again, dedicated pragma might be cleaner. Also helps programs<br>
parsing Haskell programs if the information is _always_ local in the<br>
file.<br>
<br>
<br>
<br>
<br>
Cheers,<br>
Joachim<br>
-- <br>
Joachim Breitner<br>
<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a><br>
<a href="http://www.joachim-breitner.de/" rel="noreferrer" target="_blank">http://www.joachim-breitner.de/</a><br>
<br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>