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

Tue Dec 13 17:08:58 UTC 2022

It is very fashionable to dunk on GHC language extensions but I think it is worth considering where we would be without them — probably Haskell 98 and a nice Wikipedia page explaining how influential Haskell was — a remarkable academic experiment, but practically speaking, like FP and KRC and Hope, a dead programming language.

I had a period in the late naughties away from Haskell and I thought it was great to be able to work with the familiar Haskell 98 and page in the developments as I needed them, and easily locate documentation, papers and articles on those proposals. The modularity that extensions provide is a real practical strength that is often overlooked.

Further to that, I find it quite difficult to get my head around the sheer vitality of Haskell today. It was tempting to conclude that Haskell2010 would be the last harrah but building Haskell code bases in 2022 is really quite different and a *much* more rewarding and more productive exercise in my opinion, thanks to generics and the ingenious exploration of newtype, especially with DerivingVia. This is really quite separate from all the work on TLP and DH — I am talking about the very practical business of building, organising and maintaining non-trivial Haskell code bases.

I love the way we have become keen to learn from other successes like Rust but I fear we could repeat past mistakes in a dash to force Haskell, and the Haskell community, into a particular shape so that it can compete. I think we should have more confidence in what has got us to where we are — and there is no doubt in my mind that it is the enduring vitality of Haskell that flows from its open philosophy, open to allcomers and open to creative experimentation.

I think the intrinsic diversity we see at all levels of the community is important to that creative process which is why I get a little despondent when I see calls to eliminate that diversity. People see the language extensions in different ways depending on the problems they are trying to solve and those problems are arising in great array of different contexts — and that feeds vitality is what keeps us moving forward (like the proverbial shark). 

I understand that we can’t just allow ourselves to suffer a chaotic heat death and we need a continuous effort to analyse and organise, but I look at the diversity of thought and approaches and see the basis of a vibrant future. I just ask that we seek to organise and not to develop a monoculture.

Which is all by way of saying that I think the diversity we see in the extensions and the different ways of understanding them as important to the whole enterprise and take care with any drives to rationalise them into a more coherent structure. 

Chris

> On 13 Dec 2022, at 09:59, Simon Peyton Jones <simon.peytonjones at gmail.com> wrote:
> 
> Thanks Richard for answering more comprehensively than I could have done myself. Simon: do you feel that Richard's email answers your question?
> 
> It contributes to an answer.  
> 
> The problem(s) we seek to solve
> 
> Richard says
> 
> 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
> 
> I'm OK with those as goals, although I have not found myself stuck on them.  E.g. most proposals do come with an extension because they are, well, an extension.   And user opinions frankly differ about the value and tempo of GHC20XX.
> 
> The proposed solution(s)
> 
> Richard comes up with a couple of categorisations, which are indeed helpful.  But he stops short of any concrete proposals.
> 
> 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.
> 
> These aren't either/or choices.   It's clear that 
> some really are configuration flags (Safe, RebindableSyntax; maybe punning)
> some are definitely local, thin ice (UndecidableSuperclasses) -- the more we can turn these into local modifiers the better
> some are really part of the language we'd like to see (PolyKinds, MultiParamTypeClasses)
> some are experimental in the "Haskell as a laboratory" sense (Linear)
> I think that classifying them might be helpful; choosing one of these paths over the others seems infeasible to me.
> 
> What next?
> 
> I suppose the next step is for some motivated person to write a draft policy paper, so we can say "This is the GHC steering committee's policy on extensions".  Maybe it too can be a GHC proposal (rather like the design principles one).  It can certainly include the categorisations Richard suggests.
> 
> Simon
> 
> 
> 
> On Tue, 13 Dec 2022 at 09:43, Arnaud Spiwack <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>> wrote:
> Thanks Richard for answering more comprehensively than I could have done myself. Simon: do you feel that Richard's email answers your question?
> 
> On Fri, 9 Dec 2022 at 19:57, Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
> Hi,
> 
> this categorization is very helpful, I’ve been thinking about that as
> well recently. Especially it’s worth keeping in mind that some language
> extensions probably wouldn’t be language extensions these days, but
> some other kind of flag (CPP, Safe, Trustworthy), and as you say
> shouldn’t get in the way of finding a more coherent story for the
> others.
> 
> I think we should keep separate the category
> 
> F: Enables new language features with not just a local (usually)
> syntactic effect. (Litmus test: will a user of a module with that
> extension tell). Mostly all the type-level feature extension (GADTs,
> LinearTypes, TypeFamilies etc.)
> 
> Some of these are also guarded by “new syntax” of sorts, but I think
> they are fundamentally different from your category A. These are, in a
> way, the most interesting ones!
> 
> Cheers,
> Joachim
> 
> Am Freitag, dem 09.12.2022 um 14:21 +0000 schrieb Richard Eisenberg:
> > 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.
> 
> -- 
> Joachim Breitner
>   mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>
>   http://www.joachim-breitner.de/ <http://www.joachim-breitner.de/>
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> _______________________________________________
> 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/20221213/4c191206/attachment-0001.html>