[ghc-steering-committee] Why not?, rather than, why?

[Richard Eisenberg]

I have divided this email into two parts. The first part presents what are my observations of this (and related) conversation. Then I share my opinion in the second part.

> On Dec 8, 2022, at 12:53 PM, Simon Peyton Jones <simon.peytonjones at gmail.com> wrote:
> 
> * the problem you want to solve

We, as a committee, struggle to figure out a policy around extensions. This policy would help inform decisions such as:
 * whether proposal X needs to come with an extension, can modify a previous one, or needs no extension at all
 * how to evolve the set of extensions that are part of GHC20XX / the default set of extensions
Beyond these real-world challenges that the committee has faced, we might also want to consider
 * how better to communicate the role extensions play in the Haskell language (anecdotes suggest the current story is off-putting to newcomers)
 * whether some extensions ought to be retired

While all decisions would continue to be made on a case-by-case basis, discussions in the past have suggested that individual members have very different criteria for making these calls, stymieing effective debate. Thus the problem is that we, the committee, don't have common goals for the extensions feature of the language. Accordingly, our decisions in this space easily risk being incoherent, which is a problem.

> * a set of possible choices that might solve it

I spot several solutions drawn from our conversations:

1. Declare that extensions are experimental language features, being evaluated for inclusion in the language proper. Gating some new syntax behind an extension theoretically allows us to experiment, improve, etc., until we are happy, and then we merge the feature into the language, with no extension needed.
2. Declare that extensions are configuration flags, meant to exist in perpetuity. In this way, extensions are a more powerful form of warning flag: not only can they dictate which programs are accepted, but sometimes they can be used to change the semantics of an accepted program.
3. Organize the set of extensions around an idea of language levels, where we classify different extensions according to the expected level of expertise of users working in the extended language. The levels themselves would exist in perpetuity, but the extensions themselves may eventually just be folded into the choice of language level. This is something of a hybrid between (1) and (2).

Perhaps others have other ideas, but I hope I've captured the different approaches floated so far.

Given the fact that we're working in an existing language, we have to incorporate the reality of today's Haskell: some existing language extensions are unmistakably configuration flags (e.g. RebindableSyntax, Safe) which could never reasonably be on by default. I urge us not to get caught on these snags. Once we have a general approach, we can come back to these if necessary and see how to incorporate them.

-------------------------

I used to be in Camp 2, thinking that extensions make for good configuration flags, and would exist in perpetuity -- or at least until a standards committee forms and writes the next version of the standard. I've now switched over to Camp 1. The extensions system continues to grow without seeming bound. This fragments our community somewhat (think of the various exhortations to only use these extensions), provides a source of unnecessary and bureaucratic complexity to users, and means that language maintainers must consider 2^n languages. (When I last counted, n was around 150. It may have grown since.) What does it even mean that a language has a core and has extensions? We could argue that the unextended language is Haskell2010, but I don't think that's a useful designation in 2022. So why have the distinction between a core and an extension? I'm honestly not sure what the value is there. And I think the current state of this actively harms the language.

Glancing through the list of extensions, I see a few broad categories:

A. Extensions that simply enable new syntax. If users still want fine control over whether this syntax is allowed, each such extension could be converted to a warning -- but then all these extensions (except ones that are still experimental!) would be on by default. Maybe the warnings would be -Werror by default -- not sure. Examples: GADTSyntax, Arrows, InstanceSigs, StandaloneDeriving, and many more.

B. Extensions that allow violation of some general principle that holds elsewhere. These should be replaced by modifiers or pragmas and be enabled locally. Examples: OverlappingInstances (this is already done!), NoMonomorphismRestriction, DeepSubsumption(*), UndecidableSuperClasses, NoMonoLocalBinds, etc.

(*): Given the hue and cry about this one, perhaps there should be a flag to control the behavior.

C. Extensions that change the compilation pipeline. These need to remain as configuration flags. Examples: CPP, TemplateHaskell.

D. Extensions that create variants of the language by changing semantics of existing constructs. I'm not quite sure what to do with these, but they probably need to remain configuration flags. Even better if they could be enabled locally within a file, though. We should probably try to avoid doing this in the future, though the pain may be worth it. Examples: RebindableSyntax, Strict, OverloadedXXX, etc.

Maybe some extensions fail to be categorized here, but this covers the vast, vast majority.

About language levels: I like the idea of language levels. But I would want them to be mostly about error messages, not about gating language features. That is, at level 1, `x :: Just Int` wouldn't get "Did you want to turn on DataKinds?" but instead a message about confusing types and terms. So it's possible to do the language-level idea without hooking it to extensions. I think.

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20221209/8b3232b5/attachment-0001.html>