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

[Adam Gundry]

I'm not convinced we should strive to eliminate all extensions as either 
"successful" (part of the default language), or "failed" experiments 
(deprecated and perhaps eventually removed). While it is surely good to 
reduce the proliferation of extensions that can itself be a source of 
confusion, there are still benefits to distinguishing "language levels". 
The right choice of language features can be context dependent, and 
invoking more powerful features is always a trade-off, so I think it is 
a positive virtue that LANGUAGE pragmas let us pass that choice to 
users/codebases. AntC made a good comment to this effect at 
https://github.com/ghc-proposals/ghc-proposals/pull/559#issuecomment-1336059655.

By all means let's reduce the number of trivial syntactic extensions 
that exist primarily for backwards compatibility purposes. But for 
semantically meaningful extensions, I would rather make the ability to 
choose language features even more local, so that a user can tightly 
constrain their use to where they are needed, for example:

   module M where
     -- I would like GHC to complain if I accidentally risk compile time
     -- non-termination with this instance...
     instance ... => Foo T

     -- but for this one I need to lift the check, and have accepted the
     -- corresponding responsibility to ensure the instance is sensible.
     language UndecidableInstances where
       instance ... => Bar T

Cheers,

Adam


On 08/12/2022 17:53, Simon Peyton Jones wrote:
>     The choice can be:...
>     My point is: we need to take an explicit stance and record it.
> 
> 
> Do you want to lay out
> * the problem you want to solve
> * a set of possible choices that might solve it
> 
> Personally I don't perceive an immediate problem that we need to solve.  
> But I'm an outlier and willing to be educated.
> 
> 
> 
> On Thu, 8 Dec 2022 at 17:30, Arnaud Spiwack <arnaud.spiwack at tweag.io 
> <mailto:arnaud.spiwack at tweag.io>> wrote:
> 
>     Personally, my concern is primarily procedural. There is no official
>     stance on what an extension can be, so different people map
>     different concepts on them. As a result, we have a lot of
>     conversations (in here, in proposal threads) where everybody speaks
>     past one another. What I would like is that we come together and
>     design a principle saying: we strive for future extensions to be X.
>     This would clarify discussions around
>     - Is a new extension X appropriate?
>     - Should extension X imply extension Y?
>     - Should extension X be included in GHC20XX?
> 
>     My personal (strong) preference is for striving for extensions to
>     either become a default, eventually, or to be deprecated. It also
>     seems to be the preference of most of those who spoke up here. But
>     what really matters is that we make a choice. The choice can be: “An
>     extension is a switch that triggers optional behaviour in the
>     language, it can be used to gate advanced features, some (but
>     probably not all) of these extensions will become defaults if their
>     use is generalised enough”, I'd disagree with the choice, but I'd
>     champion it anyway. Note that this option is compatible with the
>     no-language-fork principle.
> 
>     My point is: we need to take an explicit stance and record it.
> 
>     /Arnaud
> 
>     On Mon, 5 Dec 2022 at 22:03, Chris Dornan <chris at chrisdornan.com
>     <mailto:chris at chrisdornan.com>> wrote:
> 
>         Now I am sorry — my tongue was in my cheek in talking about the
>         thread taking an authoritarian turn!
> 
>         I think we can al agree that there is a cost to adding more and
>         more extensions, and bear the mounting complexity in mind when
>         scrutinising these proposals, and try to steer this review
>         process towards a coherent future language. At least that is my
>         understanding of the spirit of what Joachim is getting at when
>         he initiated this thread, in which case count me in. My point is
>         just that we don’t also forget certain necessary messy realities
>         in attempting to unwind ourselves from the ‘excessive’
>         complexity that our open, experimental philosophy/DNA will tend
>         to generate.
> 
>         I would love to here more from Simon venting on what needs to
>         happen, ideally down the pub, but, more practically, we might
>         have to make do with a virtual one…
> 
>         Chris
> 
> 
>>         On 5 Dec 2022, at 19:03, Simon Marlow <marlowsd at gmail.com
>>         <mailto:marlowsd at gmail.com>> wrote:
>>
>>         Apologies, I didn't mean to sound like I wanted us to be
>>         "authoritarian", perhaps more along the lines of
>>         "opinionated". By analogy with the CLC: they are forced to
>>         make decisions, because there is only one set of core
>>         libraries. I don't necessarily agree with all the decisions
>>         that the CLC makes, but I'm very glad we only have one set of
>>         core libraries.
>>
>>         In GHC we have the dubious luxury of being able to give people
>>         optional language features, I'm suggesting we should use this
>>         very carefully and avoid forks - which is our current policy
>>         anyway - but to be more intentional about it in the way that
>>         Joachim suggested. I'm also a fan of an open platform that
>>         encourages experimentation, but at some point we have to
>>         accept (I believe) that too much of this leads to a poor
>>         experience for new users. (that's putting it gently! I'm
>>         itching to rant about this some more, but I fear it may come
>>         across poorly. One for the pub.)
>>
>>         Cheers
>>         Simon
>>
>>         On Fri, 2 Dec 2022 at 19:04, Chris Dornan
>>         <chris at chrisdornan.com <mailto:chris at chrisdornan.com>> wrote:
>>
>>             I think we are on the same page, but the thread seemed to
>>             be taking an authoritarian turn so I thought it best to
>>             ensure the voices of caution were represented!
>>
>>             Chris
>>
>>             > On 2 Dec 2022, at 17:39, Joachim Breitner
>>             <mail at joachim-breitner.de
>>             <mailto:mail at joachim-breitner.de>> wrote:
>>             >
>>             > Hi,
>>             >
>>             > Am Freitag, dem 02.12.2022 um 17:27 +0000 schrieb Chris
>>             Dornan:
>>             >> I am sympathetic to the idea of a new language standard
>>             that we
>>             >> promote heavily and encourage developers, tools,
>>             tutorials and
>>             >> courseware to favour —if we get this right then we will
>>             reap the
>>             >> benefits of a strong standard. But if we take it upon
>>             ourselves to
>>             >> try and force an extension combination of our choosing
>>             on the
>>             >> community because we believe the community will benefit
>>             from a big
>>             >> reset then I think it could blow up on us really badly,
>>             with forks
>>             >> and factions which could be truly difficult to manage —
>>             and fatally
>>             >> discourage adoption.
>>             >
>>             > ah, sorry if I was unclear. I am certainly not proposing
>>             a form of “big
>>             > reset”!  It’s more about “should every language
>>             extension be in
>>             > principle on track towards in inclusion to a future
>>             GHC20xx” – still
>>             > all incremental and cautious.
>>             >
>>             > Cheers,
>>             > Joachim

-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890
27 Old Gloucester Street, London WC1N 3AX, England