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

[Simon Peyton Jones]

>
> 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.
>

Strong +1

Simon

On Tue, 13 Dec 2022 at 17:09, Chris Dornan <chris at chrisdornan.com> wrote:

> 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>
> 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>
>> 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
>>>   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
>>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> 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/89402913/attachment.html>