From lists at richarde.dev  Thu Mar  2 13:38:19 2023
From: lists at richarde.dev (Richard Eisenberg)
Date: Thu, 2 Mar 2023 13:38:19 +0000
Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?=
 =?utf-8?b?4oCTIFJvdW5kIDE=?=
In-Reply-To: <CAJKmMz8KyaM4j5vK+4z3je3hxB2F9bCBUChmFFEJqbuEBMzjgA@mail.gmail.com>
References: <CAGwnsnn=rY=Xzwi23HjQ2zGSRAhtqAS8Xi8Em6M5oqfpG3aYWw@mail.gmail.com>
 <010f018684991b10-761d0bd6-4151-41af-9a56-5cce6ff0aeaa-000000@us-east-2.amazonses.com>
 <CANsrgP+VQLop_UyLudEweB0m1ApaXFDPdnTyTTYm+CYJudYN=g@mail.gmail.com>
 <CAJKmMz8KyaM4j5vK+4z3je3hxB2F9bCBUChmFFEJqbuEBMzjgA@mail.gmail.com>
Message-ID: <010f0186a28b88ff-d308e836-2389-4f65-a43d-93312f820f7e-000000@us-east-2.amazonses.com>

Yes, I think eliminating "obvious" extensions from the need for fine scoring is a good idea. Maybe we start by figuring out which these should be? I bet we'll kill off about half of what we have, which is a nice savings.

Richard

> On Feb 28, 2023, at 11:30 AM, Simon Peyton Jones <simon.peytonjones at gmail.com> wrote:
> 
> Shall we start with the three columns I described, and the non-scoring enumerations I suggest, and see where we go?  If it's inadequate we can elaborate.  But let's not start with too many categories etc.
> 
> S
> 
> On Tue, 28 Feb 2023 at 14:45, Simon Marlow <marlowsd at gmail.com <mailto:marlowsd at gmail.com>> wrote:
> We definitely *could* assign every extension a 1-5 score on 6+ different axes, but I have to admit the thought of actually doing this gives me a sinking feeling! Furthermore I'm not sure what we would do with the results. How do we use the scores to decide what goes into GHC20xx? It feels like we're creating a great deal of work for ourselves.
> 
> The idea of categorising rather than scoring is to shortcut the discussion. If we know that some extension is experimental (e.g. LinearTypes), it just goes in the experimental category and we don't need to think about it any more. If we have an extension that is enabling a deprecated feature, again we don't need to consider any other aspects.
> 
> So, perhaps these axes are useful for extensions that are candidates for GHC20xx and not in one of the other categories 2-5 in Arnaud's list. But if we're going to reject extensions from GHC20xx for reasons that are *not* covered by categories 2-5 in Arnaud's list, then we should think about what those reasons might be. Is "breaks too many programs" one of them?
> 
> Cheers
> Simon
> 
> On Fri, 24 Feb 2023 at 18:04, Richard Eisenberg <lists at richarde.dev <mailto:lists at richarde.dev>> wrote:
> Thanks, Arnaud!
> 
> > Q1: Are all the categories 1–5 relevant? If you would like to remove
> >        some categories, which and why (free form)?
> 
> I'm not really sure I understand Category 1. In particular, I think my initial categorization didn't have Arnaud's Category 1, but instead had
> 
> 8. Extensions that enable only new programs, without changing the semantics of any existing program
> 
> This was meant as a counterpoint to 6.
> 
> But my initial categorization was non-orthogonal: for example, this Category 8 overlaps with several other categories. In that way, Joachim's argument that we could imagine two axes of categorization -- one technical, one policy-oriented -- is intriguing. For example, -XDatatypeContexts belongs in Category 8 (it's a syntactic extension), but that doesn't mean it should be on-by-default.
> 
> Along similar lines, Categories 2 and 3 overlap: we might have an experimental language feature that violates a general principle. (Perhaps UndecidableSuperClasses?)
> 
> I tend to think that we'll have an easier time proceeding with 1) orthogonal categories and 2) separation between technical content and policy.
> 
> I thus propose the following taxonomy, where each extension gets rated along each axis.
> 
> A. Is the extension flag purely a language extension? That is, does the flag enable only new programs, without changing the semantics of any existing programs?
> 
> Possible answers: sliding scale 1-5, where 1 means "programs written and widely used today would break and/or change meaning" and 5 means "no programs at all change meaning". It's a sliding scale to account for the fact that e.g. -XTypeFamilies once upon a time meant that all programs retain meanings... except for ones which name a type variable `family`. (Now, `family` is unconditionally a keyword in types, so -XTypeFamilies is, I believe, a 5.) So if there are obscure programs that change meaning, we can use 2, 3, and 4 as a way of stating how obscure the programs are. (Higher number = more obscure.)
> 
> B. How stable is the extension flag?
> 
> Possible answers: sliding scale 1-5, where 1 means "likely to change soon" and 5 means "as unlikely to change as the definition of Monad". (That was chosen deliberately: we *did* change the definition of Monad!) For me, a criterion required to write 5 here would be the possibility of writing down a formal specification of the extension. (So -XGADTs could not be a 5.)
> 
> C. Would a user always want to enable this extension for an entire file (as opposed to for local regions)?
> 
> Possible answers: sliding scale 1-5, where 1 means "there shouldn't even be a way to enable it for a whole file" and 5 means "no -- a user who wants this flag would want it for the whole file". I would put GADTSyntax as a 5 and OverlappingInstances as a 1. GADTs would (for me) be a 4, because maybe someone wants to say that one part of a file is more type-y than the rest.
> 
> D. How much do we like the extension?
> 
> Possible answers: sliding scale 1-5, where 1 means "this shouldn't be here" and 5 means "I want this on by default (ignoring backward compatibility)". -XDatatypeContexts would be a 1: we should never have had that in the language. -XOverloadedStrings would be a 5: even if we don't want it enabled everywhere, it's a vastly useful extension that lots of people depend on.
> 
> E. Does the extension flag change the language, as opposed to the operation of the compiler?
> 
> Possible answers: sliding scale 1-5, where 1 means "purely about the compiler operation" and 5 means "purely about the language". Most extensions (e.g. -XPolyKinds) would be 5; -XCPP would be 1. I would put -XTemplateHaskell around a 4, because it's mostly about the language, but it impacts cross-compilation and recompilation avoidance. -XSafe is a 2: it affects the way instances are selected, I think.
> 
> F. How broad is the use-case for the extension?
> 
> Possible answers: sliding scale 1-5, where 1 means "very specialized" and 5 is "broadly useful in many contexts". I would put -XMultiParamTypeClasses at a 5 and -XMagicHash at a 2. I'm struggling to come up with something so specialized as to be worth a 1. I would say -XTypeFamilies and -XGADTs are 4.
> 
> I think these questions A-F cover the range of categories Arnaud proposes, while addressing Joachim's and Simon M's desires to keep separate things separate. Having each question have a sliding-scale answer is also nice: it means we can submit our classifications of each extension and just average the results. This avoids time wasted in debate. (You can even submit decimals in the range 1-5, if you like!) I would propose that we highlight and debate any question/extension pair where the (max - min) > 2, as there may be disagreement about what the extension or the question means. And we have a natural way to identify candidates for inclusion in GHC20XX: multiply (or add; I think multiply) the 6 scores for an extension and then set a threshold for acceptance. (I don't think we would do this blindly, at all, but it would offer a wonderful starting-point.)
> 
> Having upended the table and made a mess of things, I will now answer the other questions ignoring this new proposal.
> 
> > Q2: Is category 6 relevant?
> 
> Yes, but it's on the wrong axis.
> 
> > Q2.Y: If you found category 6 to be relevant: should it be its own
> >            category, or should it be a subcategory of 1?
> 
> I see 6 and 1 not having a relationship: 6 is about syntax, while 1 is about whether we like an extension.
> 
> > Q3: Is category 7 relevant?
> 
> Yes.
> 
> > Q3.Y: If you found category 7 to be relevant: should it be its own
> >            category or should it be a subcategory of 5?
> 
> Hard to say. MagicHash and UnboxedTuples could in theory be flags. But maybe there are other 7s that wouldn't?
> 
> >  Q4: In which category would you classify Strict?
> 
> 5, in that Strict is a compiler flag, but it doesn't certainly change the language.
> 
> >  Q5: Is there any category that you feel is missing from the list? If
> >        so, please argue (free form).
> 
> I've done that enough already. :)
> 
> Richard
> _______________________________________________
> 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>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230302/325daf4a/attachment.html>

From lists at richarde.dev  Thu Mar  2 23:56:00 2023
From: lists at richarde.dev (Richard Eisenberg)
Date: Thu, 2 Mar 2023 23:56:00 +0000
Subject: [ghc-steering-committee] #540: parallelism semaphores,
 recommendation: *accept*
In-Reply-To: <1be75ca3-1b45-424f-b1a1-8f2ef18ced3c@app.fastmail.com>
References: <555dcb045377d7eb674c5656ecdb47904f5bdbaf.camel@joachim-breitner.de>
 <2183bf1dbe07ed846d08c0468ff3d49f1f1aca3a.camel@joachim-breitner.de>
 <ec71a6e4b62866add3bf906eb4415fa77810d483.camel@joachim-breitner.de>
 <178bd73a-e54f-46d7-b0fd-6999d61162c5@app.fastmail.com>
 <1be75ca3-1b45-424f-b1a1-8f2ef18ced3c@app.fastmail.com>
Message-ID: <010f0186a4c10c7d-4dd05ffa-1088-432b-bb12-6357c3906ce2-000000@us-east-2.amazonses.com>

I didn't know we were voting on this one!

I requested a loud Haddock comment on GitHub, but I'm in support.

Richard

> On Feb 23, 2023, at 1:07 PM, Eric Seidel <eric at seidel.io> wrote:
> 
> Hi all,
> 
> We have votes in favor from Joachim, Arnaud, Chris, Moritz, and Simon M, and silence otherwise.
> 
> Simon PJ, Richard, Vlad, Adam: if you have thoughts or concerns about this proposal, please speak up! 
> 
> On Sun, Feb 12, 2023, at 12:01, Eric Seidel wrote:
>> Hi Committee,
>> 
>> Douglas Wilson, Sam Derbyshire, and Matthew Pickering have proposed 
>> adding support for a job-server to GHC. 
>> 
>> The goal is to allow Cabal and Stack to make optimal use of system 
>> resources when compiling many packages. Currently, the build tools are 
>> forced to choose between 
>> 
>> 1. parallelizing across packages, but compiling each package single-threaded
>> 2. parallelizing within packages, but compiling packages sequentially
>> 
>> There is no correct choice for all build plans, so the authors propose 
>> a lightweight job-server protocol to allow Cabal and GHC to 
>> cooperatively decide on the best parallelization strategy.
>> 
>> The implementation is already done and the changes to GHC are supposed 
>> to be quite self-contained. At a high level GHC's participation in the 
>> protocol is thus:
>> 
>> 1. when invoked with -jsem /path/to/job-server, acquire N job tokens 
>> from the job server
>> 2. call `setNumCapabilities N`
>> 3. compile as usual
>> 4. before exiting, return the tokens to the job server
>> 
>> There are more details in how GHC chooses how many tokens to request, 
>> and more opportunities for optimization, e.g. returning early returning 
>> of unneeded tokens, but this is really the essence of the protocol from 
>> GHC's perspective.
>> 
>> ---
>> 
>> I have two minds about this proposal. On the one hand, it seems likely 
>> to leave performance on the table compared to the alternatives 
>> discussed. But on the other hand, this proposal has already been 
>> implemented and validated by Well-Typed, and it seems like a small 
>> amount of additional complexity for GHC to adapt. (Though I'd love for 
>> someone with more knowledge of GHC internals to opine on the internal 
>> complexity.)
>> 
>> On balance, I think we should accept this proposal and not let the 
>> perfect be the enemy of the good.
>> 
>> https://github.com/ghc-proposals/ghc-proposals/pull/540
>> 
>> Eric
>> 
>> On Wed, Nov 16, 2022, at 14:21, Joachim Breitner wrote:
>>> Hi,
>>> 
>>> Am Dienstag, dem 08.11.2022 um 13:49 +0100 schrieb Joachim Breitner:
>>>> Dear Committee,
>>>> 
>>>> parallelism semaphores
>>>> have been proposed by Douglas Wilson, Sam Derbyshire, Matthew Pickering
>>>> 
>>>> https://github.com/ghc-proposals/ghc-proposals/pull/540
>>>> 
>>>> https://github.com/sheaf/ghc-proposals/blob/jsem/proposals/0540-jsem.rst
>>>> 
>>>> I suggest Adam shepherds this proposal.
>>> 
>>> JFTR: I’m reassigning this to Eric (hope that’s ok for you).
>>> 
>>> Cheers,
>>> Joachim
>>> -- 
>>> 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


From arnaud.spiwack at tweag.io  Mon Mar  6 08:37:43 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Mon, 6 Mar 2023 09:37:43 +0100
Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?=
	=?utf-8?b?4oCTIFJvdW5kIDE=?=
In-Reply-To: <010f0186a28b88ff-d308e836-2389-4f65-a43d-93312f820f7e-000000@us-east-2.amazonses.com>
References: <CAGwnsnn=rY=Xzwi23HjQ2zGSRAhtqAS8Xi8Em6M5oqfpG3aYWw@mail.gmail.com>
 <010f018684991b10-761d0bd6-4151-41af-9a56-5cce6ff0aeaa-000000@us-east-2.amazonses.com>
 <CANsrgP+VQLop_UyLudEweB0m1ApaXFDPdnTyTTYm+CYJudYN=g@mail.gmail.com>
 <CAJKmMz8KyaM4j5vK+4z3je3hxB2F9bCBUChmFFEJqbuEBMzjgA@mail.gmail.com>
 <010f0186a28b88ff-d308e836-2389-4f65-a43d-93312f820f7e-000000@us-east-2.amazonses.com>
Message-ID: <CAGwnsnnXsJTDg5eeVTKdp7O09m9ea9mE5wLHeTMjRzWwEFEYmA@mail.gmail.com>

Dear all,

I waited a bit before answering this thread, as I got quite surprised by
the replies.

First, the categorisation was meant as purely descriptive, and to provide
us with terminology to speak about policy. In retrospect, the fact that I
didn't manage to find a good name for category (1) and that I resorted to
name it after something the extensions might be for should have been a tell
that the conversation was not going to go as planned (also I'm slowly
realising that “experimental” may not really be a category in that sense,
and probably helped getting the conversation confused). Let me add that, in
my opinion, it would be quite premature to actually try and categorise or
grade extensions now, before we have a policy.

Honestly, I think that it's going to be difficult to salvage this approach,
given that there are almost as many different positions on this than
respondents. That being said, I believe that we need some common
terminology or at least a common framework to even start to discuss policy
more deeply, but far from converging, we seem to be diverging as the
conversation progresses.

Maybe the takeaway from this conversation is that it's difficult, at least
at this stage, to find relevant axes on which to classify what extensions
are, so maybe, we ought to be building our terminology on what extensions
are for. Which we could build on the basis of Adam's user-stories. I'll
come up with a new proposal later this week.

/Arnaud



On Thu, 2 Mar 2023 at 14:38, Richard Eisenberg <lists at richarde.dev> wrote:

> Yes, I think eliminating "obvious" extensions from the need for fine
> scoring is a good idea. Maybe we start by figuring out which these should
> be? I bet we'll kill off about half of what we have, which is a nice
> savings.
>
> Richard
>
> On Feb 28, 2023, at 11:30 AM, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
> Shall we start with the three columns I described, and the non-scoring
> enumerations I suggest, and see where we go?  If it's inadequate we can
> elaborate.  But let's not start with too many categories etc.
>
> S
>
> On Tue, 28 Feb 2023 at 14:45, Simon Marlow <marlowsd at gmail.com> wrote:
>
>> We definitely *could* assign every extension a 1-5 score on 6+ different
>> axes, but I have to admit the thought of actually doing this gives me a
>> sinking feeling! Furthermore I'm not sure what we would do with the
>> results. How do we use the scores to decide what goes into GHC20xx? It
>> feels like we're creating a great deal of work for ourselves.
>>
>> The idea of categorising rather than scoring is to shortcut the
>> discussion. If we know that some extension is experimental (e.g.
>> LinearTypes), it just goes in the experimental category and we don't need
>> to think about it any more. If we have an extension that is enabling a
>> deprecated feature, again we don't need to consider any other aspects.
>>
>> So, perhaps these axes are useful for extensions that are candidates for
>> GHC20xx and not in one of the other categories 2-5 in Arnaud's list. But if
>> we're going to reject extensions from GHC20xx for reasons that are *not*
>> covered by categories 2-5 in Arnaud's list, then we should think about what
>> those reasons might be. Is "breaks too many programs" one of them?
>>
>> Cheers
>> Simon
>>
>> On Fri, 24 Feb 2023 at 18:04, Richard Eisenberg <lists at richarde.dev>
>> wrote:
>>
>>> Thanks, Arnaud!
>>>
>>> > Q1: Are all the categories 1–5 relevant? If you would like to remove
>>> >        some categories, which and why (free form)?
>>>
>>> I'm not really sure I understand Category 1. In particular, I think my
>>> initial categorization didn't have Arnaud's Category 1, but instead had
>>>
>>> 8. Extensions that enable only new programs, without changing the
>>> semantics of any existing program
>>>
>>> This was meant as a counterpoint to 6.
>>>
>>> But my initial categorization was non-orthogonal: for example, this
>>> Category 8 overlaps with several other categories. In that way, Joachim's
>>> argument that we could imagine two axes of categorization -- one technical,
>>> one policy-oriented -- is intriguing. For example, -XDatatypeContexts
>>> belongs in Category 8 (it's a syntactic extension), but that doesn't mean
>>> it should be on-by-default.
>>>
>>> Along similar lines, Categories 2 and 3 overlap: we might have an
>>> experimental language feature that violates a general principle. (Perhaps
>>> UndecidableSuperClasses?)
>>>
>>> I tend to think that we'll have an easier time proceeding with 1)
>>> orthogonal categories and 2) separation between technical content and
>>> policy.
>>>
>>> I thus propose the following taxonomy, where each extension gets rated
>>> along each axis.
>>>
>>> A. Is the extension flag purely a language extension? That is, does the
>>> flag enable only new programs, without changing the semantics of any
>>> existing programs?
>>>
>>> Possible answers: sliding scale 1-5, where 1 means "programs written and
>>> widely used today would break and/or change meaning" and 5 means "no
>>> programs at all change meaning". It's a sliding scale to account for the
>>> fact that e.g. -XTypeFamilies once upon a time meant that all programs
>>> retain meanings... except for ones which name a type variable `family`.
>>> (Now, `family` is unconditionally a keyword in types, so -XTypeFamilies is,
>>> I believe, a 5.) So if there are obscure programs that change meaning, we
>>> can use 2, 3, and 4 as a way of stating how obscure the programs are.
>>> (Higher number = more obscure.)
>>>
>>> B. How stable is the extension flag?
>>>
>>> Possible answers: sliding scale 1-5, where 1 means "likely to change
>>> soon" and 5 means "as unlikely to change as the definition of Monad". (That
>>> was chosen deliberately: we *did* change the definition of Monad!) For me,
>>> a criterion required to write 5 here would be the possibility of writing
>>> down a formal specification of the extension. (So -XGADTs could not be a 5.)
>>>
>>> C. Would a user always want to enable this extension for an entire file
>>> (as opposed to for local regions)?
>>>
>>> Possible answers: sliding scale 1-5, where 1 means "there shouldn't even
>>> be a way to enable it for a whole file" and 5 means "no -- a user who wants
>>> this flag would want it for the whole file". I would put GADTSyntax as a 5
>>> and OverlappingInstances as a 1. GADTs would (for me) be a 4, because maybe
>>> someone wants to say that one part of a file is more type-y than the rest.
>>>
>>> D. How much do we like the extension?
>>>
>>> Possible answers: sliding scale 1-5, where 1 means "this shouldn't be
>>> here" and 5 means "I want this on by default (ignoring backward
>>> compatibility)". -XDatatypeContexts would be a 1: we should never have had
>>> that in the language. -XOverloadedStrings would be a 5: even if we don't
>>> want it enabled everywhere, it's a vastly useful extension that lots of
>>> people depend on.
>>>
>>> E. Does the extension flag change the language, as opposed to the
>>> operation of the compiler?
>>>
>>> Possible answers: sliding scale 1-5, where 1 means "purely about the
>>> compiler operation" and 5 means "purely about the language". Most
>>> extensions (e.g. -XPolyKinds) would be 5; -XCPP would be 1. I would put
>>> -XTemplateHaskell around a 4, because it's mostly about the language, but
>>> it impacts cross-compilation and recompilation avoidance. -XSafe is a 2: it
>>> affects the way instances are selected, I think.
>>>
>>> F. How broad is the use-case for the extension?
>>>
>>> Possible answers: sliding scale 1-5, where 1 means "very specialized"
>>> and 5 is "broadly useful in many contexts". I would put
>>> -XMultiParamTypeClasses at a 5 and -XMagicHash at a 2. I'm struggling to
>>> come up with something so specialized as to be worth a 1. I would say
>>> -XTypeFamilies and -XGADTs are 4.
>>>
>>> I think these questions A-F cover the range of categories Arnaud
>>> proposes, while addressing Joachim's and Simon M's desires to keep separate
>>> things separate. Having each question have a sliding-scale answer is also
>>> nice: it means we can submit our classifications of each extension and just
>>> average the results. This avoids time wasted in debate. (You can even
>>> submit decimals in the range 1-5, if you like!) I would propose that we
>>> highlight and debate any question/extension pair where the (max - min) > 2,
>>> as there may be disagreement about what the extension or the question
>>> means. And we have a natural way to identify candidates for inclusion in
>>> GHC20XX: multiply (or add; I think multiply) the 6 scores for an extension
>>> and then set a threshold for acceptance. (I don't think we would do this
>>> blindly, at all, but it would offer a wonderful starting-point.)
>>>
>>> Having upended the table and made a mess of things, I will now answer
>>> the other questions ignoring this new proposal.
>>>
>>> > Q2: Is category 6 relevant?
>>>
>>> Yes, but it's on the wrong axis.
>>>
>>> > Q2.Y: If you found category 6 to be relevant: should it be its own
>>> >            category, or should it be a subcategory of 1?
>>>
>>> I see 6 and 1 not having a relationship: 6 is about syntax, while 1 is
>>> about whether we like an extension.
>>>
>>> > Q3: Is category 7 relevant?
>>>
>>> Yes.
>>>
>>> > Q3.Y: If you found category 7 to be relevant: should it be its own
>>> >            category or should it be a subcategory of 5?
>>>
>>> Hard to say. MagicHash and UnboxedTuples could in theory be flags. But
>>> maybe there are other 7s that wouldn't?
>>>
>>> >  Q4: In which category would you classify Strict?
>>>
>>> 5, in that Strict is a compiler flag, but it doesn't certainly change
>>> the language.
>>>
>>> >  Q5: Is there any category that you feel is missing from the list? If
>>> >        so, please argue (free form).
>>>
>>> I've done that enough already. :)
>>>
>>> Richard
>>> _______________________________________________
>>> 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/20230306/dddc73f4/attachment.html>

From simon.peytonjones at gmail.com  Mon Mar  6 09:57:08 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Mon, 6 Mar 2023 09:57:08 +0000
Subject: [ghc-steering-committee] Please review #536: Type-level
 literals as a separate language extension, Shepherd: Vlad
In-Reply-To: <fa294c4eaea45a6d27ca01a92999f9e0712fc7ad.camel@joachim-breitner.de>
References: <fa294c4eaea45a6d27ca01a92999f9e0712fc7ad.camel@joachim-breitner.de>
Message-ID: <CAJKmMz9x-uH9fhszpKnVE9jghrmJYbZ_M5D+mux4Yr5yEpCGgg@mail.gmail.com>

Hi Vlad

Are you ruminating on this one?  We need a recommendation :-).

Simon

On Thu, 16 Feb 2023 at 09:14, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Dear Committee,
>
> Ross Paterson proposes
> Type-level literals as a separate language extension
> https://github.com/ghc-proposals/ghc-proposals/pull/536
>
> https://github.com/RossPaterson/ghc-proposals/blob/literals/proposals/0000-type-level-literals.rst
>
> I suggest Vlad to shepherd this, as he has already engaged
> with it on Github.
>
> Please guide us to a conclusion as outlined in
> https://github.com/ghc-proposals/ghc-proposals#committee-process
>
>
> Cheers,
> Joachim
>
>
>
>
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230306/9629c26c/attachment-0001.html>

From vlad.z.4096 at gmail.com  Mon Mar  6 13:04:44 2023
From: vlad.z.4096 at gmail.com (Vladislav Zavialov)
Date: Mon, 6 Mar 2023 16:04:44 +0300
Subject: [ghc-steering-committee] #536: Type-level literals as a separate
	language extension, rec: accept
Message-ID: <CAHZ0NLoao=NF38m7uHHj4+trWMgcyN7gPZg3E+ET+zQTd-cK9g@mail.gmail.com>

Dear Committee,

Ross Paterson has proposed #536 "Type-level literals as a separate language
extension". Read it here:

https://github.com/RossPaterson/ghc-proposals/blob/literals/proposals/0000-type-level-literals.rst

Currently the DataKinds extension allows us to use both type-level literals
(such as "hello", 'x', and 42) and promoted algebraic data constructors
(such as True, Just, and '[]). The proposal is to factor out promotion of
literals into its own extension, TypeLevelLiterals.

Why would one want to enable TypeLevelLiterals but not DataKinds? Because
the latter can create ambiguities when it comes to name resolution. If the
user defines `data Just x = ...` and they have DataKinds enabled, then
suddenly it's ambiguous whether `Just` refers to a data constructor or a
type constructor, and GHC starts to guess from context. Type-level
literals, on the other hand, are a more conservative subset of DataKinds
that does not raise any questions with regards to name resolution.

While I, personally, would not use this conservative subset, I believe we
shouldn't create obstacles for those who want to. I expect the maintenance
costs to be minimal.

Does anyone have objections? If not, I will mark the proposal accepted in 2
weeks.

- Vlad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230306/71e687b7/attachment.html>

From vlad.z.4096 at gmail.com  Mon Mar  6 13:06:38 2023
From: vlad.z.4096 at gmail.com (Vladislav Zavialov)
Date: Mon, 6 Mar 2023 16:06:38 +0300
Subject: [ghc-steering-committee] Please review #536: Type-level
 literals as a separate language extension, Shepherd: Vlad
In-Reply-To: <CAJKmMz9x-uH9fhszpKnVE9jghrmJYbZ_M5D+mux4Yr5yEpCGgg@mail.gmail.com>
References: <fa294c4eaea45a6d27ca01a92999f9e0712fc7ad.camel@joachim-breitner.de>
 <CAJKmMz9x-uH9fhszpKnVE9jghrmJYbZ_M5D+mux4Yr5yEpCGgg@mail.gmail.com>
Message-ID: <CAHZ0NLrNVJ883svBTfpHLP9cf7EKqCAEWrJp=Rb_OR1axEBb5g@mail.gmail.com>

Thank you for the reminder, Simon, I have made a recommendation.

On Mon, Mar 6, 2023 at 12:56 PM Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> Hi Vlad
>
> Are you ruminating on this one?  We need a recommendation :-).
>
> Simon
>
> On Thu, 16 Feb 2023 at 09:14, Joachim Breitner <mail at joachim-breitner.de>
> wrote:
>
>> Dear Committee,
>>
>> Ross Paterson proposes
>> Type-level literals as a separate language extension
>> https://github.com/ghc-proposals/ghc-proposals/pull/536
>>
>> https://github.com/RossPaterson/ghc-proposals/blob/literals/proposals/0000-type-level-literals.rst
>>
>> I suggest Vlad to shepherd this, as he has already engaged
>> with it on Github.
>>
>> Please guide us to a conclusion as outlined in
>> https://github.com/ghc-proposals/ghc-proposals#committee-process
>>
>>
>> Cheers,
>> Joachim
>>
>>
>>
>>
>> --
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230306/fa8a3cc4/attachment.html>

From vlad.z.4096 at gmail.com  Mon Mar  6 13:44:28 2023
From: vlad.z.4096 at gmail.com (Vladislav Zavialov)
Date: Mon, 6 Mar 2023 16:44:28 +0300
Subject: [ghc-steering-committee] #330: Decorate exceptions with backtrace
	information, rec: accept
Message-ID: <CAHZ0NLr6-zMeNdFK-DbvemJ3pJ4hz4JZFfKoYrW1AxGqDnbnZA@mail.gmail.com>

Dear Committee,

Ben Gamari has proposed #330 "Decorate exceptions with backtrace
information". Read it here:

https://github.com/bgamari/ghc-proposals/blob/stacktraces/proposals/0000-exception-backtraces.rst

The proposal attaches contextual information to thrown exceptions. This
information includes (but is not limited to) backtraces, making it possible
to debug uncaught exceptions more effectively.

This is a very nuanced change, since it modifies SomeException, throw,
catch, and other exception-related definitions whose use is extremely
widespread. We might end up affecting our users in unexpected ways. Because
of that, I ask the committee to review the proposal with the appropriate
amount of care.

I am recommending acceptance because adding observability to our programs
is an important part of developer ergonomics. From the proposal discussion,
I have got the impression that there are numerous commercial users who
would benefit from this.

Please take a look at the proposal text and share your thoughts either here
or directly on GitHub.

- Vlad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230306/d51ea3b6/attachment.html>

From simon.peytonjones at gmail.com  Mon Mar  6 16:15:10 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Mon, 6 Mar 2023 16:15:10 +0000
Subject: [ghc-steering-committee] #536: Type-level literals as a
 separate language extension, rec: accept
In-Reply-To: <CAHZ0NLoao=NF38m7uHHj4+trWMgcyN7gPZg3E+ET+zQTd-cK9g@mail.gmail.com>
References: <CAHZ0NLoao=NF38m7uHHj4+trWMgcyN7gPZg3E+ET+zQTd-cK9g@mail.gmail.com>
Message-ID: <CAJKmMz9RC9GbudS9pCBTvYHpB6SPpXUuNJVH8-W2xS+B1+BZmA@mail.gmail.com>

I'm content to accept this one.

Simon

On Mon, 6 Mar 2023 at 13:05, Vladislav Zavialov <vlad.z.4096 at gmail.com>
wrote:

> Dear Committee,
>
> Ross Paterson has proposed #536 "Type-level literals as a separate
> language extension". Read it here:
>
>
> https://github.com/RossPaterson/ghc-proposals/blob/literals/proposals/0000-type-level-literals.rst
>
> Currently the DataKinds extension allows us to use both type-level
> literals (such as "hello", 'x', and 42) and promoted algebraic data
> constructors (such as True, Just, and '[]). The proposal is to factor out
> promotion of literals into its own extension, TypeLevelLiterals.
>
> Why would one want to enable TypeLevelLiterals but not DataKinds? Because
> the latter can create ambiguities when it comes to name resolution. If the
> user defines `data Just x = ...` and they have DataKinds enabled, then
> suddenly it's ambiguous whether `Just` refers to a data constructor or a
> type constructor, and GHC starts to guess from context. Type-level
> literals, on the other hand, are a more conservative subset of DataKinds
> that does not raise any questions with regards to name resolution.
>
> While I, personally, would not use this conservative subset, I believe we
> shouldn't create obstacles for those who want to. I expect the maintenance
> costs to be minimal.
>
> Does anyone have objections? If not, I will mark the proposal accepted in
> 2 weeks.
>
> - Vlad
> _______________________________________________
> 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/20230306/9e01110e/attachment.html>

From mail at joachim-breitner.de  Mon Mar  6 16:58:29 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 06 Mar 2023 17:58:29 +0100
Subject: [ghc-steering-committee] #536: Type-level literals as a
 separate language extension, rec: accept
In-Reply-To: <CAHZ0NLoao=NF38m7uHHj4+trWMgcyN7gPZg3E+ET+zQTd-cK9g@mail.gmail.com>
References: <CAHZ0NLoao=NF38m7uHHj4+trWMgcyN7gPZg3E+ET+zQTd-cK9g@mail.gmail.com>
Message-ID: <b2a7f83a60faeb6478acbe28d9d94c57f90740d6.camel@joachim-breitner.de>

Hi,

Am Montag, dem 06.03.2023 um 16:04 +0300 schrieb Vladislav Zavialov:
> Does anyone have objections? If not, I will mark the proposal
> accepted in 2 weeks.

not a full fledged objection yet, but I am unsure how that fits with
the overall direction we have for namespaces, as outlined in
https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0378-dependent-type-design.rst

It this meant to be a short-gap measure that helps us to get to towards
a bolder destination?

Or is it a half-way step for people who like type-level computation,
but don’t want to go all the way, and is expected to stay around?

(Or maybe I am missing the point.)

Unless I am missing the point, I can’t really make an informed decision
before we have concluded our policy discussion, in particular, on
whether we want to go towards a future where everyone is welcome to
turn extensions on and off to build their little fine-grained preferred
language islands, or whether that is something we want to avoid and use
extensions only as stepping stones towards a ((eventually) single)
future Haskell, at the cost of having to tell some people that they
can’t expect that every possible dialect of Haskell will be supported.

Cheers,
Joachim

-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/


From adam at well-typed.com  Mon Mar  6 21:27:01 2023
From: adam at well-typed.com (Adam Gundry)
Date: Mon, 6 Mar 2023 21:27:01 +0000
Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?=
 =?utf-8?b?4oCTIFJvdW5kIDE=?=
In-Reply-To: <CAGwnsnnXsJTDg5eeVTKdp7O09m9ea9mE5wLHeTMjRzWwEFEYmA@mail.gmail.com>
References: <CAGwnsnn=rY=Xzwi23HjQ2zGSRAhtqAS8Xi8Em6M5oqfpG3aYWw@mail.gmail.com>
 <010f018684991b10-761d0bd6-4151-41af-9a56-5cce6ff0aeaa-000000@us-east-2.amazonses.com>
 <CANsrgP+VQLop_UyLudEweB0m1ApaXFDPdnTyTTYm+CYJudYN=g@mail.gmail.com>
 <CAJKmMz8KyaM4j5vK+4z3je3hxB2F9bCBUChmFFEJqbuEBMzjgA@mail.gmail.com>
 <010f0186a28b88ff-d308e836-2389-4f65-a43d-93312f820f7e-000000@us-east-2.amazonses.com>
 <CAGwnsnnXsJTDg5eeVTKdp7O09m9ea9mE5wLHeTMjRzWwEFEYmA@mail.gmail.com>
Message-ID: <d8b79679-fbe0-2a86-7b00-47e5e5eed2aa@well-typed.com>

Dear Arnaud,

Thanks for trying to make progress on this! I've also been hesitating in 
replying to this thread, because I'm not sure of the big picture or what 
our goal is with the various categorisations. As I indicated in the 
document, I think we need to start by figuring out "what users need/want 
from extensions" (though no doubt there are various overlapping 
purposes). Then we can assess which of those needs are currently 
under-served.

I guess we should also try to figure out what the crucial questions are 
that we expect the policy document to answer. Some that come to mind for 
me (but let's not try to answer them all at once!):

  * Should it be a goal to reduce the number of extensions and try to 
converge on a "single Haskell"? Or should we rather aim for many small 
mostly-orthogonal extensions, even at the cost of a combinatorial 
explosion of possible "languages"?

  * What are the differences in principle between extensions, warnings 
and other compiler flags? Where reality diverges from these principles, 
to what extent should fixing that be a priority?

  * How frequently should we produce GHC20xx editions? Are the stability 
expectations for GHC20xx editions different from other extensions?

Cheers,

Adam



On 06/03/2023 08:37, Arnaud Spiwack wrote:
> Dear all,
> 
> I waited a bit before answering this thread, as I got quite surprised by 
> the replies.
> 
> First, the categorisation was meant as purely descriptive, and to 
> provide us with terminology to speak about policy. In retrospect, the 
> fact that I didn't manage to find a good name for category (1) and that 
> I resorted to name it after something the extensions might be for should 
> have been a tell that the conversation was not going to go as planned 
> (also I'm slowly realising that “experimental” may not really be a 
> category in that sense, and probably helped getting the conversation 
> confused). Let me add that, in my opinion, it would be quite premature 
> to actually try and categorise or grade extensions now, before we have a 
> policy.
> 
> Honestly, I think that it's going to be difficult to salvage this 
> approach, given that there are almost as many different positions on 
> this than respondents. That being said, I believe that we need some 
> common terminology or at least a common framework to even start to 
> discuss policy more deeply, but far from converging, we seem to be 
> diverging as the conversation progresses.
> 
> Maybe the takeaway from this conversation is that it's difficult, at 
> least at this stage, to find relevant axes on which to classify what 
> extensions are, so maybe, we ought to be building our terminology on 
> what extensions are for. Which we could build on the basis of Adam's 
> user-stories. I'll come up with a new proposal later this week.
> 
> /Arnaud
> 
> 
> 
> On Thu, 2 Mar 2023 at 14:38, Richard Eisenberg <lists at richarde.dev 
> <mailto:lists at richarde.dev>> wrote:
> 
>     Yes, I think eliminating "obvious" extensions from the need for fine
>     scoring is a good idea. Maybe we start by figuring out which these
>     should be? I bet we'll kill off about half of what we have, which is
>     a nice savings.
> 
>     Richard
> 
>>     On Feb 28, 2023, at 11:30 AM, Simon Peyton Jones
>>     <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>>
>>     wrote:
>>
>>     Shall we start with the three columns I described, and the
>>     non-scoring enumerations I suggest, and see where we go?  If it's
>>     inadequate we can elaborate.  But let's not start with too many
>>     categories etc.
>>
>>     S
>>
>>     On Tue, 28 Feb 2023 at 14:45, Simon Marlow <marlowsd at gmail.com
>>     <mailto:marlowsd at gmail.com>> wrote:
>>
>>         We definitely *could* assign every extension a 1-5 score on 6+
>>         different axes, but I have to admit the thought of actually
>>         doing this gives me a sinking feeling! Furthermore I'm not
>>         sure what we would do with the results. How do we use the
>>         scores to decide what goes into GHC20xx? It feels like we're
>>         creating a great deal of work for ourselves.
>>
>>         The idea of categorising rather than scoring is to shortcut
>>         the discussion. If we know that some extension is experimental
>>         (e.g. LinearTypes), it just goes in the experimental category
>>         and we don't need to think about it any more. If we have an
>>         extension that is enabling a deprecated feature, again we
>>         don't need to consider any other aspects.
>>
>>         So, perhaps these axes are useful for extensions that are
>>         candidates for GHC20xx and not in one of the other categories
>>         2-5 in Arnaud's list. But if we're going to reject extensions
>>         from GHC20xx for reasons that are *not* covered by categories
>>         2-5 in Arnaud's list, then we should think about what those
>>         reasons might be. Is "breaks too many programs" one of them?
>>
>>         Cheers
>>         Simon
>>
>>         On Fri, 24 Feb 2023 at 18:04, Richard Eisenberg
>>         <lists at richarde.dev <mailto:lists at richarde.dev>> wrote:
>>
>>             Thanks, Arnaud!
>>
>>             > Q1: Are all the categories 1–5 relevant? If you would
>>             like to remove
>>             >        some categories, which and why (free form)?
>>
>>             I'm not really sure I understand Category 1. In
>>             particular, I think my initial categorization didn't have
>>             Arnaud's Category 1, but instead had
>>
>>             8. Extensions that enable only new programs, without
>>             changing the semantics of any existing program
>>
>>             This was meant as a counterpoint to 6.
>>
>>             But my initial categorization was non-orthogonal: for
>>             example, this Category 8 overlaps with several other
>>             categories. In that way, Joachim's argument that we could
>>             imagine two axes of categorization -- one technical, one
>>             policy-oriented -- is intriguing. For example,
>>             -XDatatypeContexts belongs in Category 8 (it's a syntactic
>>             extension), but that doesn't mean it should be on-by-default.
>>
>>             Along similar lines, Categories 2 and 3 overlap: we might
>>             have an experimental language feature that violates a
>>             general principle. (Perhaps UndecidableSuperClasses?)
>>
>>             I tend to think that we'll have an easier time proceeding
>>             with 1) orthogonal categories and 2) separation between
>>             technical content and policy.
>>
>>             I thus propose the following taxonomy, where each
>>             extension gets rated along each axis.
>>
>>             A. Is the extension flag purely a language extension? That
>>             is, does the flag enable only new programs, without
>>             changing the semantics of any existing programs?
>>
>>             Possible answers: sliding scale 1-5, where 1 means
>>             "programs written and widely used today would break and/or
>>             change meaning" and 5 means "no programs at all change
>>             meaning". It's a sliding scale to account for the fact
>>             that e.g. -XTypeFamilies once upon a time meant that all
>>             programs retain meanings... except for ones which name a
>>             type variable `family`. (Now, `family` is unconditionally
>>             a keyword in types, so -XTypeFamilies is, I believe, a 5.)
>>             So if there are obscure programs that change meaning, we
>>             can use 2, 3, and 4 as a way of stating how obscure the
>>             programs are. (Higher number = more obscure.)
>>
>>             B. How stable is the extension flag?
>>
>>             Possible answers: sliding scale 1-5, where 1 means "likely
>>             to change soon" and 5 means "as unlikely to change as the
>>             definition of Monad". (That was chosen deliberately: we
>>             *did* change the definition of Monad!) For me, a criterion
>>             required to write 5 here would be the possibility of
>>             writing down a formal specification of the extension. (So
>>             -XGADTs could not be a 5.)
>>
>>             C. Would a user always want to enable this extension for
>>             an entire file (as opposed to for local regions)?
>>
>>             Possible answers: sliding scale 1-5, where 1 means "there
>>             shouldn't even be a way to enable it for a whole file" and
>>             5 means "no -- a user who wants this flag would want it
>>             for the whole file". I would put GADTSyntax as a 5 and
>>             OverlappingInstances as a 1. GADTs would (for me) be a 4,
>>             because maybe someone wants to say that one part of a file
>>             is more type-y than the rest.
>>
>>             D. How much do we like the extension?
>>
>>             Possible answers: sliding scale 1-5, where 1 means "this
>>             shouldn't be here" and 5 means "I want this on by default
>>             (ignoring backward compatibility)". -XDatatypeContexts
>>             would be a 1: we should never have had that in the
>>             language. -XOverloadedStrings would be a 5: even if we
>>             don't want it enabled everywhere, it's a vastly useful
>>             extension that lots of people depend on.
>>
>>             E. Does the extension flag change the language, as opposed
>>             to the operation of the compiler?
>>
>>             Possible answers: sliding scale 1-5, where 1 means "purely
>>             about the compiler operation" and 5 means "purely about
>>             the language". Most extensions (e.g. -XPolyKinds) would be
>>             5; -XCPP would be 1. I would put -XTemplateHaskell around
>>             a 4, because it's mostly about the language, but it
>>             impacts cross-compilation and recompilation avoidance.
>>             -XSafe is a 2: it affects the way instances are selected,
>>             I think.
>>
>>             F. How broad is the use-case for the extension?
>>
>>             Possible answers: sliding scale 1-5, where 1 means "very
>>             specialized" and 5 is "broadly useful in many contexts". I
>>             would put -XMultiParamTypeClasses at a 5 and -XMagicHash
>>             at a 2. I'm struggling to come up with something so
>>             specialized as to be worth a 1. I would say -XTypeFamilies
>>             and -XGADTs are 4.
>>
>>             I think these questions A-F cover the range of categories
>>             Arnaud proposes, while addressing Joachim's and Simon M's
>>             desires to keep separate things separate. Having each
>>             question have a sliding-scale answer is also nice: it
>>             means we can submit our classifications of each extension
>>             and just average the results. This avoids time wasted in
>>             debate. (You can even submit decimals in the range 1-5, if
>>             you like!) I would propose that we highlight and debate
>>             any question/extension pair where the (max - min) > 2, as
>>             there may be disagreement about what the extension or the
>>             question means. And we have a natural way to identify
>>             candidates for inclusion in GHC20XX: multiply (or add; I
>>             think multiply) the 6 scores for an extension and then set
>>             a threshold for acceptance. (I don't think we would do
>>             this blindly, at all, but it would offer a wonderful
>>             starting-point.)
>>
>>             Having upended the table and made a mess of things, I will
>>             now answer the other questions ignoring this new proposal.
>>
>>             > Q2: Is category 6 relevant?
>>
>>             Yes, but it's on the wrong axis.
>>
>>             > Q2.Y: If you found category 6 to be relevant: should it
>>             be its own
>>             >            category, or should it be a subcategory of 1?
>>
>>             I see 6 and 1 not having a relationship: 6 is about
>>             syntax, while 1 is about whether we like an extension.
>>
>>             > Q3: Is category 7 relevant?
>>
>>             Yes.
>>
>>             > Q3.Y: If you found category 7 to be relevant: should it
>>             be its own
>>             >            category or should it be a subcategory of 5?
>>
>>             Hard to say. MagicHash and UnboxedTuples could in theory
>>             be flags. But maybe there are other 7s that wouldn't?
>>
>>             >  Q4: In which category would you classify Strict?
>>
>>             5, in that Strict is a compiler flag, but it doesn't
>>             certainly change the language.
>>
>>             >  Q5: Is there any category that you feel is missing from
>>             the list? If
>>             >        so, please argue (free form).
>>
>>             I've done that enough already. :)
>>
>>             Richard

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


From eric at seidel.io  Tue Mar  7 02:49:54 2023
From: eric at seidel.io (Eric Seidel)
Date: Mon, 06 Mar 2023 21:49:54 -0500
Subject: [ghc-steering-committee] #330: Decorate exceptions with
 backtraceinformation, rec: accept
In-Reply-To: <CAHZ0NLr6-zMeNdFK-DbvemJ3pJ4hz4JZFfKoYrW1AxGqDnbnZA@mail.gmail.com>
References: <CAHZ0NLr6-zMeNdFK-DbvemJ3pJ4hz4JZFfKoYrW1AxGqDnbnZA@mail.gmail.com>
Message-ID: <40bbc395-9e11-44fc-9fb1-acd382329aad@app.fastmail.com>

Strong accept from me. I left one question about the backtrace collection defaults on GitHub.

On Mon, Mar 6, 2023, at 08:44, Vladislav Zavialov wrote:
> Dear Committee,
>
> Ben Gamari has proposed #330 "Decorate exceptions with backtrace 
> information". Read it here:
>
> https://github.com/bgamari/ghc-proposals/blob/stacktraces/proposals/0000-exception-backtraces.rst
>
> The proposal attaches contextual information to thrown exceptions. This 
> information includes (but is not limited to) backtraces, making it 
> possible to debug uncaught exceptions more effectively.
>
> This is a very nuanced change, since it modifies SomeException, throw, 
> catch, and other exception-related definitions whose use is extremely 
> widespread. We might end up affecting our users in unexpected ways. 
> Because of that, I ask the committee to review the proposal with the 
> appropriate amount of care.
>
> I am recommending acceptance because adding observability to our 
> programs is an important part of developer ergonomics. From the 
> proposal discussion, I have got the impression that there are numerous 
> commercial users who would benefit from this.
>
> Please take a look at the proposal text and share your thoughts either 
> here or directly on GitHub.
>
> - Vlad 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

From simon.peytonjones at gmail.com  Wed Mar  8 10:57:04 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Wed, 8 Mar 2023 10:57:04 +0000
Subject: [ghc-steering-committee] #536: Type-level literals as a
 separate language extension, rec: accept
In-Reply-To: <b2a7f83a60faeb6478acbe28d9d94c57f90740d6.camel@joachim-breitner.de>
References: <CAHZ0NLoao=NF38m7uHHj4+trWMgcyN7gPZg3E+ET+zQTd-cK9g@mail.gmail.com>
 <b2a7f83a60faeb6478acbe28d9d94c57f90740d6.camel@joachim-breitner.de>
Message-ID: <CAJKmMz_iF3KckSATgHetX8NL2rWqjAGTwP1j11xxBvu-9OoYaw@mail.gmail.com>

>
> Unless I am missing the point, I can’t really make an informed decision
> before we have concluded our policy discussion, in particular, on
> whether we want to go towards a future where everyone is welcome to
> turn extensions on and off to build their little fine-grained preferred
> language islands, or whether that is something we want to avoid and use
> extensions only as stepping stones towards a ((eventually) single)
> future Haskell, at the cost of having to tell some people that they
> can’t expect that every possible dialect of Haskell will be supported.
>

I don't think these two are incompatible.  Even if we have a "single future
Haskell" in mind, it's fair enough for people to switch things on and off
if they want.   Offering flexiblity at low cost seems OK to me; other
things being equal, it's not for us to say what they should or should not
want.  (If the implementation or maintenance cost was high I might think
again, but I don't think it is in this case.)

Simon

On Mon, 6 Mar 2023 at 16:58, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> Am Montag, dem 06.03.2023 um 16:04 +0300 schrieb Vladislav Zavialov:
> > Does anyone have objections? If not, I will mark the proposal
> > accepted in 2 weeks.
>
> not a full fledged objection yet, but I am unsure how that fits with
> the overall direction we have for namespaces, as outlined in
>
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0378-dependent-type-design.rst
>
> It this meant to be a short-gap measure that helps us to get to towards
> a bolder destination?
>
> Or is it a half-way step for people who like type-level computation,
> but don’t want to go all the way, and is expected to stay around?
>
> (Or maybe I am missing the point.)
>
> Unless I am missing the point, I can’t really make an informed decision
> before we have concluded our policy discussion, in particular, on
> whether we want to go towards a future where everyone is welcome to
> turn extensions on and off to build their little fine-grained preferred
> language islands, or whether that is something we want to avoid and use
> extensions only as stepping stones towards a ((eventually) single)
> future Haskell, at the cost of having to tell some people that they
> can’t expect that every possible dialect of Haskell will be supported.
>
> Cheers,
> Joachim
>
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230308/68d8208c/attachment.html>

From simon.peytonjones at gmail.com  Wed Mar  8 11:07:26 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Wed, 8 Mar 2023 11:07:26 +0000
Subject: [ghc-steering-committee] #330: Decorate exceptions with
 backtrace information, rec: accept
In-Reply-To: <CAHZ0NLr6-zMeNdFK-DbvemJ3pJ4hz4JZFfKoYrW1AxGqDnbnZA@mail.gmail.com>
References: <CAHZ0NLr6-zMeNdFK-DbvemJ3pJ4hz4JZFfKoYrW1AxGqDnbnZA@mail.gmail.com>
Message-ID: <CAJKmMz_8V2jA-P8ray=O_nDgWWKwwJX5RMGDL-M6pePQPO+zTQ@mail.gmail.com>

I have read the proposal, but I don't feel in a position to offer a
well-informed judgement about it.  It proposes a lot of specific changes to
a part of GHC's ecosystem that I'm not familiar with.

If we turn out to lack sufficient expertise on the steering committee,
maybe we should consult some plausible external experts?  Or maybe we have
enough on the committee. I'm not sure.

TL;DR: I should be considered a "don't know".  But the goal looks plausible
to me.

Other committee members: please express your views.

Simon

On Mon, 6 Mar 2023 at 13:44, Vladislav Zavialov <vlad.z.4096 at gmail.com>
wrote:

> Dear Committee,
>
> Ben Gamari has proposed #330 "Decorate exceptions with backtrace
> information". Read it here:
>
>
> https://github.com/bgamari/ghc-proposals/blob/stacktraces/proposals/0000-exception-backtraces.rst
>
> The proposal attaches contextual information to thrown exceptions. This
> information includes (but is not limited to) backtraces, making it possible
> to debug uncaught exceptions more effectively.
>
> This is a very nuanced change, since it modifies SomeException, throw,
> catch, and other exception-related definitions whose use is extremely
> widespread. We might end up affecting our users in unexpected ways. Because
> of that, I ask the committee to review the proposal with the appropriate
> amount of care.
>
> I am recommending acceptance because adding observability to our programs
> is an important part of developer ergonomics. From the proposal discussion,
> I have got the impression that there are numerous commercial users who
> would benefit from this.
>
> Please take a look at the proposal text and share your thoughts either
> here or directly on GitHub.
>
> - Vlad
> _______________________________________________
> 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/20230308/d02ca3a1/attachment.html>

From mail at joachim-breitner.de  Wed Mar  8 11:19:08 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 08 Mar 2023 12:19:08 +0100
Subject: [ghc-steering-committee] #536: Type-level literals as a
 separate language extension, rec: accept
In-Reply-To: <CAJKmMz_iF3KckSATgHetX8NL2rWqjAGTwP1j11xxBvu-9OoYaw@mail.gmail.com>
References: <CAHZ0NLoao=NF38m7uHHj4+trWMgcyN7gPZg3E+ET+zQTd-cK9g@mail.gmail.com>
 <b2a7f83a60faeb6478acbe28d9d94c57f90740d6.camel@joachim-breitner.de>
 <CAJKmMz_iF3KckSATgHetX8NL2rWqjAGTwP1j11xxBvu-9OoYaw@mail.gmail.com>
Message-ID: <c07162d7324d6cba101bee0bce2e9e3fb97c3e23.camel@joachim-breitner.de>

Hello,

Am Mittwoch, dem 08.03.2023 um 10:57 +0000 schrieb Simon Peyton Jones:
> > Unless I am missing the point, I can’t really make an informed decision
> > before we have concluded our policy discussion, in particular, on
> > whether we want to go towards a future where everyone is welcome to
> > turn extensions on and off to build their little fine-grained preferred
> > language islands, or whether that is something we want to avoid and use
> > extensions only as stepping stones towards a ((eventually) single)
> > future Haskell, at the cost of having to tell some people that they
> > can’t expect that every possible dialect of Haskell will be supported.
> 
> 
> I don't think these two are incompatible.  Even if we have a "single
> future Haskell" in mind, it's fair enough for people to switch things
> on and off if they want.   Offering flexiblity at low cost seems OK
> to me; other things being equal, it's not for us to say what they
> should or should not want.  (If the implementation or maintenance
> cost was high I might think again, but I don't think it is in this
> case.)  

It is certainly a reasonable policy that we _want_ GHC Haskell to be
highly customizable, and that users should be able to use language
extensions to tailor the language to their needs and preferences. (So
maybe we’d add UnqualifiedImports so that PVP-adherence can be enforced
with -XNoUnqualifiedImports, and we’d add ASCIISyntax, so that fans of
unicode can add -XNoASCIISyntax and get to use `forall` and `->` as
variable names, since ∀ and → are the keywords now… – just building up
a little strawmany army here…)

But its also reasonable to say that, as convenient as it is for the
individual developer asking for the feature, it’s not actualy good for
the ecosystem as a whole. And this is not just about the implementation
cost: It’s the cost of yet another language extension that people
dealing with more than just their own code have to understand, to
decide whether they want to use it, to worry about whether it’s on or
off when reading code and (in this case) mentally resolving name.
Choice is good for those who want the alternative, but incurs a (small,
but relevant) cost on everyone!

I see appeal in either policy, but they do seem rather incompatible to
me, and I hope the general policy discussion will give us better
guidelines here.


More concretely about this proposal:
It seems that one motivation is that DataKinds is “bad” in some way,
namely in that term constructors are available in types. So if we
accept this proposal, does that mean we agree with that assessment,
what are we going to do about it? Is there a better way of referring to
term constructors that we could work to wards to that works for
everyone? Or are we going to have multiple future Haskell dialects, one
with strict separation between terms and types, one with some things
also on the type level (basic literals, but no tuples or user-defined
constructors), and a third one that’s the full story?



Cheers,
Joachim

-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/


From vlad.z.4096 at gmail.com  Wed Mar  8 11:58:43 2023
From: vlad.z.4096 at gmail.com (Vladislav Zavialov)
Date: Wed, 8 Mar 2023 14:58:43 +0300
Subject: [ghc-steering-committee] #536: Type-level literals as a
 separate language extension, rec: accept
In-Reply-To: <c07162d7324d6cba101bee0bce2e9e3fb97c3e23.camel@joachim-breitner.de>
References: <CAHZ0NLoao=NF38m7uHHj4+trWMgcyN7gPZg3E+ET+zQTd-cK9g@mail.gmail.com>
 <b2a7f83a60faeb6478acbe28d9d94c57f90740d6.camel@joachim-breitner.de>
 <CAJKmMz_iF3KckSATgHetX8NL2rWqjAGTwP1j11xxBvu-9OoYaw@mail.gmail.com>
 <c07162d7324d6cba101bee0bce2e9e3fb97c3e23.camel@joachim-breitner.de>
Message-ID: <CAHZ0NLpUf9JYmaGYfJzWtc41NWxtY7fLUJu395vme6e0nmmkgw@mail.gmail.com>

On Wed, Mar 8, 2023 at 2:19 PM Joachim Breitner <mail at joachim-breitner.de>
wrote:

> It seems that one motivation is that DataKinds is “bad” in some way,
> namely in that term constructors are available in types. So if we
> accept this proposal, does that mean we agree with that assessment,
> what are we going to do about it? Is there a better way of referring to
> term constructors that we could work to wards to that works for
> everyone? Or are we going to have multiple future Haskell dialects, one
> with strict separation between terms and types, one with some things
> also on the type level (basic literals, but no tuples or user-defined
> constructors), and a third one that’s the full story?
>

DataKinds is indeed a "bad" extension because it introduces ambiguity to
name resolution.

There are two ways to avoid this issue:
1. Keep namespaces separate and double down on using punned constructor
names.
2. Merge terms and types, discouraging punned constructor names.

Each approach could indeed lead to a "dialect" of sorts.
* The (accepted and recently implemented) TypeData extension moves us in
the direction of option (1), and I imagine the proposed TypeLevelLiterals
would be often used in conjunction with TypeData. This carves out a
limited, conservative language subset for type-level programming.
* At the same time, #270 "Support pun-free code" moves us in the direction
of option (2), and I expect it to be the better option when it comes to
fully fledged dependently-typed programming envisioned by #378.

If I had to choose, I'd go with option (2). I don't see myself using
TypeData, nor TypeLevelLiterals for that matter. But I am of a "let a
thousand flowers bloom" persuasion, hence my recommendation to accept.

- Vlad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230308/b2dee3ff/attachment-0001.html>

From mail at joachim-breitner.de  Wed Mar  8 12:56:04 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 08 Mar 2023 13:56:04 +0100
Subject: [ghc-steering-committee] #536: Type-level literals as a
 separate language extension, rec: accept
In-Reply-To: <CAHZ0NLpUf9JYmaGYfJzWtc41NWxtY7fLUJu395vme6e0nmmkgw@mail.gmail.com>
References: <CAHZ0NLoao=NF38m7uHHj4+trWMgcyN7gPZg3E+ET+zQTd-cK9g@mail.gmail.com>
 <b2a7f83a60faeb6478acbe28d9d94c57f90740d6.camel@joachim-breitner.de>
 <CAJKmMz_iF3KckSATgHetX8NL2rWqjAGTwP1j11xxBvu-9OoYaw@mail.gmail.com>
 <c07162d7324d6cba101bee0bce2e9e3fb97c3e23.camel@joachim-breitner.de>
 <CAHZ0NLpUf9JYmaGYfJzWtc41NWxtY7fLUJu395vme6e0nmmkgw@mail.gmail.com>
Message-ID: <efc0baf49b2bc4451bec25d88c35e1c1af155edf.camel@joachim-breitner.de>

Hi,

Am Mittwoch, dem 08.03.2023 um 14:58 +0300 schrieb Vladislav Zavialov:
> DataKinds is indeed a "bad" extension because it introduces ambiguity
> to name resolution.
> 
> There are two ways to avoid this issue:
> 1. Keep namespaces separate and double down on using punned
> constructor names.
> 2. Merge terms and types, discouraging punned constructor names.
> 
> Each approach could indeed lead to a "dialect" of sorts.
>
> * The (accepted and recently implemented) TypeData extension moves us
> in the direction of option (1), and I imagine the proposed
> TypeLevelLiterals would be often used in conjunction with TypeData.
> This carves out a limited, conservative language subset for type-
> level programming.
> * At the same time, #270 "Support pun-free code" moves us in the
> direction of option (2), and I expect it to be the better option when
> it comes to fully fledged dependently-typed programming envisioned by
> #378.
> 
> If I had to choose, I'd go with option (2). I don't see myself using
> TypeData, nor TypeLevelLiterals for that matter. But I am of a "let a
> thousand flowers bloom" persuasion, hence my recommendation to
> accept.


Thanks for putting this into a clearer context.

Where does DataKind fit in? Is it a natural part of approach (2) (which
is the general direction outlined by #378), or is yet another take on
the issue?
If DataKinds was not what we want according to #378, but the fragment
carved out by TypeLevelLiterals was, then that would be a strong reason
for me to acccept TypeLevelLiterals.
But if DataKinds is the goal (or at least “the” goal), then I think I’d
like to see stronger arguments for why it should be split.


Cheers,
Joachim

-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/


From arnaud.spiwack at tweag.io  Thu Mar  9 09:16:21 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Thu, 9 Mar 2023 10:16:21 +0100
Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?=
	=?utf-8?b?4oCTIFJvdW5kIDE=?=
In-Reply-To: <d8b79679-fbe0-2a86-7b00-47e5e5eed2aa@well-typed.com>
References: <CAGwnsnn=rY=Xzwi23HjQ2zGSRAhtqAS8Xi8Em6M5oqfpG3aYWw@mail.gmail.com>
 <010f018684991b10-761d0bd6-4151-41af-9a56-5cce6ff0aeaa-000000@us-east-2.amazonses.com>
 <CANsrgP+VQLop_UyLudEweB0m1ApaXFDPdnTyTTYm+CYJudYN=g@mail.gmail.com>
 <CAJKmMz8KyaM4j5vK+4z3je3hxB2F9bCBUChmFFEJqbuEBMzjgA@mail.gmail.com>
 <010f0186a28b88ff-d308e836-2389-4f65-a43d-93312f820f7e-000000@us-east-2.amazonses.com>
 <CAGwnsnnXsJTDg5eeVTKdp7O09m9ea9mE5wLHeTMjRzWwEFEYmA@mail.gmail.com>
 <d8b79679-fbe0-2a86-7b00-47e5e5eed2aa@well-typed.com>
Message-ID: <CAGwnsn=7w7=u4Kf85mpiCM89Ln8gr+Kubr4q+qrvF3GenDTewA@mail.gmail.com>

Simon,

> I made a very concrete suggestion: a table whose rows are extensions, and
whose columns are described below.  I think it would help us.

You have, and I'm not ignoring it. But it also doesn't seem to have helped
people converge, so far. I can tell you my personal opinion on your
proposed columns: they make a lot of sense to me, but I don't think that
they are the right dimensions that will help answer the questions that
Joachim initially asked.

I must say that since writing my previous email, I have gotten some clarity
on categorification (at the expense of some sleep, I'm afraid to say, but
such are human bodies). I'll get back to it. I'm going to give a try to
start the conversation from the “what people use extensions for” point of
view next, though. Let's see if we can find some common ground there.


Best,
Arnaud

On Mon, 6 Mar 2023 at 22:27, Adam Gundry <adam at well-typed.com> wrote:

> Dear Arnaud,
>
> Thanks for trying to make progress on this! I've also been hesitating in
> replying to this thread, because I'm not sure of the big picture or what
> our goal is with the various categorisations. As I indicated in the
> document, I think we need to start by figuring out "what users need/want
> from extensions" (though no doubt there are various overlapping
> purposes). Then we can assess which of those needs are currently
> under-served.
>
> I guess we should also try to figure out what the crucial questions are
> that we expect the policy document to answer. Some that come to mind for
> me (but let's not try to answer them all at once!):
>
>   * Should it be a goal to reduce the number of extensions and try to
> converge on a "single Haskell"? Or should we rather aim for many small
> mostly-orthogonal extensions, even at the cost of a combinatorial
> explosion of possible "languages"?
>
>   * What are the differences in principle between extensions, warnings
> and other compiler flags? Where reality diverges from these principles,
> to what extent should fixing that be a priority?
>
>   * How frequently should we produce GHC20xx editions? Are the stability
> expectations for GHC20xx editions different from other extensions?
>
> Cheers,
>
> Adam
>
>
>
> On 06/03/2023 08:37, Arnaud Spiwack wrote:
> > Dear all,
> >
> > I waited a bit before answering this thread, as I got quite surprised by
> > the replies.
> >
> > First, the categorisation was meant as purely descriptive, and to
> > provide us with terminology to speak about policy. In retrospect, the
> > fact that I didn't manage to find a good name for category (1) and that
> > I resorted to name it after something the extensions might be for should
> > have been a tell that the conversation was not going to go as planned
> > (also I'm slowly realising that “experimental” may not really be a
> > category in that sense, and probably helped getting the conversation
> > confused). Let me add that, in my opinion, it would be quite premature
> > to actually try and categorise or grade extensions now, before we have a
> > policy.
> >
> > Honestly, I think that it's going to be difficult to salvage this
> > approach, given that there are almost as many different positions on
> > this than respondents. That being said, I believe that we need some
> > common terminology or at least a common framework to even start to
> > discuss policy more deeply, but far from converging, we seem to be
> > diverging as the conversation progresses.
> >
> > Maybe the takeaway from this conversation is that it's difficult, at
> > least at this stage, to find relevant axes on which to classify what
> > extensions are, so maybe, we ought to be building our terminology on
> > what extensions are for. Which we could build on the basis of Adam's
> > user-stories. I'll come up with a new proposal later this week.
> >
> > /Arnaud
> >
> >
> >
> > On Thu, 2 Mar 2023 at 14:38, Richard Eisenberg <lists at richarde.dev
> > <mailto:lists at richarde.dev>> wrote:
> >
> >     Yes, I think eliminating "obvious" extensions from the need for fine
> >     scoring is a good idea. Maybe we start by figuring out which these
> >     should be? I bet we'll kill off about half of what we have, which is
> >     a nice savings.
> >
> >     Richard
> >
> >>     On Feb 28, 2023, at 11:30 AM, Simon Peyton Jones
> >>     <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>>
> >>     wrote:
> >>
> >>     Shall we start with the three columns I described, and the
> >>     non-scoring enumerations I suggest, and see where we go?  If it's
> >>     inadequate we can elaborate.  But let's not start with too many
> >>     categories etc.
> >>
> >>     S
> >>
> >>     On Tue, 28 Feb 2023 at 14:45, Simon Marlow <marlowsd at gmail.com
> >>     <mailto:marlowsd at gmail.com>> wrote:
> >>
> >>         We definitely *could* assign every extension a 1-5 score on 6+
> >>         different axes, but I have to admit the thought of actually
> >>         doing this gives me a sinking feeling! Furthermore I'm not
> >>         sure what we would do with the results. How do we use the
> >>         scores to decide what goes into GHC20xx? It feels like we're
> >>         creating a great deal of work for ourselves.
> >>
> >>         The idea of categorising rather than scoring is to shortcut
> >>         the discussion. If we know that some extension is experimental
> >>         (e.g. LinearTypes), it just goes in the experimental category
> >>         and we don't need to think about it any more. If we have an
> >>         extension that is enabling a deprecated feature, again we
> >>         don't need to consider any other aspects.
> >>
> >>         So, perhaps these axes are useful for extensions that are
> >>         candidates for GHC20xx and not in one of the other categories
> >>         2-5 in Arnaud's list. But if we're going to reject extensions
> >>         from GHC20xx for reasons that are *not* covered by categories
> >>         2-5 in Arnaud's list, then we should think about what those
> >>         reasons might be. Is "breaks too many programs" one of them?
> >>
> >>         Cheers
> >>         Simon
> >>
> >>         On Fri, 24 Feb 2023 at 18:04, Richard Eisenberg
> >>         <lists at richarde.dev <mailto:lists at richarde.dev>> wrote:
> >>
> >>             Thanks, Arnaud!
> >>
> >>             > Q1: Are all the categories 1–5 relevant? If you would
> >>             like to remove
> >>             >        some categories, which and why (free form)?
> >>
> >>             I'm not really sure I understand Category 1. In
> >>             particular, I think my initial categorization didn't have
> >>             Arnaud's Category 1, but instead had
> >>
> >>             8. Extensions that enable only new programs, without
> >>             changing the semantics of any existing program
> >>
> >>             This was meant as a counterpoint to 6.
> >>
> >>             But my initial categorization was non-orthogonal: for
> >>             example, this Category 8 overlaps with several other
> >>             categories. In that way, Joachim's argument that we could
> >>             imagine two axes of categorization -- one technical, one
> >>             policy-oriented -- is intriguing. For example,
> >>             -XDatatypeContexts belongs in Category 8 (it's a syntactic
> >>             extension), but that doesn't mean it should be
> on-by-default.
> >>
> >>             Along similar lines, Categories 2 and 3 overlap: we might
> >>             have an experimental language feature that violates a
> >>             general principle. (Perhaps UndecidableSuperClasses?)
> >>
> >>             I tend to think that we'll have an easier time proceeding
> >>             with 1) orthogonal categories and 2) separation between
> >>             technical content and policy.
> >>
> >>             I thus propose the following taxonomy, where each
> >>             extension gets rated along each axis.
> >>
> >>             A. Is the extension flag purely a language extension? That
> >>             is, does the flag enable only new programs, without
> >>             changing the semantics of any existing programs?
> >>
> >>             Possible answers: sliding scale 1-5, where 1 means
> >>             "programs written and widely used today would break and/or
> >>             change meaning" and 5 means "no programs at all change
> >>             meaning". It's a sliding scale to account for the fact
> >>             that e.g. -XTypeFamilies once upon a time meant that all
> >>             programs retain meanings... except for ones which name a
> >>             type variable `family`. (Now, `family` is unconditionally
> >>             a keyword in types, so -XTypeFamilies is, I believe, a 5.)
> >>             So if there are obscure programs that change meaning, we
> >>             can use 2, 3, and 4 as a way of stating how obscure the
> >>             programs are. (Higher number = more obscure.)
> >>
> >>             B. How stable is the extension flag?
> >>
> >>             Possible answers: sliding scale 1-5, where 1 means "likely
> >>             to change soon" and 5 means "as unlikely to change as the
> >>             definition of Monad". (That was chosen deliberately: we
> >>             *did* change the definition of Monad!) For me, a criterion
> >>             required to write 5 here would be the possibility of
> >>             writing down a formal specification of the extension. (So
> >>             -XGADTs could not be a 5.)
> >>
> >>             C. Would a user always want to enable this extension for
> >>             an entire file (as opposed to for local regions)?
> >>
> >>             Possible answers: sliding scale 1-5, where 1 means "there
> >>             shouldn't even be a way to enable it for a whole file" and
> >>             5 means "no -- a user who wants this flag would want it
> >>             for the whole file". I would put GADTSyntax as a 5 and
> >>             OverlappingInstances as a 1. GADTs would (for me) be a 4,
> >>             because maybe someone wants to say that one part of a file
> >>             is more type-y than the rest.
> >>
> >>             D. How much do we like the extension?
> >>
> >>             Possible answers: sliding scale 1-5, where 1 means "this
> >>             shouldn't be here" and 5 means "I want this on by default
> >>             (ignoring backward compatibility)". -XDatatypeContexts
> >>             would be a 1: we should never have had that in the
> >>             language. -XOverloadedStrings would be a 5: even if we
> >>             don't want it enabled everywhere, it's a vastly useful
> >>             extension that lots of people depend on.
> >>
> >>             E. Does the extension flag change the language, as opposed
> >>             to the operation of the compiler?
> >>
> >>             Possible answers: sliding scale 1-5, where 1 means "purely
> >>             about the compiler operation" and 5 means "purely about
> >>             the language". Most extensions (e.g. -XPolyKinds) would be
> >>             5; -XCPP would be 1. I would put -XTemplateHaskell around
> >>             a 4, because it's mostly about the language, but it
> >>             impacts cross-compilation and recompilation avoidance.
> >>             -XSafe is a 2: it affects the way instances are selected,
> >>             I think.
> >>
> >>             F. How broad is the use-case for the extension?
> >>
> >>             Possible answers: sliding scale 1-5, where 1 means "very
> >>             specialized" and 5 is "broadly useful in many contexts". I
> >>             would put -XMultiParamTypeClasses at a 5 and -XMagicHash
> >>             at a 2. I'm struggling to come up with something so
> >>             specialized as to be worth a 1. I would say -XTypeFamilies
> >>             and -XGADTs are 4.
> >>
> >>             I think these questions A-F cover the range of categories
> >>             Arnaud proposes, while addressing Joachim's and Simon M's
> >>             desires to keep separate things separate. Having each
> >>             question have a sliding-scale answer is also nice: it
> >>             means we can submit our classifications of each extension
> >>             and just average the results. This avoids time wasted in
> >>             debate. (You can even submit decimals in the range 1-5, if
> >>             you like!) I would propose that we highlight and debate
> >>             any question/extension pair where the (max - min) > 2, as
> >>             there may be disagreement about what the extension or the
> >>             question means. And we have a natural way to identify
> >>             candidates for inclusion in GHC20XX: multiply (or add; I
> >>             think multiply) the 6 scores for an extension and then set
> >>             a threshold for acceptance. (I don't think we would do
> >>             this blindly, at all, but it would offer a wonderful
> >>             starting-point.)
> >>
> >>             Having upended the table and made a mess of things, I will
> >>             now answer the other questions ignoring this new proposal.
> >>
> >>             > Q2: Is category 6 relevant?
> >>
> >>             Yes, but it's on the wrong axis.
> >>
> >>             > Q2.Y: If you found category 6 to be relevant: should it
> >>             be its own
> >>             >            category, or should it be a subcategory of 1?
> >>
> >>             I see 6 and 1 not having a relationship: 6 is about
> >>             syntax, while 1 is about whether we like an extension.
> >>
> >>             > Q3: Is category 7 relevant?
> >>
> >>             Yes.
> >>
> >>             > Q3.Y: If you found category 7 to be relevant: should it
> >>             be its own
> >>             >            category or should it be a subcategory of 5?
> >>
> >>             Hard to say. MagicHash and UnboxedTuples could in theory
> >>             be flags. But maybe there are other 7s that wouldn't?
> >>
> >>             >  Q4: In which category would you classify Strict?
> >>
> >>             5, in that Strict is a compiler flag, but it doesn't
> >>             certainly change the language.
> >>
> >>             >  Q5: Is there any category that you feel is missing from
> >>             the list? If
> >>             >        so, please argue (free form).
> >>
> >>             I've done that enough already. :)
> >>
> >>             Richard
>
> --
> 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
>
> _______________________________________________
> 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/20230309/7964d74c/attachment-0001.html>

From arnaud.spiwack at tweag.io  Thu Mar  9 09:26:08 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Thu, 9 Mar 2023 10:26:08 +0100
Subject: [ghc-steering-committee] #536: Type-level literals as a
 separate language extension, rec: accept
In-Reply-To: <efc0baf49b2bc4451bec25d88c35e1c1af155edf.camel@joachim-breitner.de>
References: <CAHZ0NLoao=NF38m7uHHj4+trWMgcyN7gPZg3E+ET+zQTd-cK9g@mail.gmail.com>
 <b2a7f83a60faeb6478acbe28d9d94c57f90740d6.camel@joachim-breitner.de>
 <CAJKmMz_iF3KckSATgHetX8NL2rWqjAGTwP1j11xxBvu-9OoYaw@mail.gmail.com>
 <c07162d7324d6cba101bee0bce2e9e3fb97c3e23.camel@joachim-breitner.de>
 <CAHZ0NLpUf9JYmaGYfJzWtc41NWxtY7fLUJu395vme6e0nmmkgw@mail.gmail.com>
 <efc0baf49b2bc4451bec25d88c35e1c1af155edf.camel@joachim-breitner.de>
Message-ID: <CAGwnsnny_-PZED5y6RfDaLYwWP==NeK-zvoF3pEbyV1yy5yvBQ@mail.gmail.com>

I can see where the author is coming from. But as Joachim, I find myself
unconvinced that it is worth yet one extra extension (but then again, I'm
the more-extensions-make-me-wince member of this committee).

On Wed, 8 Mar 2023 at 13:56, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> Am Mittwoch, dem 08.03.2023 um 14:58 +0300 schrieb Vladislav Zavialov:
> > DataKinds is indeed a "bad" extension because it introduces ambiguity
> > to name resolution.
> >
> > There are two ways to avoid this issue:
> > 1. Keep namespaces separate and double down on using punned
> > constructor names.
> > 2. Merge terms and types, discouraging punned constructor names.
> >
> > Each approach could indeed lead to a "dialect" of sorts.
> >
> > * The (accepted and recently implemented) TypeData extension moves us
> > in the direction of option (1), and I imagine the proposed
> > TypeLevelLiterals would be often used in conjunction with TypeData.
> > This carves out a limited, conservative language subset for type-
> > level programming.
> > * At the same time, #270 "Support pun-free code" moves us in the
> > direction of option (2), and I expect it to be the better option when
> > it comes to fully fledged dependently-typed programming envisioned by
> > #378.
> >
> > If I had to choose, I'd go with option (2). I don't see myself using
> > TypeData, nor TypeLevelLiterals for that matter. But I am of a "let a
> > thousand flowers bloom" persuasion, hence my recommendation to
> > accept.
>
>
> Thanks for putting this into a clearer context.
>
> Where does DataKind fit in? Is it a natural part of approach (2) (which
> is the general direction outlined by #378), or is yet another take on
> the issue?
> If DataKinds was not what we want according to #378, but the fragment
> carved out by TypeLevelLiterals was, then that would be a strong reason
> for me to acccept TypeLevelLiterals.
> But if DataKinds is the goal (or at least “the” goal), then I think I’d
> like to see stronger arguments for why it should be split.
>
>
> Cheers,
> Joachim
>
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230309/bb0bb74b/attachment.html>

From marlowsd at gmail.com  Thu Mar  9 10:23:09 2023
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu, 9 Mar 2023 10:23:09 +0000
Subject: [ghc-steering-committee] #330: Decorate exceptions with
 backtrace information, rec: accept
In-Reply-To: <CAHZ0NLr6-zMeNdFK-DbvemJ3pJ4hz4JZFfKoYrW1AxGqDnbnZA@mail.gmail.com>
References: <CAHZ0NLr6-zMeNdFK-DbvemJ3pJ4hz4JZFfKoYrW1AxGqDnbnZA@mail.gmail.com>
Message-ID: <CANsrgPL_VNngGx_SkmQDa6ACOvNoza1GqLr27EvtmrQa_ho2EQ@mail.gmail.com>

High-level we definitely want this, I added a couple of comments to the
GitHub thread to discuss details.

One slightly suboptimal aspect of the proposal is the use of implicit
parameters. The design in Section 8.2
<https://github.com/bgamari/ghc-proposals/blob/stacktraces/proposals/0000-exception-backtraces.rst#82exception-hierarchy-design-alternative-two>
seems much nicer and is only prevented by issues with pattern synonyms.
Couldn't we fix pattern synonyms so this would work?

Cheers
Simon

On Mon, 6 Mar 2023 at 13:44, Vladislav Zavialov <vlad.z.4096 at gmail.com>
wrote:

> Dear Committee,
>
> Ben Gamari has proposed #330 "Decorate exceptions with backtrace
> information". Read it here:
>
>
> https://github.com/bgamari/ghc-proposals/blob/stacktraces/proposals/0000-exception-backtraces.rst
>
> The proposal attaches contextual information to thrown exceptions. This
> information includes (but is not limited to) backtraces, making it possible
> to debug uncaught exceptions more effectively.
>
> This is a very nuanced change, since it modifies SomeException, throw,
> catch, and other exception-related definitions whose use is extremely
> widespread. We might end up affecting our users in unexpected ways. Because
> of that, I ask the committee to review the proposal with the appropriate
> amount of care.
>
> I am recommending acceptance because adding observability to our programs
> is an important part of developer ergonomics. From the proposal discussion,
> I have got the impression that there are numerous commercial users who
> would benefit from this.
>
> Please take a look at the proposal text and share your thoughts either
> here or directly on GitHub.
>
> - Vlad
> _______________________________________________
> 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/20230309/893b9b9b/attachment.html>

From arnaud.spiwack at tweag.io  Thu Mar  9 10:39:16 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Thu, 9 Mar 2023 11:39:16 +0100
Subject: [ghc-steering-committee] #330: Decorate exceptions with
 backtrace information, rec: accept
In-Reply-To: <CANsrgPL_VNngGx_SkmQDa6ACOvNoza1GqLr27EvtmrQa_ho2EQ@mail.gmail.com>
References: <CAHZ0NLr6-zMeNdFK-DbvemJ3pJ4hz4JZFfKoYrW1AxGqDnbnZA@mail.gmail.com>
 <CANsrgPL_VNngGx_SkmQDa6ACOvNoza1GqLr27EvtmrQa_ho2EQ@mail.gmail.com>
Message-ID: <CAGwnsnmCEGW_eDdE58+WebxLk_7MUzzrYyKkyC7aP517kzvOzw@mail.gmail.com>

Likewise: very supportive, a few holes that I'd like to address before
fully committing.

Contrary to Simon M, though, I think I prefer the implicit parameter design
to the pattern-synonym design.


On Thu, 9 Mar 2023 at 11:23, Simon Marlow <marlowsd at gmail.com> wrote:

> High-level we definitely want this, I added a couple of comments to the
> GitHub thread to discuss details.
>
> One slightly suboptimal aspect of the proposal is the use of implicit
> parameters. The design in Section 8.2
> <https://github.com/bgamari/ghc-proposals/blob/stacktraces/proposals/0000-exception-backtraces.rst#82exception-hierarchy-design-alternative-two>
> seems much nicer and is only prevented by issues with pattern synonyms.
> Couldn't we fix pattern synonyms so this would work?
>
> Cheers
> Simon
>
> On Mon, 6 Mar 2023 at 13:44, Vladislav Zavialov <vlad.z.4096 at gmail.com>
> wrote:
>
>> Dear Committee,
>>
>> Ben Gamari has proposed #330 "Decorate exceptions with backtrace
>> information". Read it here:
>>
>>
>> https://github.com/bgamari/ghc-proposals/blob/stacktraces/proposals/0000-exception-backtraces.rst
>>
>> The proposal attaches contextual information to thrown exceptions. This
>> information includes (but is not limited to) backtraces, making it possible
>> to debug uncaught exceptions more effectively.
>>
>> This is a very nuanced change, since it modifies SomeException, throw,
>> catch, and other exception-related definitions whose use is extremely
>> widespread. We might end up affecting our users in unexpected ways. Because
>> of that, I ask the committee to review the proposal with the appropriate
>> amount of care.
>>
>> I am recommending acceptance because adding observability to our programs
>> is an important part of developer ergonomics. From the proposal discussion,
>> I have got the impression that there are numerous commercial users who
>> would benefit from this.
>>
>> Please take a look at the proposal text and share your thoughts either
>> here or directly on GitHub.
>>
>> - Vlad
>> _______________________________________________
>> 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/20230309/750ac939/attachment.html>

From marlowsd at gmail.com  Thu Mar  9 11:51:56 2023
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu, 9 Mar 2023 11:51:56 +0000
Subject: [ghc-steering-committee] #330: Decorate exceptions with
 backtrace information, rec: accept
In-Reply-To: <CAGwnsnmCEGW_eDdE58+WebxLk_7MUzzrYyKkyC7aP517kzvOzw@mail.gmail.com>
References: <CAHZ0NLr6-zMeNdFK-DbvemJ3pJ4hz4JZFfKoYrW1AxGqDnbnZA@mail.gmail.com>
 <CANsrgPL_VNngGx_SkmQDa6ACOvNoza1GqLr27EvtmrQa_ho2EQ@mail.gmail.com>
 <CAGwnsnmCEGW_eDdE58+WebxLk_7MUzzrYyKkyC7aP517kzvOzw@mail.gmail.com>
Message-ID: <CANsrgPLVnZSEjhUqN=UfVw1JALSENTN9ni_PgNNDOu2sZd96+A@mail.gmail.com>

On Thu, 9 Mar 2023 at 10:39, Arnaud Spiwack <arnaud.spiwack at tweag.io> wrote:

> Likewise: very supportive, a few holes that I'd like to address before
> fully committing.
>
> Contrary to Simon M, though, I think I prefer the implicit parameter
> design to the pattern-synonym design.
>

Out of interest, why?

Simon



>
>
> On Thu, 9 Mar 2023 at 11:23, Simon Marlow <marlowsd at gmail.com> wrote:
>
>> High-level we definitely want this, I added a couple of comments to the
>> GitHub thread to discuss details.
>>
>> One slightly suboptimal aspect of the proposal is the use of implicit
>> parameters. The design in Section 8.2
>> <https://github.com/bgamari/ghc-proposals/blob/stacktraces/proposals/0000-exception-backtraces.rst#82exception-hierarchy-design-alternative-two>
>> seems much nicer and is only prevented by issues with pattern synonyms.
>> Couldn't we fix pattern synonyms so this would work?
>>
>> Cheers
>> Simon
>>
>> On Mon, 6 Mar 2023 at 13:44, Vladislav Zavialov <vlad.z.4096 at gmail.com>
>> wrote:
>>
>>> Dear Committee,
>>>
>>> Ben Gamari has proposed #330 "Decorate exceptions with backtrace
>>> information". Read it here:
>>>
>>>
>>> https://github.com/bgamari/ghc-proposals/blob/stacktraces/proposals/0000-exception-backtraces.rst
>>>
>>> The proposal attaches contextual information to thrown exceptions. This
>>> information includes (but is not limited to) backtraces, making it possible
>>> to debug uncaught exceptions more effectively.
>>>
>>> This is a very nuanced change, since it modifies SomeException, throw,
>>> catch, and other exception-related definitions whose use is extremely
>>> widespread. We might end up affecting our users in unexpected ways. Because
>>> of that, I ask the committee to review the proposal with the appropriate
>>> amount of care.
>>>
>>> I am recommending acceptance because adding observability to our
>>> programs is an important part of developer ergonomics. From the proposal
>>> discussion, I have got the impression that there are numerous commercial
>>> users who would benefit from this.
>>>
>>> Please take a look at the proposal text and share your thoughts either
>>> here or directly on GitHub.
>>>
>>> - Vlad
>>> _______________________________________________
>>> 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/20230309/432a4f6d/attachment-0001.html>

From lists at richarde.dev  Thu Mar  9 16:21:15 2023
From: lists at richarde.dev (Richard Eisenberg)
Date: Thu, 9 Mar 2023 16:21:15 +0000
Subject: [ghc-steering-committee] #536: Type-level literals as a
 separate language extension, rec: accept
In-Reply-To: <CAGwnsnny_-PZED5y6RfDaLYwWP==NeK-zvoF3pEbyV1yy5yvBQ@mail.gmail.com>
References: <CAHZ0NLoao=NF38m7uHHj4+trWMgcyN7gPZg3E+ET+zQTd-cK9g@mail.gmail.com>
 <b2a7f83a60faeb6478acbe28d9d94c57f90740d6.camel@joachim-breitner.de>
 <CAJKmMz_iF3KckSATgHetX8NL2rWqjAGTwP1j11xxBvu-9OoYaw@mail.gmail.com>
 <c07162d7324d6cba101bee0bce2e9e3fb97c3e23.camel@joachim-breitner.de>
 <CAHZ0NLpUf9JYmaGYfJzWtc41NWxtY7fLUJu395vme6e0nmmkgw@mail.gmail.com>
 <efc0baf49b2bc4451bec25d88c35e1c1af155edf.camel@joachim-breitner.de>
 <CAGwnsnny_-PZED5y6RfDaLYwWP==NeK-zvoF3pEbyV1yy5yvBQ@mail.gmail.com>
Message-ID: <010f0186c72d3aa5-5163b078-0956-46e8-9e41-c2d206f6273c-000000@us-east-2.amazonses.com>

Though I see the arguments in the other direction, I vote against this proposal. As Joachim argues, adding an extension puts a tax on the entire ecosystem by adding one more bit of context a reader has to have to understand code. In addition, HLS will have to be aware of this extension. And the benefits seem pretty marginal here.

Can we instead simply provide a warning? The warning here would be something like the -Wpuns idea, in that it helps the author keep to a particular subset of the language. (We might want to collect such warnings somehow in our documentation.)

Actually, it occurs to me we already have the warning: -Wunticked-promoted-constructors. We've put that warning in the -Weverything bin (not even -Wall) because in the past we've decided that we shouldn't recommend/require the ' when using a constructor in a type. But actually, setting -Werror=unticked-promoted-constructors would seem to be a perfect substitute for -XTypeLevelLiterals -XNoDataKinds. OK, not perfect: you could still use a constructor in a type with a ' mark. But I think that's great, actually, because perhaps an author wary of constructors in types still might need to use one, in one place, in a 2,000-line file. This ticks all the boxes (ha ha).

Having discovered this replacement, I'm now pretty strongly against this proposal. I'll also post on GitHub.

Richard

> On Mar 9, 2023, at 4:26 AM, Arnaud Spiwack <arnaud.spiwack at tweag.io> wrote:
> 
> I can see where the author is coming from. But as Joachim, I find myself unconvinced that it is worth yet one extra extension (but then again, I'm the more-extensions-make-me-wince member of this committee).
> 
> On Wed, 8 Mar 2023 at 13:56, Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
> Hi,
> 
> Am Mittwoch, dem 08.03.2023 um 14:58 +0300 schrieb Vladislav Zavialov:
> > DataKinds is indeed a "bad" extension because it introduces ambiguity
> > to name resolution.
> > 
> > There are two ways to avoid this issue:
> > 1. Keep namespaces separate and double down on using punned
> > constructor names.
> > 2. Merge terms and types, discouraging punned constructor names.
> > 
> > Each approach could indeed lead to a "dialect" of sorts.
> >
> > * The (accepted and recently implemented) TypeData extension moves us
> > in the direction of option (1), and I imagine the proposed
> > TypeLevelLiterals would be often used in conjunction with TypeData.
> > This carves out a limited, conservative language subset for type-
> > level programming.
> > * At the same time, #270 "Support pun-free code" moves us in the
> > direction of option (2), and I expect it to be the better option when
> > it comes to fully fledged dependently-typed programming envisioned by
> > #378.
> > 
> > If I had to choose, I'd go with option (2). I don't see myself using
> > TypeData, nor TypeLevelLiterals for that matter. But I am of a "let a
> > thousand flowers bloom" persuasion, hence my recommendation to
> > accept.
> 
> 
> Thanks for putting this into a clearer context.
> 
> Where does DataKind fit in? Is it a natural part of approach (2) (which
> is the general direction outlined by #378), or is yet another take on
> the issue?
> If DataKinds was not what we want according to #378, but the fragment
> carved out by TypeLevelLiterals was, then that would be a strong reason
> for me to acccept TypeLevelLiterals.
> But if DataKinds is the goal (or at least “the” goal), then I think I’d
> like to see stronger arguments for why it should be split.
> 
> 
> Cheers,
> Joachim
> 
> -- 
> 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
> 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/20230309/76fe9173/attachment.html>

From arnaud.spiwack at tweag.io  Thu Mar  9 17:03:34 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Thu, 9 Mar 2023 18:03:34 +0100
Subject: [ghc-steering-committee] #330: Decorate exceptions with
 backtrace information, rec: accept
In-Reply-To: <CANsrgPLVnZSEjhUqN=UfVw1JALSENTN9ni_PgNNDOu2sZd96+A@mail.gmail.com>
References: <CAHZ0NLr6-zMeNdFK-DbvemJ3pJ4hz4JZFfKoYrW1AxGqDnbnZA@mail.gmail.com>
 <CANsrgPL_VNngGx_SkmQDa6ACOvNoza1GqLr27EvtmrQa_ho2EQ@mail.gmail.com>
 <CAGwnsnmCEGW_eDdE58+WebxLk_7MUzzrYyKkyC7aP517kzvOzw@mail.gmail.com>
 <CANsrgPLVnZSEjhUqN=UfVw1JALSENTN9ni_PgNNDOu2sZd96+A@mail.gmail.com>
Message-ID: <CAGwnsn=4Oavgq+YEnHVM8A=LW5LfSgsk9GcFpZoQkG+qBNPdcw@mail.gmail.com>

On Thu, 9 Mar 2023 at 12:52, Simon Marlow <marlowsd at gmail.com> wrote:

> Out of interest, why?
>

 I'm not sure that I can quite say. The idea of annotations being somewhat
implicitly passed, the symmetry with `HasCallStack`: it appeals to me. I
guess it's not a very strong preference.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230309/862822bf/attachment.html>

From marlowsd at gmail.com  Thu Mar  9 17:41:09 2023
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu, 9 Mar 2023 17:41:09 +0000
Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?=
	=?utf-8?b?4oCTIFJvdW5kIDE=?=
In-Reply-To: <CAGwnsn=7w7=u4Kf85mpiCM89Ln8gr+Kubr4q+qrvF3GenDTewA@mail.gmail.com>
References: <CAGwnsnn=rY=Xzwi23HjQ2zGSRAhtqAS8Xi8Em6M5oqfpG3aYWw@mail.gmail.com>
 <010f018684991b10-761d0bd6-4151-41af-9a56-5cce6ff0aeaa-000000@us-east-2.amazonses.com>
 <CANsrgP+VQLop_UyLudEweB0m1ApaXFDPdnTyTTYm+CYJudYN=g@mail.gmail.com>
 <CAJKmMz8KyaM4j5vK+4z3je3hxB2F9bCBUChmFFEJqbuEBMzjgA@mail.gmail.com>
 <010f0186a28b88ff-d308e836-2389-4f65-a43d-93312f820f7e-000000@us-east-2.amazonses.com>
 <CAGwnsnnXsJTDg5eeVTKdp7O09m9ea9mE5wLHeTMjRzWwEFEYmA@mail.gmail.com>
 <d8b79679-fbe0-2a86-7b00-47e5e5eed2aa@well-typed.com>
 <CAGwnsn=7w7=u4Kf85mpiCM89Ln8gr+Kubr4q+qrvF3GenDTewA@mail.gmail.com>
Message-ID: <CANsrgPLfCQPFq7YRh0a3j9JJbjU8y7aRyPYBU+bpvRA1vft4Ng@mail.gmail.com>

Looking forward to your proposal Arnaud. In the meantime I wanted to
comment on the purpose of categorising extensions, at least as I see it:

   - Goal: to add clarity and consistency to the process for deciding what
   goes into GHC20xx.
   - Categorising extensions shortcuts the discussion and narrows the
   search space. We've identified a bunch of reasons why extensions will not
   be considered for GHC20xx, so we can just categorise those appropriately
   and we've eliminated a lot of extensions from consideration while providing
   clarity for users.

Cheers
Simon

On Thu, 9 Mar 2023 at 09:17, Arnaud Spiwack <arnaud.spiwack at tweag.io> wrote:

> Simon,
>
> > I made a very concrete suggestion: a table whose rows are extensions,
> and whose columns are described below.  I think it would help us.
>
> You have, and I'm not ignoring it. But it also doesn't seem to have helped
> people converge, so far. I can tell you my personal opinion on your
> proposed columns: they make a lot of sense to me, but I don't think that
> they are the right dimensions that will help answer the questions that
> Joachim initially asked.
>
> I must say that since writing my previous email, I have gotten some
> clarity on categorification (at the expense of some sleep, I'm afraid to
> say, but such are human bodies). I'll get back to it. I'm going to give a
> try to start the conversation from the “what people use extensions for”
> point of view next, though. Let's see if we can find some common ground
> there.
>
>
> Best,
> Arnaud
>
> On Mon, 6 Mar 2023 at 22:27, Adam Gundry <adam at well-typed.com> wrote:
>
>> Dear Arnaud,
>>
>> Thanks for trying to make progress on this! I've also been hesitating in
>> replying to this thread, because I'm not sure of the big picture or what
>> our goal is with the various categorisations. As I indicated in the
>> document, I think we need to start by figuring out "what users need/want
>> from extensions" (though no doubt there are various overlapping
>> purposes). Then we can assess which of those needs are currently
>> under-served.
>>
>> I guess we should also try to figure out what the crucial questions are
>> that we expect the policy document to answer. Some that come to mind for
>> me (but let's not try to answer them all at once!):
>>
>>   * Should it be a goal to reduce the number of extensions and try to
>> converge on a "single Haskell"? Or should we rather aim for many small
>> mostly-orthogonal extensions, even at the cost of a combinatorial
>> explosion of possible "languages"?
>>
>>   * What are the differences in principle between extensions, warnings
>> and other compiler flags? Where reality diverges from these principles,
>> to what extent should fixing that be a priority?
>>
>>   * How frequently should we produce GHC20xx editions? Are the stability
>> expectations for GHC20xx editions different from other extensions?
>>
>> Cheers,
>>
>> Adam
>>
>>
>>
>> On 06/03/2023 08:37, Arnaud Spiwack wrote:
>> > Dear all,
>> >
>> > I waited a bit before answering this thread, as I got quite surprised
>> by
>> > the replies.
>> >
>> > First, the categorisation was meant as purely descriptive, and to
>> > provide us with terminology to speak about policy. In retrospect, the
>> > fact that I didn't manage to find a good name for category (1) and that
>> > I resorted to name it after something the extensions might be for
>> should
>> > have been a tell that the conversation was not going to go as planned
>> > (also I'm slowly realising that “experimental” may not really be a
>> > category in that sense, and probably helped getting the conversation
>> > confused). Let me add that, in my opinion, it would be quite premature
>> > to actually try and categorise or grade extensions now, before we have
>> a
>> > policy.
>> >
>> > Honestly, I think that it's going to be difficult to salvage this
>> > approach, given that there are almost as many different positions on
>> > this than respondents. That being said, I believe that we need some
>> > common terminology or at least a common framework to even start to
>> > discuss policy more deeply, but far from converging, we seem to be
>> > diverging as the conversation progresses.
>> >
>> > Maybe the takeaway from this conversation is that it's difficult, at
>> > least at this stage, to find relevant axes on which to classify what
>> > extensions are, so maybe, we ought to be building our terminology on
>> > what extensions are for. Which we could build on the basis of Adam's
>> > user-stories. I'll come up with a new proposal later this week.
>> >
>> > /Arnaud
>> >
>> >
>> >
>> > On Thu, 2 Mar 2023 at 14:38, Richard Eisenberg <lists at richarde.dev
>> > <mailto:lists at richarde.dev>> wrote:
>> >
>> >     Yes, I think eliminating "obvious" extensions from the need for fine
>> >     scoring is a good idea. Maybe we start by figuring out which these
>> >     should be? I bet we'll kill off about half of what we have, which is
>> >     a nice savings.
>> >
>> >     Richard
>> >
>> >>     On Feb 28, 2023, at 11:30 AM, Simon Peyton Jones
>> >>     <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>>
>> >>     wrote:
>> >>
>> >>     Shall we start with the three columns I described, and the
>> >>     non-scoring enumerations I suggest, and see where we go?  If it's
>> >>     inadequate we can elaborate.  But let's not start with too many
>> >>     categories etc.
>> >>
>> >>     S
>> >>
>> >>     On Tue, 28 Feb 2023 at 14:45, Simon Marlow <marlowsd at gmail.com
>> >>     <mailto:marlowsd at gmail.com>> wrote:
>> >>
>> >>         We definitely *could* assign every extension a 1-5 score on 6+
>> >>         different axes, but I have to admit the thought of actually
>> >>         doing this gives me a sinking feeling! Furthermore I'm not
>> >>         sure what we would do with the results. How do we use the
>> >>         scores to decide what goes into GHC20xx? It feels like we're
>> >>         creating a great deal of work for ourselves.
>> >>
>> >>         The idea of categorising rather than scoring is to shortcut
>> >>         the discussion. If we know that some extension is experimental
>> >>         (e.g. LinearTypes), it just goes in the experimental category
>> >>         and we don't need to think about it any more. If we have an
>> >>         extension that is enabling a deprecated feature, again we
>> >>         don't need to consider any other aspects.
>> >>
>> >>         So, perhaps these axes are useful for extensions that are
>> >>         candidates for GHC20xx and not in one of the other categories
>> >>         2-5 in Arnaud's list. But if we're going to reject extensions
>> >>         from GHC20xx for reasons that are *not* covered by categories
>> >>         2-5 in Arnaud's list, then we should think about what those
>> >>         reasons might be. Is "breaks too many programs" one of them?
>> >>
>> >>         Cheers
>> >>         Simon
>> >>
>> >>         On Fri, 24 Feb 2023 at 18:04, Richard Eisenberg
>> >>         <lists at richarde.dev <mailto:lists at richarde.dev>> wrote:
>> >>
>> >>             Thanks, Arnaud!
>> >>
>> >>             > Q1: Are all the categories 1–5 relevant? If you would
>> >>             like to remove
>> >>             >        some categories, which and why (free form)?
>> >>
>> >>             I'm not really sure I understand Category 1. In
>> >>             particular, I think my initial categorization didn't have
>> >>             Arnaud's Category 1, but instead had
>> >>
>> >>             8. Extensions that enable only new programs, without
>> >>             changing the semantics of any existing program
>> >>
>> >>             This was meant as a counterpoint to 6.
>> >>
>> >>             But my initial categorization was non-orthogonal: for
>> >>             example, this Category 8 overlaps with several other
>> >>             categories. In that way, Joachim's argument that we could
>> >>             imagine two axes of categorization -- one technical, one
>> >>             policy-oriented -- is intriguing. For example,
>> >>             -XDatatypeContexts belongs in Category 8 (it's a syntactic
>> >>             extension), but that doesn't mean it should be
>> on-by-default.
>> >>
>> >>             Along similar lines, Categories 2 and 3 overlap: we might
>> >>             have an experimental language feature that violates a
>> >>             general principle. (Perhaps UndecidableSuperClasses?)
>> >>
>> >>             I tend to think that we'll have an easier time proceeding
>> >>             with 1) orthogonal categories and 2) separation between
>> >>             technical content and policy.
>> >>
>> >>             I thus propose the following taxonomy, where each
>> >>             extension gets rated along each axis.
>> >>
>> >>             A. Is the extension flag purely a language extension? That
>> >>             is, does the flag enable only new programs, without
>> >>             changing the semantics of any existing programs?
>> >>
>> >>             Possible answers: sliding scale 1-5, where 1 means
>> >>             "programs written and widely used today would break and/or
>> >>             change meaning" and 5 means "no programs at all change
>> >>             meaning". It's a sliding scale to account for the fact
>> >>             that e.g. -XTypeFamilies once upon a time meant that all
>> >>             programs retain meanings... except for ones which name a
>> >>             type variable `family`. (Now, `family` is unconditionally
>> >>             a keyword in types, so -XTypeFamilies is, I believe, a 5.)
>> >>             So if there are obscure programs that change meaning, we
>> >>             can use 2, 3, and 4 as a way of stating how obscure the
>> >>             programs are. (Higher number = more obscure.)
>> >>
>> >>             B. How stable is the extension flag?
>> >>
>> >>             Possible answers: sliding scale 1-5, where 1 means "likely
>> >>             to change soon" and 5 means "as unlikely to change as the
>> >>             definition of Monad". (That was chosen deliberately: we
>> >>             *did* change the definition of Monad!) For me, a criterion
>> >>             required to write 5 here would be the possibility of
>> >>             writing down a formal specification of the extension. (So
>> >>             -XGADTs could not be a 5.)
>> >>
>> >>             C. Would a user always want to enable this extension for
>> >>             an entire file (as opposed to for local regions)?
>> >>
>> >>             Possible answers: sliding scale 1-5, where 1 means "there
>> >>             shouldn't even be a way to enable it for a whole file" and
>> >>             5 means "no -- a user who wants this flag would want it
>> >>             for the whole file". I would put GADTSyntax as a 5 and
>> >>             OverlappingInstances as a 1. GADTs would (for me) be a 4,
>> >>             because maybe someone wants to say that one part of a file
>> >>             is more type-y than the rest.
>> >>
>> >>             D. How much do we like the extension?
>> >>
>> >>             Possible answers: sliding scale 1-5, where 1 means "this
>> >>             shouldn't be here" and 5 means "I want this on by default
>> >>             (ignoring backward compatibility)". -XDatatypeContexts
>> >>             would be a 1: we should never have had that in the
>> >>             language. -XOverloadedStrings would be a 5: even if we
>> >>             don't want it enabled everywhere, it's a vastly useful
>> >>             extension that lots of people depend on.
>> >>
>> >>             E. Does the extension flag change the language, as opposed
>> >>             to the operation of the compiler?
>> >>
>> >>             Possible answers: sliding scale 1-5, where 1 means "purely
>> >>             about the compiler operation" and 5 means "purely about
>> >>             the language". Most extensions (e.g. -XPolyKinds) would be
>> >>             5; -XCPP would be 1. I would put -XTemplateHaskell around
>> >>             a 4, because it's mostly about the language, but it
>> >>             impacts cross-compilation and recompilation avoidance.
>> >>             -XSafe is a 2: it affects the way instances are selected,
>> >>             I think.
>> >>
>> >>             F. How broad is the use-case for the extension?
>> >>
>> >>             Possible answers: sliding scale 1-5, where 1 means "very
>> >>             specialized" and 5 is "broadly useful in many contexts". I
>> >>             would put -XMultiParamTypeClasses at a 5 and -XMagicHash
>> >>             at a 2. I'm struggling to come up with something so
>> >>             specialized as to be worth a 1. I would say -XTypeFamilies
>> >>             and -XGADTs are 4.
>> >>
>> >>             I think these questions A-F cover the range of categories
>> >>             Arnaud proposes, while addressing Joachim's and Simon M's
>> >>             desires to keep separate things separate. Having each
>> >>             question have a sliding-scale answer is also nice: it
>> >>             means we can submit our classifications of each extension
>> >>             and just average the results. This avoids time wasted in
>> >>             debate. (You can even submit decimals in the range 1-5, if
>> >>             you like!) I would propose that we highlight and debate
>> >>             any question/extension pair where the (max - min) > 2, as
>> >>             there may be disagreement about what the extension or the
>> >>             question means. And we have a natural way to identify
>> >>             candidates for inclusion in GHC20XX: multiply (or add; I
>> >>             think multiply) the 6 scores for an extension and then set
>> >>             a threshold for acceptance. (I don't think we would do
>> >>             this blindly, at all, but it would offer a wonderful
>> >>             starting-point.)
>> >>
>> >>             Having upended the table and made a mess of things, I will
>> >>             now answer the other questions ignoring this new proposal.
>> >>
>> >>             > Q2: Is category 6 relevant?
>> >>
>> >>             Yes, but it's on the wrong axis.
>> >>
>> >>             > Q2.Y: If you found category 6 to be relevant: should it
>> >>             be its own
>> >>             >            category, or should it be a subcategory of 1?
>> >>
>> >>             I see 6 and 1 not having a relationship: 6 is about
>> >>             syntax, while 1 is about whether we like an extension.
>> >>
>> >>             > Q3: Is category 7 relevant?
>> >>
>> >>             Yes.
>> >>
>> >>             > Q3.Y: If you found category 7 to be relevant: should it
>> >>             be its own
>> >>             >            category or should it be a subcategory of 5?
>> >>
>> >>             Hard to say. MagicHash and UnboxedTuples could in theory
>> >>             be flags. But maybe there are other 7s that wouldn't?
>> >>
>> >>             >  Q4: In which category would you classify Strict?
>> >>
>> >>             5, in that Strict is a compiler flag, but it doesn't
>> >>             certainly change the language.
>> >>
>> >>             >  Q5: Is there any category that you feel is missing from
>> >>             the list? If
>> >>             >        so, please argue (free form).
>> >>
>> >>             I've done that enough already. :)
>> >>
>> >>             Richard
>>
>> --
>> 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
>>
>> _______________________________________________
>> 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/20230309/20856c49/attachment-0001.html>

From mail at joachim-breitner.de  Thu Mar  9 23:23:06 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 10 Mar 2023 00:23:06 +0100
Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?=
 =?utf-8?b?4oCTIFJvdW5kIDE=?=
In-Reply-To: <CANsrgPLfCQPFq7YRh0a3j9JJbjU8y7aRyPYBU+bpvRA1vft4Ng@mail.gmail.com>
References: <CAGwnsnn=rY=Xzwi23HjQ2zGSRAhtqAS8Xi8Em6M5oqfpG3aYWw@mail.gmail.com>
 <010f018684991b10-761d0bd6-4151-41af-9a56-5cce6ff0aeaa-000000@us-east-2.amazonses.com>
 <CANsrgP+VQLop_UyLudEweB0m1ApaXFDPdnTyTTYm+CYJudYN=g@mail.gmail.com>
 <CAJKmMz8KyaM4j5vK+4z3je3hxB2F9bCBUChmFFEJqbuEBMzjgA@mail.gmail.com>
 <010f0186a28b88ff-d308e836-2389-4f65-a43d-93312f820f7e-000000@us-east-2.amazonses.com>
 <CAGwnsnnXsJTDg5eeVTKdp7O09m9ea9mE5wLHeTMjRzWwEFEYmA@mail.gmail.com>
 <d8b79679-fbe0-2a86-7b00-47e5e5eed2aa@well-typed.com>
 <CAGwnsn=7w7=u4Kf85mpiCM89Ln8gr+Kubr4q+qrvF3GenDTewA@mail.gmail.com>
 <CANsrgPLfCQPFq7YRh0a3j9JJbjU8y7aRyPYBU+bpvRA1vft4Ng@mail.gmail.com>
Message-ID: <763798bb453f18baf6b62ac1ed0bab8b2e9751d6.camel@joachim-breitner.de>

Hi,

Am Donnerstag, dem 09.03.2023 um 17:41 +0000 schrieb Simon Marlow:
> Looking forward to your proposal Arnaud. In the meantime I wanted to
> comment on the purpose of categorising extensions, at least as I see
> it:
>  * Goal: to add clarity and consistency to the process for deciding
> what goes into GHC20xx.
>  * Categorising extensions shortcuts the discussion and narrows the
> search space. We've identified a bunch of reasons why extensions will
> not be considered for GHC20xx, so we can just categorise those
> appropriately and we've eliminated a lot of extensions from
> consideration while providing clarity for users.

right, but this is not just about GHC20xx, is it?

Having some more objective characteristics of extensions spelled out
will help us making other decisions more consistently as well
(accepting proposals for new extensions, extending existing extensions,
changing existing extensions etc.)

Cheers,
Joachim


-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/


From arnaud.spiwack at tweag.io  Fri Mar 10 07:46:34 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Fri, 10 Mar 2023 08:46:34 +0100
Subject: [ghc-steering-committee] #330: Decorate exceptions with
 backtrace information, rec: accept
In-Reply-To: <CAGwnsn=4Oavgq+YEnHVM8A=LW5LfSgsk9GcFpZoQkG+qBNPdcw@mail.gmail.com>
References: <CAHZ0NLr6-zMeNdFK-DbvemJ3pJ4hz4JZFfKoYrW1AxGqDnbnZA@mail.gmail.com>
 <CANsrgPL_VNngGx_SkmQDa6ACOvNoza1GqLr27EvtmrQa_ho2EQ@mail.gmail.com>
 <CAGwnsnmCEGW_eDdE58+WebxLk_7MUzzrYyKkyC7aP517kzvOzw@mail.gmail.com>
 <CANsrgPLVnZSEjhUqN=UfVw1JALSENTN9ni_PgNNDOu2sZd96+A@mail.gmail.com>
 <CAGwnsn=4Oavgq+YEnHVM8A=LW5LfSgsk9GcFpZoQkG+qBNPdcw@mail.gmail.com>
Message-ID: <CAGwnsnnsQUVa8fuYWJ68g9Q5c+q74ggDcu4m0Ja6WXeXhzZnew@mail.gmail.com>

My questions have been addressed, I'm now content with the proposal.

On Thu, 9 Mar 2023 at 18:03, Arnaud Spiwack <arnaud.spiwack at tweag.io> wrote:

> On Thu, 9 Mar 2023 at 12:52, Simon Marlow <marlowsd at gmail.com> wrote:
>
>> Out of interest, why?
>>
>
>  I'm not sure that I can quite say. The idea of annotations being somewhat
> implicitly passed, the symmetry with `HasCallStack`: it appeals to me. I
> guess it's not a very strong preference.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230310/03a0a455/attachment.html>

From adam at well-typed.com  Fri Mar 10 09:15:22 2023
From: adam at well-typed.com (Adam Gundry)
Date: Fri, 10 Mar 2023 09:15:22 +0000
Subject: [ghc-steering-committee] #536: Type-level literals as a
 separate language extension, rec: accept
In-Reply-To: <010f0186c72d3aa5-5163b078-0956-46e8-9e41-c2d206f6273c-000000@us-east-2.amazonses.com>
References: <CAHZ0NLoao=NF38m7uHHj4+trWMgcyN7gPZg3E+ET+zQTd-cK9g@mail.gmail.com>
 <b2a7f83a60faeb6478acbe28d9d94c57f90740d6.camel@joachim-breitner.de>
 <CAJKmMz_iF3KckSATgHetX8NL2rWqjAGTwP1j11xxBvu-9OoYaw@mail.gmail.com>
 <c07162d7324d6cba101bee0bce2e9e3fb97c3e23.camel@joachim-breitner.de>
 <CAHZ0NLpUf9JYmaGYfJzWtc41NWxtY7fLUJu395vme6e0nmmkgw@mail.gmail.com>
 <efc0baf49b2bc4451bec25d88c35e1c1af155edf.camel@joachim-breitner.de>
 <CAGwnsnny_-PZED5y6RfDaLYwWP==NeK-zvoF3pEbyV1yy5yvBQ@mail.gmail.com>
 <010f0186c72d3aa5-5163b078-0956-46e8-9e41-c2d206f6273c-000000@us-east-2.amazonses.com>
Message-ID: <882d3cac-00e6-7dfd-b32d-69968856b8ba@well-typed.com>

This proposal is very helpful in exposing some of the divisions about 
the interpretation of extensions that exist within the committee! "Let a 
thousand flowers bloom" vs "more-extensions-make-me-wince", if you like.

For what it's worth I tend to be in the former camp. I think we should 
strive for orthogonality and avoid bundling together distinct features 
merely because they have related effects. Instead we should construct 
our language via composition of simple components. And I think it's 
reasonable to say that TypeLevelLiterals and (the rest of) DataKinds are 
clearly distinct and can be understood in isolation.

If the number of extensions is a problem, that points to the need to 
better structure our documentation and gather coherent subsets of 
extensions into manageable pieces (much as GHC2021 tries to do). Beyond 
that I'd like to understand the downsides better (e.g. what costs does 
it actually impose on HLS to have another extension?).

A conversation with one of the authors of Helium this week made me think 
that in the GHC proposals process we have tended to neglect the possible 
presence of other Haskell implementations. It's not realistic to expect 
that anyone will reimplement the whole of GHC Haskell, but perhaps there 
is a fragment large enough to be useful for a fair number of Haskell 
programs but also small enough to be independently implemented (e.g. by 
Helium). It would strike me as plausible that such an implementation 
might want to support TypeData+TypeLevelLiterals but not DataKinds.

Adam


On 09/03/2023 16:21, Richard Eisenberg wrote:
> Though I see the arguments in the other direction, I vote against this 
> proposal. As Joachim argues, adding an extension puts a tax on the 
> entire ecosystem by adding one more bit of context a reader has to have 
> to understand code. In addition, HLS will have to be aware of this 
> extension. And the benefits seem pretty marginal here.
> 
> Can we instead simply provide a warning? The warning here would be 
> something like the -Wpuns idea, in that it helps the author keep to a 
> particular subset of the language. (We might want to collect such 
> warnings somehow in our documentation.)
> 
> Actually, it occurs to me we already have the warning: 
> -Wunticked-promoted-constructors. We've put that warning in the 
> -Weverything bin (not even -Wall) because in the past we've decided that 
> we shouldn't recommend/require the ' when using a constructor in a type. 
> But actually, setting -Werror=unticked-promoted-constructors would seem 
> to be a perfect substitute for -XTypeLevelLiterals -XNoDataKinds. OK, 
> not perfect: you could still use a constructor in a type with a ' mark. 
> But I think that's great, actually, because perhaps an author wary of 
> constructors in types still might need to use one, in one place, in a 
> 2,000-line file. This ticks all the boxes (ha ha).
> 
> Having discovered this replacement, I'm now pretty strongly against this 
> proposal. I'll also post on GitHub.
> 
> Richard
> 
>> On Mar 9, 2023, at 4:26 AM, Arnaud Spiwack <arnaud.spiwack at tweag.io 
>> <mailto:arnaud.spiwack at tweag.io>> wrote:
>>
>> I can see where the author is coming from. But as Joachim, I find 
>> myself unconvinced that it is worth yet one extra extension (but then 
>> again, I'm the more-extensions-make-me-wince member of this committee).
>>
>> On Wed, 8 Mar 2023 at 13:56, Joachim Breitner 
>> <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
>>
>>     Hi,
>>
>>     Am Mittwoch, dem 08.03.2023 um 14:58 +0300 schrieb Vladislav Zavialov:
>>     > DataKinds is indeed a "bad" extension because it introduces
>>     ambiguity
>>     > to name resolution.
>>     >
>>     > There are two ways to avoid this issue:
>>     > 1. Keep namespaces separate and double down on using punned
>>     > constructor names.
>>     > 2. Merge terms and types, discouraging punned constructor names.
>>     >
>>     > Each approach could indeed lead to a "dialect" of sorts.
>>     >
>>     > * The (accepted and recently implemented) TypeData extension
>>     moves us
>>     > in the direction of option (1), and I imagine the proposed
>>     > TypeLevelLiterals would be often used in conjunction with TypeData.
>>     > This carves out a limited, conservative language subset for type-
>>     > level programming.
>>     > * At the same time, #270 "Support pun-free code" moves us in the
>>     > direction of option (2), and I expect it to be the better option
>>     when
>>     > it comes to fully fledged dependently-typed programming
>>     envisioned by
>>     > #378.
>>     >
>>     > If I had to choose, I'd go with option (2). I don't see myself using
>>     > TypeData, nor TypeLevelLiterals for that matter. But I am of a
>>     "let a
>>     > thousand flowers bloom" persuasion, hence my recommendation to
>>     > accept.
>>
>>
>>     Thanks for putting this into a clearer context.
>>
>>     Where does DataKind fit in? Is it a natural part of approach (2)
>>     (which
>>     is the general direction outlined by #378), or is yet another take on
>>     the issue?
>>     If DataKinds was not what we want according to #378, but the fragment
>>     carved out by TypeLevelLiterals was, then that would be a strong
>>     reason
>>     for me to acccept TypeLevelLiterals.
>>     But if DataKinds is the goal (or at least “the” goal), then I
>>     think I’d
>>     like to see stronger arguments for why it should be split.
>>
>>
>>     Cheers,
>>     Joachim
>>
>>     -- 
>>     Joachim Breitner
>>     mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>
>>     http://www.joachim-breitner.de/ <http://www.joachim-breitner.de/>

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


From mail at joachim-breitner.de  Thu Mar 16 13:59:05 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 16 Mar 2023 14:59:05 +0100
Subject: [ghc-steering-committee] GHC Steering Committee Status
Message-ID: <79e94b6b9909d1d1a10966aeefa34eccc54df907.camel@joachim-breitner.de>

Dear Committee,

it’s not quite yet spring time. But it is always GHC Steering Committee
time. So let’s see where we are.

What has happened since the last one update (January 19)?

 * We decided not to have GHC2023.

 * Arnaud took on the daunting task of writing down more concrete policies
   about what role language Extensions have these days, where the committee
   wants to steer the language to, and what implications that has for our work.

 * We welcomed Moritz Angerman as a new member (and changed the bylaws
   a bit to make that possible)
 
   Tom stepped down from the committee. Thanks Tom!

 * we were asked to review these proposals:
  
   #330: Decorate exceptions with backtrace information, rec: accept
   #536: Type-level literals as a sep language extension, Shepherd: Vlad

 * we have a recommendation from the shepherd about:

   #540: parallelism semaphores, rec: accept
   #330: Decorate exceptions with backtrace information, rec: accept
   #536: Type-level literals as a sep language extension, rec: accept

 * we have sent the following proposals back to revision

   #270: Support pun-free code
   #515: Relaxing HasField constraints
   #562  Make Symbol a newtype over String (originally #546)
   #529: Template Haskell quotes as patterns

 * we decided about the following proposals

   #555: Higher Order Patterns in Rewrite Rules (accept)
   #556: fix signature scoping #448 (accept)

 * we fast-tracked two amendments to existing proposals:

   #573: No #. label
   #576: Warning Category syntax

We currently have to act on the following 6 proposals, 4 down.
Good trend, let’s continue it! (Note that we sent 4 back to revision,
which means they’ll come back…)

## Waiting for committee decision

#532: Clean up implicit binding, Shepherd: Arnaud   
      2022-08-23: Assigned to Arnaud
      Sent back for revision
      2022-11-27: Resubmitted
      2022-12-14: Arnaud recommends acceptance
      2023-01-17: Arnaud picks up the conversation again.
      Silence since.

#512: NoFieldSelectors as datatype annotation, Shepherd: Vlad
      2022-09-03: Assigned to Baldur
      2022-10-02: Reassignd to Vlad
      2022-11-30: Vlad recommends rejection
      Turned into a discussion of Modifiers, and then
      into silence.  Where are we on this one?

#540: jsem parallelism semaphores, Shepherd: Eric 
      2022-11-08: Assigned to Adam
      2022-11-17: Re-assigned to Eric
      2023-02-12: Eric recommends acceptance
      Lots of discussion on the list and on Github.
      Is this near conclusion, or should it go back to revision?

#536: Type-level literals as a sep language extension, Shepherd: Vlad
      2023-02-16 Assigned to Vlad
      2023-03-06 Vlad recommends acceptance
      Some hesitancy in the committee to introduce this extension,
      the ongoing policy clarification process might guide us, 
      but maybe we can resolve this earlier?

#330: Decorate exceptions with backtrace information, Shepherd: Vlad
      2023-03-06: Vlad recommends acceptance.
      Some active discussion on Github. Is this steering towards
      a conclusion?

## Waiting for shepherd recommendation

#526: Applicative Comprehensions, Shepherd: Simon M
      2022-10-08: Assigned to Simon M
      Simon, can you cast your recommendation?

Cheers,
Joachim

-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/


From eric at seidel.io  Sat Mar 18 15:14:18 2023
From: eric at seidel.io (Eric Seidel)
Date: Sat, 18 Mar 2023 11:14:18 -0400
Subject: [ghc-steering-committee] GHC Steering Committee Status
In-Reply-To: <79e94b6b9909d1d1a10966aeefa34eccc54df907.camel@joachim-breitner.de>
References: <79e94b6b9909d1d1a10966aeefa34eccc54df907.camel@joachim-breitner.de>
Message-ID: <2420e387-ec74-4466-a30c-9f4b765cda26@app.fastmail.com>

On Thu, Mar 16, 2023, at 09:59, Joachim Breitner wrote:

> #540: jsem parallelism semaphores, Shepherd: Eric 
>       2022-11-08: Assigned to Adam
>       2022-11-17: Re-assigned to Eric
>       2023-02-12: Eric recommends acceptance
>       Lots of discussion on the list and on Github.
>       Is this near conclusion, or should it go back to revision?

I think this one is basically good to merge. Simon PJ had asked for a couple clarifications to the text, which the authors just did. I'll pinged Simon just now to review the edits, and then we should be set.

From lists at richarde.dev  Sun Mar 19 21:09:32 2023
From: lists at richarde.dev (Richard Eisenberg)
Date: Sun, 19 Mar 2023 21:09:32 +0000
Subject: [ghc-steering-committee] #536: Type-level literals as a
 separate language extension, rec: accept
In-Reply-To: <882d3cac-00e6-7dfd-b32d-69968856b8ba@well-typed.com>
References: <CAHZ0NLoao=NF38m7uHHj4+trWMgcyN7gPZg3E+ET+zQTd-cK9g@mail.gmail.com>
 <b2a7f83a60faeb6478acbe28d9d94c57f90740d6.camel@joachim-breitner.de>
 <CAJKmMz_iF3KckSATgHetX8NL2rWqjAGTwP1j11xxBvu-9OoYaw@mail.gmail.com>
 <c07162d7324d6cba101bee0bce2e9e3fb97c3e23.camel@joachim-breitner.de>
 <CAHZ0NLpUf9JYmaGYfJzWtc41NWxtY7fLUJu395vme6e0nmmkgw@mail.gmail.com>
 <efc0baf49b2bc4451bec25d88c35e1c1af155edf.camel@joachim-breitner.de>
 <CAGwnsnny_-PZED5y6RfDaLYwWP==NeK-zvoF3pEbyV1yy5yvBQ@mail.gmail.com>
 <010f0186c72d3aa5-5163b078-0956-46e8-9e41-c2d206f6273c-000000@us-east-2.amazonses.com>
 <882d3cac-00e6-7dfd-b32d-69968856b8ba@well-typed.com>
Message-ID: <010f0186fbb4bf37-10d8c856-9c2e-47c0-9edf-e0af23097fbc-000000@us-east-2.amazonses.com>

This argument gave me pause. Thanks, Adam. I think, for me, it comes down to this: what do we think will be more useful to more of our users? A notion of a core language -- perhaps implemented by different compilers -- with extensions? Or a unified language GHC/Haskell which allows subsetting? I tend to think the latter, though I'm not sure.

Regarding this particular proposal: I remain against the proposal, as it duplicates an existing feature. That's a simple reason to be against a proposal.

Richard

> On Mar 10, 2023, at 9:15 AM, Adam Gundry <adam at well-typed.com> wrote:
> 
> This proposal is very helpful in exposing some of the divisions about the interpretation of extensions that exist within the committee! "Let a thousand flowers bloom" vs "more-extensions-make-me-wince", if you like.
> 
> For what it's worth I tend to be in the former camp. I think we should strive for orthogonality and avoid bundling together distinct features merely because they have related effects. Instead we should construct our language via composition of simple components. And I think it's reasonable to say that TypeLevelLiterals and (the rest of) DataKinds are clearly distinct and can be understood in isolation.
> 
> If the number of extensions is a problem, that points to the need to better structure our documentation and gather coherent subsets of extensions into manageable pieces (much as GHC2021 tries to do). Beyond that I'd like to understand the downsides better (e.g. what costs does it actually impose on HLS to have another extension?).
> 
> A conversation with one of the authors of Helium this week made me think that in the GHC proposals process we have tended to neglect the possible presence of other Haskell implementations. It's not realistic to expect that anyone will reimplement the whole of GHC Haskell, but perhaps there is a fragment large enough to be useful for a fair number of Haskell programs but also small enough to be independently implemented (e.g. by Helium). It would strike me as plausible that such an implementation might want to support TypeData+TypeLevelLiterals but not DataKinds.
> 
> Adam
> 
> 
> On 09/03/2023 16:21, Richard Eisenberg wrote:
>> Though I see the arguments in the other direction, I vote against this proposal. As Joachim argues, adding an extension puts a tax on the entire ecosystem by adding one more bit of context a reader has to have to understand code. In addition, HLS will have to be aware of this extension. And the benefits seem pretty marginal here.
>> Can we instead simply provide a warning? The warning here would be something like the -Wpuns idea, in that it helps the author keep to a particular subset of the language. (We might want to collect such warnings somehow in our documentation.)
>> Actually, it occurs to me we already have the warning: -Wunticked-promoted-constructors. We've put that warning in the -Weverything bin (not even -Wall) because in the past we've decided that we shouldn't recommend/require the ' when using a constructor in a type. But actually, setting -Werror=unticked-promoted-constructors would seem to be a perfect substitute for -XTypeLevelLiterals -XNoDataKinds. OK, not perfect: you could still use a constructor in a type with a ' mark. But I think that's great, actually, because perhaps an author wary of constructors in types still might need to use one, in one place, in a 2,000-line file. This ticks all the boxes (ha ha).
>> Having discovered this replacement, I'm now pretty strongly against this proposal. I'll also post on GitHub.
>> Richard
>>> On Mar 9, 2023, at 4:26 AM, Arnaud Spiwack <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>> wrote:
>>> 
>>> I can see where the author is coming from. But as Joachim, I find myself unconvinced that it is worth yet one extra extension (but then again, I'm the more-extensions-make-me-wince member of this committee).
>>> 
>>> On Wed, 8 Mar 2023 at 13:56, Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
>>> 
>>>    Hi,
>>> 
>>>    Am Mittwoch, dem 08.03.2023 um 14:58 +0300 schrieb Vladislav Zavialov:
>>>    > DataKinds is indeed a "bad" extension because it introduces
>>>    ambiguity
>>>    > to name resolution.
>>>    >
>>>    > There are two ways to avoid this issue:
>>>    > 1. Keep namespaces separate and double down on using punned
>>>    > constructor names.
>>>    > 2. Merge terms and types, discouraging punned constructor names.
>>>    >
>>>    > Each approach could indeed lead to a "dialect" of sorts.
>>>    >
>>>    > * The (accepted and recently implemented) TypeData extension
>>>    moves us
>>>    > in the direction of option (1), and I imagine the proposed
>>>    > TypeLevelLiterals would be often used in conjunction with TypeData.
>>>    > This carves out a limited, conservative language subset for type-
>>>    > level programming.
>>>    > * At the same time, #270 "Support pun-free code" moves us in the
>>>    > direction of option (2), and I expect it to be the better option
>>>    when
>>>    > it comes to fully fledged dependently-typed programming
>>>    envisioned by
>>>    > #378.
>>>    >
>>>    > If I had to choose, I'd go with option (2). I don't see myself using
>>>    > TypeData, nor TypeLevelLiterals for that matter. But I am of a
>>>    "let a
>>>    > thousand flowers bloom" persuasion, hence my recommendation to
>>>    > accept.
>>> 
>>> 
>>>    Thanks for putting this into a clearer context.
>>> 
>>>    Where does DataKind fit in? Is it a natural part of approach (2)
>>>    (which
>>>    is the general direction outlined by #378), or is yet another take on
>>>    the issue?
>>>    If DataKinds was not what we want according to #378, but the fragment
>>>    carved out by TypeLevelLiterals was, then that would be a strong
>>>    reason
>>>    for me to acccept TypeLevelLiterals.
>>>    But if DataKinds is the goal (or at least “the” goal), then I
>>>    think I’d
>>>    like to see stronger arguments for why it should be split.
>>> 
>>> 
>>>    Cheers,
>>>    Joachim
>>> 
>>>    --     Joachim Breitner
>>>    mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>
>>>    http://www.joachim-breitner.de/ <http://www.joachim-breitner.de/>
> 
> -- 
> 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
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


From simon.peytonjones at gmail.com  Mon Mar 20 08:43:55 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Mon, 20 Mar 2023 08:43:55 +0000
Subject: [ghc-steering-committee] #536: Type-level literals as a
 separate language extension, rec: accept
In-Reply-To: <010f0186fbb4bf37-10d8c856-9c2e-47c0-9edf-e0af23097fbc-000000@us-east-2.amazonses.com>
References: <CAHZ0NLoao=NF38m7uHHj4+trWMgcyN7gPZg3E+ET+zQTd-cK9g@mail.gmail.com>
 <b2a7f83a60faeb6478acbe28d9d94c57f90740d6.camel@joachim-breitner.de>
 <CAJKmMz_iF3KckSATgHetX8NL2rWqjAGTwP1j11xxBvu-9OoYaw@mail.gmail.com>
 <c07162d7324d6cba101bee0bce2e9e3fb97c3e23.camel@joachim-breitner.de>
 <CAHZ0NLpUf9JYmaGYfJzWtc41NWxtY7fLUJu395vme6e0nmmkgw@mail.gmail.com>
 <efc0baf49b2bc4451bec25d88c35e1c1af155edf.camel@joachim-breitner.de>
 <CAGwnsnny_-PZED5y6RfDaLYwWP==NeK-zvoF3pEbyV1yy5yvBQ@mail.gmail.com>
 <010f0186c72d3aa5-5163b078-0956-46e8-9e41-c2d206f6273c-000000@us-east-2.amazonses.com>
 <882d3cac-00e6-7dfd-b32d-69968856b8ba@well-typed.com>
 <010f0186fbb4bf37-10d8c856-9c2e-47c0-9edf-e0af23097fbc-000000@us-east-2.amazonses.com>
Message-ID: <CAJKmMz8sGnBRRqS=3GGfGe8SLHAx3gERo-5Wt2Jjm7f8YY-wHA@mail.gmail.com>

Personally I'm happy with having orthogonal extensions that enable just one
thing.  That allows our users to do what they want, rather than telling
them what they want.

On this particular proposal I don't think it's a big deal either way, but
I'd vote in favour.  It's not exactly true to say that it duplicates an
existing feature.  I think Richard's point is that you can get a warning
for using an unticked constructor (but nothing for using a ticked one).
That's different from getting an error if you use a constructor in a type,
ticked or not.

This particular proposal is easy to describe and easy to implement.  But I
don't think we should burn a lot of cycles on it... it's a matter of taste,
so we could just vote.

Simon

On Sun, 19 Mar 2023 at 21:09, Richard Eisenberg <lists at richarde.dev> wrote:

> This argument gave me pause. Thanks, Adam. I think, for me, it comes down
> to this: what do we think will be more useful to more of our users? A
> notion of a core language -- perhaps implemented by different compilers --
> with extensions? Or a unified language GHC/Haskell which allows subsetting?
> I tend to think the latter, though I'm not sure.
>
> Regarding this particular proposal: I remain against the proposal, as it
> duplicates an existing feature. That's a simple reason to be against a
> proposal.
>
> Richard
>
> > On Mar 10, 2023, at 9:15 AM, Adam Gundry <adam at well-typed.com> wrote:
> >
> > This proposal is very helpful in exposing some of the divisions about
> the interpretation of extensions that exist within the committee! "Let a
> thousand flowers bloom" vs "more-extensions-make-me-wince", if you like.
> >
> > For what it's worth I tend to be in the former camp. I think we should
> strive for orthogonality and avoid bundling together distinct features
> merely because they have related effects. Instead we should construct our
> language via composition of simple components. And I think it's reasonable
> to say that TypeLevelLiterals and (the rest of) DataKinds are clearly
> distinct and can be understood in isolation.
> >
> > If the number of extensions is a problem, that points to the need to
> better structure our documentation and gather coherent subsets of
> extensions into manageable pieces (much as GHC2021 tries to do). Beyond
> that I'd like to understand the downsides better (e.g. what costs does it
> actually impose on HLS to have another extension?).
> >
> > A conversation with one of the authors of Helium this week made me think
> that in the GHC proposals process we have tended to neglect the possible
> presence of other Haskell implementations. It's not realistic to expect
> that anyone will reimplement the whole of GHC Haskell, but perhaps there is
> a fragment large enough to be useful for a fair number of Haskell programs
> but also small enough to be independently implemented (e.g. by Helium). It
> would strike me as plausible that such an implementation might want to
> support TypeData+TypeLevelLiterals but not DataKinds.
> >
> > Adam
> >
> >
> > On 09/03/2023 16:21, Richard Eisenberg wrote:
> >> Though I see the arguments in the other direction, I vote against this
> proposal. As Joachim argues, adding an extension puts a tax on the entire
> ecosystem by adding one more bit of context a reader has to have to
> understand code. In addition, HLS will have to be aware of this extension.
> And the benefits seem pretty marginal here.
> >> Can we instead simply provide a warning? The warning here would be
> something like the -Wpuns idea, in that it helps the author keep to a
> particular subset of the language. (We might want to collect such warnings
> somehow in our documentation.)
> >> Actually, it occurs to me we already have the warning:
> -Wunticked-promoted-constructors. We've put that warning in the
> -Weverything bin (not even -Wall) because in the past we've decided that we
> shouldn't recommend/require the ' when using a constructor in a type. But
> actually, setting -Werror=unticked-promoted-constructors would seem to be a
> perfect substitute for -XTypeLevelLiterals -XNoDataKinds. OK, not perfect:
> you could still use a constructor in a type with a ' mark. But I think
> that's great, actually, because perhaps an author wary of constructors in
> types still might need to use one, in one place, in a 2,000-line file. This
> ticks all the boxes (ha ha).
> >> Having discovered this replacement, I'm now pretty strongly against
> this proposal. I'll also post on GitHub.
> >> Richard
> >>> On Mar 9, 2023, at 4:26 AM, Arnaud Spiwack <arnaud.spiwack at tweag.io
> <mailto:arnaud.spiwack at tweag.io>> wrote:
> >>>
> >>> I can see where the author is coming from. But as Joachim, I find
> myself unconvinced that it is worth yet one extra extension (but then
> again, I'm the more-extensions-make-me-wince member of this committee).
> >>>
> >>> On Wed, 8 Mar 2023 at 13:56, Joachim Breitner <
> mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
> >>>
> >>>    Hi,
> >>>
> >>>    Am Mittwoch, dem 08.03.2023 um 14:58 +0300 schrieb Vladislav
> Zavialov:
> >>>    > DataKinds is indeed a "bad" extension because it introduces
> >>>    ambiguity
> >>>    > to name resolution.
> >>>    >
> >>>    > There are two ways to avoid this issue:
> >>>    > 1. Keep namespaces separate and double down on using punned
> >>>    > constructor names.
> >>>    > 2. Merge terms and types, discouraging punned constructor names.
> >>>    >
> >>>    > Each approach could indeed lead to a "dialect" of sorts.
> >>>    >
> >>>    > * The (accepted and recently implemented) TypeData extension
> >>>    moves us
> >>>    > in the direction of option (1), and I imagine the proposed
> >>>    > TypeLevelLiterals would be often used in conjunction with
> TypeData.
> >>>    > This carves out a limited, conservative language subset for type-
> >>>    > level programming.
> >>>    > * At the same time, #270 "Support pun-free code" moves us in the
> >>>    > direction of option (2), and I expect it to be the better option
> >>>    when
> >>>    > it comes to fully fledged dependently-typed programming
> >>>    envisioned by
> >>>    > #378.
> >>>    >
> >>>    > If I had to choose, I'd go with option (2). I don't see myself
> using
> >>>    > TypeData, nor TypeLevelLiterals for that matter. But I am of a
> >>>    "let a
> >>>    > thousand flowers bloom" persuasion, hence my recommendation to
> >>>    > accept.
> >>>
> >>>
> >>>    Thanks for putting this into a clearer context.
> >>>
> >>>    Where does DataKind fit in? Is it a natural part of approach (2)
> >>>    (which
> >>>    is the general direction outlined by #378), or is yet another take
> on
> >>>    the issue?
> >>>    If DataKinds was not what we want according to #378, but the
> fragment
> >>>    carved out by TypeLevelLiterals was, then that would be a strong
> >>>    reason
> >>>    for me to acccept TypeLevelLiterals.
> >>>    But if DataKinds is the goal (or at least “the” goal), then I
> >>>    think I’d
> >>>    like to see stronger arguments for why it should be split.
> >>>
> >>>
> >>>    Cheers,
> >>>    Joachim
> >>>
> >>>    --     Joachim Breitner
> >>>    mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>
> >>>    http://www.joachim-breitner.de/ <http://www.joachim-breitner.de/>
> >
> > --
> > 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
> >
> > _______________________________________________
> > 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/20230320/7058763d/attachment-0001.html>

From chris at chrisdornan.com  Mon Mar 20 17:08:19 2023
From: chris at chrisdornan.com (Chris Dornan)
Date: Mon, 20 Mar 2023 17:08:19 +0000
Subject: [ghc-steering-committee] #536: Type-level literals as a
 separate language extension, rec: accept
In-Reply-To: <CAJKmMz8sGnBRRqS=3GGfGe8SLHAx3gERo-5Wt2Jjm7f8YY-wHA@mail.gmail.com>
References: <CAHZ0NLoao=NF38m7uHHj4+trWMgcyN7gPZg3E+ET+zQTd-cK9g@mail.gmail.com>
 <b2a7f83a60faeb6478acbe28d9d94c57f90740d6.camel@joachim-breitner.de>
 <CAJKmMz_iF3KckSATgHetX8NL2rWqjAGTwP1j11xxBvu-9OoYaw@mail.gmail.com>
 <c07162d7324d6cba101bee0bce2e9e3fb97c3e23.camel@joachim-breitner.de>
 <CAHZ0NLpUf9JYmaGYfJzWtc41NWxtY7fLUJu395vme6e0nmmkgw@mail.gmail.com>
 <efc0baf49b2bc4451bec25d88c35e1c1af155edf.camel@joachim-breitner.de>
 <CAGwnsnny_-PZED5y6RfDaLYwWP==NeK-zvoF3pEbyV1yy5yvBQ@mail.gmail.com>
 <010f0186c72d3aa5-5163b078-0956-46e8-9e41-c2d206f6273c-000000@us-east-2.amazonses.com>
 <882d3cac-00e6-7dfd-b32d-69968856b8ba@well-typed.com>
 <010f0186fbb4bf37-10d8c856-9c2e-47c0-9edf-e0af23097fbc-000000@us-east-2.amazonses.com>
 <CAJKmMz8sGnBRRqS=3GGfGe8SLHAx3gERo-5Wt2Jjm7f8YY-wHA@mail.gmail.com>
Message-ID: <D00B7DC9-62BF-4D21-A301-3C90741158D1@chrisdornan.com>

I am also in favour of extensions that focus on solving a single problem well and giving users precise control over what extensions they deploy. If we get this right then we should be able discover which extensions people want and those that are free of unintended consequences, and can put them on track to be included in a GHC and then Haskell standard.

This proposal isn't ambitious but it does otherwise appear to qualify so I am in favour.

Chris




> On 20 Mar 2023, at 08:43, Simon Peyton Jones <simon.peytonjones at gmail.com> wrote:
> 
> Personally I'm happy with having orthogonal extensions that enable just one thing.  That allows our users to do what they want, rather than telling them what they want.
> 
> On this particular proposal I don't think it's a big deal either way, but I'd vote in favour.  It's not exactly true to say that it duplicates an existing feature.  I think Richard's point is that you can get a warning for using an unticked constructor (but nothing for using a ticked one).  That's different from getting an error if you use a constructor in a type, ticked or not.
> 
> This particular proposal is easy to describe and easy to implement.  But I don't think we should burn a lot of cycles on it... it's a matter of taste, so we could just vote.
> 
> Simon
> 
> On Sun, 19 Mar 2023 at 21:09, Richard Eisenberg <lists at richarde.dev <mailto:lists at richarde.dev>> wrote:
>> This argument gave me pause. Thanks, Adam. I think, for me, it comes down to this: what do we think will be more useful to more of our users? A notion of a core language -- perhaps implemented by different compilers -- with extensions? Or a unified language GHC/Haskell which allows subsetting? I tend to think the latter, though I'm not sure.
>> 
>> Regarding this particular proposal: I remain against the proposal, as it duplicates an existing feature. That's a simple reason to be against a proposal.
>> 
>> Richard
>> 
>> > On Mar 10, 2023, at 9:15 AM, Adam Gundry <adam at well-typed.com <mailto:adam at well-typed.com>> wrote:
>> > 
>> > This proposal is very helpful in exposing some of the divisions about the interpretation of extensions that exist within the committee! "Let a thousand flowers bloom" vs "more-extensions-make-me-wince", if you like.
>> > 
>> > For what it's worth I tend to be in the former camp. I think we should strive for orthogonality and avoid bundling together distinct features merely because they have related effects. Instead we should construct our language via composition of simple components. And I think it's reasonable to say that TypeLevelLiterals and (the rest of) DataKinds are clearly distinct and can be understood in isolation.
>> > 
>> > If the number of extensions is a problem, that points to the need to better structure our documentation and gather coherent subsets of extensions into manageable pieces (much as GHC2021 tries to do). Beyond that I'd like to understand the downsides better (e.g. what costs does it actually impose on HLS to have another extension?).
>> > 
>> > A conversation with one of the authors of Helium this week made me think that in the GHC proposals process we have tended to neglect the possible presence of other Haskell implementations. It's not realistic to expect that anyone will reimplement the whole of GHC Haskell, but perhaps there is a fragment large enough to be useful for a fair number of Haskell programs but also small enough to be independently implemented (e.g. by Helium). It would strike me as plausible that such an implementation might want to support TypeData+TypeLevelLiterals but not DataKinds.
>> > 
>> > Adam
>> > 
>> > 
>> > On 09/03/2023 16:21, Richard Eisenberg wrote:
>> >> Though I see the arguments in the other direction, I vote against this proposal. As Joachim argues, adding an extension puts a tax on the entire ecosystem by adding one more bit of context a reader has to have to understand code. In addition, HLS will have to be aware of this extension. And the benefits seem pretty marginal here.
>> >> Can we instead simply provide a warning? The warning here would be something like the -Wpuns idea, in that it helps the author keep to a particular subset of the language. (We might want to collect such warnings somehow in our documentation.)
>> >> Actually, it occurs to me we already have the warning: -Wunticked-promoted-constructors. We've put that warning in the -Weverything bin (not even -Wall) because in the past we've decided that we shouldn't recommend/require the ' when using a constructor in a type. But actually, setting -Werror=unticked-promoted-constructors would seem to be a perfect substitute for -XTypeLevelLiterals -XNoDataKinds. OK, not perfect: you could still use a constructor in a type with a ' mark. But I think that's great, actually, because perhaps an author wary of constructors in types still might need to use one, in one place, in a 2,000-line file. This ticks all the boxes (ha ha).
>> >> Having discovered this replacement, I'm now pretty strongly against this proposal. I'll also post on GitHub.
>> >> Richard
>> >>> On Mar 9, 2023, at 4:26 AM, Arnaud Spiwack <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io> <mailto:arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>>> wrote:
>> >>> 
>> >>> I can see where the author is coming from. But as Joachim, I find myself unconvinced that it is worth yet one extra extension (but then again, I'm the more-extensions-make-me-wince member of this committee).
>> >>> 
>> >>> On Wed, 8 Mar 2023 at 13:56, Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de> <mailto:mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>>> wrote:
>> >>> 
>> >>>    Hi,
>> >>> 
>> >>>    Am Mittwoch, dem 08.03.2023 um 14:58 +0300 schrieb Vladislav Zavialov:
>> >>>    > DataKinds is indeed a "bad" extension because it introduces
>> >>>    ambiguity
>> >>>    > to name resolution.
>> >>>    >
>> >>>    > There are two ways to avoid this issue:
>> >>>    > 1. Keep namespaces separate and double down on using punned
>> >>>    > constructor names.
>> >>>    > 2. Merge terms and types, discouraging punned constructor names.
>> >>>    >
>> >>>    > Each approach could indeed lead to a "dialect" of sorts.
>> >>>    >
>> >>>    > * The (accepted and recently implemented) TypeData extension
>> >>>    moves us
>> >>>    > in the direction of option (1), and I imagine the proposed
>> >>>    > TypeLevelLiterals would be often used in conjunction with TypeData.
>> >>>    > This carves out a limited, conservative language subset for type-
>> >>>    > level programming.
>> >>>    > * At the same time, #270 "Support pun-free code" moves us in the
>> >>>    > direction of option (2), and I expect it to be the better option
>> >>>    when
>> >>>    > it comes to fully fledged dependently-typed programming
>> >>>    envisioned by
>> >>>    > #378.
>> >>>    >
>> >>>    > If I had to choose, I'd go with option (2). I don't see myself using
>> >>>    > TypeData, nor TypeLevelLiterals for that matter. But I am of a
>> >>>    "let a
>> >>>    > thousand flowers bloom" persuasion, hence my recommendation to
>> >>>    > accept.
>> >>> 
>> >>> 
>> >>>    Thanks for putting this into a clearer context.
>> >>> 
>> >>>    Where does DataKind fit in? Is it a natural part of approach (2)
>> >>>    (which
>> >>>    is the general direction outlined by #378), or is yet another take on
>> >>>    the issue?
>> >>>    If DataKinds was not what we want according to #378, but the fragment
>> >>>    carved out by TypeLevelLiterals was, then that would be a strong
>> >>>    reason
>> >>>    for me to acccept TypeLevelLiterals.
>> >>>    But if DataKinds is the goal (or at least “the” goal), then I
>> >>>    think I’d
>> >>>    like to see stronger arguments for why it should be split.
>> >>> 
>> >>> 
>> >>>    Cheers,
>> >>>    Joachim
>> >>> 
>> >>>    --     Joachim Breitner
>> >>>    mail at joachim-breitner.de <mailto:mail at joachim-breitner.de> <mailto:mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>>
>> >>>    http://www.joachim-breitner.de/ <http://www.joachim-breitner.de/>
>> > 
>> > -- 
>> > 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
>> > 
>> > _______________________________________________
>> > 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
>> 
>> _______________________________________________
>> 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
> _______________________________________________
> 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/20230320/95c0dff7/attachment.html>

From iavor.diatchki at gmail.com  Mon Mar 20 17:59:57 2023
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Mon, 20 Mar 2023 10:59:57 -0700
Subject: [ghc-steering-committee] #536: Type-level literals as a
 separate language extension, rec: accept
In-Reply-To: <D00B7DC9-62BF-4D21-A301-3C90741158D1@chrisdornan.com>
References: <CAHZ0NLoao=NF38m7uHHj4+trWMgcyN7gPZg3E+ET+zQTd-cK9g@mail.gmail.com>
 <b2a7f83a60faeb6478acbe28d9d94c57f90740d6.camel@joachim-breitner.de>
 <CAJKmMz_iF3KckSATgHetX8NL2rWqjAGTwP1j11xxBvu-9OoYaw@mail.gmail.com>
 <c07162d7324d6cba101bee0bce2e9e3fb97c3e23.camel@joachim-breitner.de>
 <CAHZ0NLpUf9JYmaGYfJzWtc41NWxtY7fLUJu395vme6e0nmmkgw@mail.gmail.com>
 <efc0baf49b2bc4451bec25d88c35e1c1af155edf.camel@joachim-breitner.de>
 <CAGwnsnny_-PZED5y6RfDaLYwWP==NeK-zvoF3pEbyV1yy5yvBQ@mail.gmail.com>
 <010f0186c72d3aa5-5163b078-0956-46e8-9e41-c2d206f6273c-000000@us-east-2.amazonses.com>
 <882d3cac-00e6-7dfd-b32d-69968856b8ba@well-typed.com>
 <010f0186fbb4bf37-10d8c856-9c2e-47c0-9edf-e0af23097fbc-000000@us-east-2.amazonses.com>
 <CAJKmMz8sGnBRRqS=3GGfGe8SLHAx3gERo-5Wt2Jjm7f8YY-wHA@mail.gmail.com>
 <D00B7DC9-62BF-4D21-A301-3C90741158D1@chrisdornan.com>
Message-ID: <CAGK9nuqb3jpL4P-AANDooxO+3_k-CC3mGG483tir+8duuC82FQ@mail.gmail.com>

Hello,

I am not on the committee but as the original author of the type literals
extensions I thought I'd give my 2c.  I am strongly in favor of separating
type literals from DataKinds, they are not really together for any deep
reason.

For me the separate extension would be useful because it makes it possible
to use type literals with the `TypeData` extension, which for me, is a much
nicer way to work with type level things than `DataKinds`.

-Iavor



On Mon, Mar 20, 2023 at 10:08 AM Chris Dornan <chris at chrisdornan.com> wrote:

> I am also in favour of extensions that focus on solving a single problem
> well and giving users precise control over what extensions they deploy. If
> we get this right then we should be able discover which extensions people
> want and those that are free of unintended consequences, and can put them
> on track to be included in a GHC and then Haskell standard.
>
> This proposal isn't ambitious but it does otherwise appear to qualify so I
> am in favour.
>
> Chris
>
>
>
>
> On 20 Mar 2023, at 08:43, Simon Peyton Jones <simon.peytonjones at gmail.com>
> wrote:
>
> Personally I'm happy with having orthogonal extensions that enable just
> one thing.  That allows our users to do what they want, rather than telling
> them what they want.
>
> On this particular proposal I don't think it's a big deal either way, but
> I'd vote in favour.  It's not exactly true to say that it duplicates an
> existing feature.  I think Richard's point is that you can get a warning
> for using an unticked constructor (but nothing for using a ticked one).
> That's different from getting an error if you use a constructor in a type,
> ticked or not.
>
> This particular proposal is easy to describe and easy to implement.  But I
> don't think we should burn a lot of cycles on it... it's a matter of taste,
> so we could just vote.
>
> Simon
>
> On Sun, 19 Mar 2023 at 21:09, Richard Eisenberg <lists at richarde.dev>
> wrote:
>
>> This argument gave me pause. Thanks, Adam. I think, for me, it comes down
>> to this: what do we think will be more useful to more of our users? A
>> notion of a core language -- perhaps implemented by different compilers --
>> with extensions? Or a unified language GHC/Haskell which allows subsetting?
>> I tend to think the latter, though I'm not sure.
>>
>> Regarding this particular proposal: I remain against the proposal, as it
>> duplicates an existing feature. That's a simple reason to be against a
>> proposal.
>>
>> Richard
>>
>> > On Mar 10, 2023, at 9:15 AM, Adam Gundry <adam at well-typed.com> wrote:
>> >
>> > This proposal is very helpful in exposing some of the divisions about
>> the interpretation of extensions that exist within the committee! "Let a
>> thousand flowers bloom" vs "more-extensions-make-me-wince", if you like.
>> >
>> > For what it's worth I tend to be in the former camp. I think we should
>> strive for orthogonality and avoid bundling together distinct features
>> merely because they have related effects. Instead we should construct our
>> language via composition of simple components. And I think it's reasonable
>> to say that TypeLevelLiterals and (the rest of) DataKinds are clearly
>> distinct and can be understood in isolation.
>> >
>> > If the number of extensions is a problem, that points to the need to
>> better structure our documentation and gather coherent subsets of
>> extensions into manageable pieces (much as GHC2021 tries to do). Beyond
>> that I'd like to understand the downsides better (e.g. what costs does it
>> actually impose on HLS to have another extension?).
>> >
>> > A conversation with one of the authors of Helium this week made me
>> think that in the GHC proposals process we have tended to neglect the
>> possible presence of other Haskell implementations. It's not realistic to
>> expect that anyone will reimplement the whole of GHC Haskell, but perhaps
>> there is a fragment large enough to be useful for a fair number of Haskell
>> programs but also small enough to be independently implemented (e.g. by
>> Helium). It would strike me as plausible that such an implementation might
>> want to support TypeData+TypeLevelLiterals but not DataKinds.
>> >
>> > Adam
>> >
>> >
>> > On 09/03/2023 16:21, Richard Eisenberg wrote:
>> >> Though I see the arguments in the other direction, I vote against this
>> proposal. As Joachim argues, adding an extension puts a tax on the entire
>> ecosystem by adding one more bit of context a reader has to have to
>> understand code. In addition, HLS will have to be aware of this extension.
>> And the benefits seem pretty marginal here.
>> >> Can we instead simply provide a warning? The warning here would be
>> something like the -Wpuns idea, in that it helps the author keep to a
>> particular subset of the language. (We might want to collect such warnings
>> somehow in our documentation.)
>> >> Actually, it occurs to me we already have the warning:
>> -Wunticked-promoted-constructors. We've put that warning in the
>> -Weverything bin (not even -Wall) because in the past we've decided that we
>> shouldn't recommend/require the ' when using a constructor in a type. But
>> actually, setting -Werror=unticked-promoted-constructors would seem to be a
>> perfect substitute for -XTypeLevelLiterals -XNoDataKinds. OK, not perfect:
>> you could still use a constructor in a type with a ' mark. But I think
>> that's great, actually, because perhaps an author wary of constructors in
>> types still might need to use one, in one place, in a 2,000-line file. This
>> ticks all the boxes (ha ha).
>> >> Having discovered this replacement, I'm now pretty strongly against
>> this proposal. I'll also post on GitHub.
>> >> Richard
>> >>> On Mar 9, 2023, at 4:26 AM, Arnaud Spiwack <arnaud.spiwack at tweag.io
>> <mailto:arnaud.spiwack at tweag.io>> wrote:
>> >>>
>> >>> I can see where the author is coming from. But as Joachim, I find
>> myself unconvinced that it is worth yet one extra extension (but then
>> again, I'm the more-extensions-make-me-wince member of this committee).
>> >>>
>> >>> On Wed, 8 Mar 2023 at 13:56, Joachim Breitner <
>> mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
>> >>>
>> >>>    Hi,
>> >>>
>> >>>    Am Mittwoch, dem 08.03.2023 um 14:58 +0300 schrieb Vladislav
>> Zavialov:
>> >>>    > DataKinds is indeed a "bad" extension because it introduces
>> >>>    ambiguity
>> >>>    > to name resolution.
>> >>>    >
>> >>>    > There are two ways to avoid this issue:
>> >>>    > 1. Keep namespaces separate and double down on using punned
>> >>>    > constructor names.
>> >>>    > 2. Merge terms and types, discouraging punned constructor names.
>> >>>    >
>> >>>    > Each approach could indeed lead to a "dialect" of sorts.
>> >>>    >
>> >>>    > * The (accepted and recently implemented) TypeData extension
>> >>>    moves us
>> >>>    > in the direction of option (1), and I imagine the proposed
>> >>>    > TypeLevelLiterals would be often used in conjunction with
>> TypeData.
>> >>>    > This carves out a limited, conservative language subset for type-
>> >>>    > level programming.
>> >>>    > * At the same time, #270 "Support pun-free code" moves us in the
>> >>>    > direction of option (2), and I expect it to be the better option
>> >>>    when
>> >>>    > it comes to fully fledged dependently-typed programming
>> >>>    envisioned by
>> >>>    > #378.
>> >>>    >
>> >>>    > If I had to choose, I'd go with option (2). I don't see myself
>> using
>> >>>    > TypeData, nor TypeLevelLiterals for that matter. But I am of a
>> >>>    "let a
>> >>>    > thousand flowers bloom" persuasion, hence my recommendation to
>> >>>    > accept.
>> >>>
>> >>>
>> >>>    Thanks for putting this into a clearer context.
>> >>>
>> >>>    Where does DataKind fit in? Is it a natural part of approach (2)
>> >>>    (which
>> >>>    is the general direction outlined by #378), or is yet another take
>> on
>> >>>    the issue?
>> >>>    If DataKinds was not what we want according to #378, but the
>> fragment
>> >>>    carved out by TypeLevelLiterals was, then that would be a strong
>> >>>    reason
>> >>>    for me to acccept TypeLevelLiterals.
>> >>>    But if DataKinds is the goal (or at least “the” goal), then I
>> >>>    think I’d
>> >>>    like to see stronger arguments for why it should be split.
>> >>>
>> >>>
>> >>>    Cheers,
>> >>>    Joachim
>> >>>
>> >>>    --     Joachim Breitner
>> >>>    mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>
>> >>>    http://www.joachim-breitner.de/ <http://www.joachim-breitner.de/>
>> >
>> > --
>> > 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
>> >
>> > _______________________________________________
>> > 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
>
>
> _______________________________________________
> 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/20230320/facb3612/attachment-0001.html>

From simon.peytonjones at gmail.com  Thu Mar 30 07:02:12 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Thu, 30 Mar 2023 08:02:12 +0100
Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?=
	=?utf-8?b?4oCTIFJvdW5kIDE=?=
In-Reply-To: <CAGwnsnn=rY=Xzwi23HjQ2zGSRAhtqAS8Xi8Em6M5oqfpG3aYWw@mail.gmail.com>
References: <CAGwnsnn=rY=Xzwi23HjQ2zGSRAhtqAS8Xi8Em6M5oqfpG3aYWw@mail.gmail.com>
Message-ID: <CAJKmMz_q7wAO-8D9jkA55OJJ9sbs_YwhZuLY-3J2Qn40=3vNOQ@mail.gmail.com>

Where are we on this thread, Arnaud?

Separately Richard has suggested
<https://github.com/ghc-proposals/ghc-proposals/pull/536#issuecomment-1475395448>
:

I think *all* extensions that just enable new syntax (without changing the
> meaning of any existing programs) should be warnings.
>

That seems like a possible principle, which could form part of this
discussion.

Simon

On Fri, 17 Feb 2023 at 14:07, Arnaud Spiwack <arnaud.spiwack at tweag.io>
wrote:

> Dear all,
>
> I am to shepherd the making of our language extension policy, working
> off our draft document
> [
> https://docs.google.com/document/d/1_-hPh8BRhKNlzM0dC1IRSmjCqPym9mXx9NjC7jUlpRQ/
> ].
> As a prelude to my introduction, I first want to apologise for taking
> that long to get back to this subject, time has, I'm afraid, gotten away
> from me. Part of the reason, though, is that we've been pulling in
> many directions, and I felt it difficult to find a path toward
> consensus among all that.
>
> In the time since I accepted the task, I have therefore spent a lot of
> time reading through the entire document multiple time, to try and
> identify the points where we agree and the points where we
> diverge. And try to build a methodology.
>
> If you go to the document, you'll see that I've separated out our
> notes after a horizontal line. I will grow the document above the line
> with decisions from this mailing list. Hopefully, the process will
> make sure that we are in broad agreement that the text does reflect
> our collective position.
>
> The way I'm going to proceed is to organise votes. Or maybe they
> should rather be seen as surveys. They'll have a bunch of questions,
> pertaining to bits of the documents that I want us to converge on. I'll
> extract a broad consensus from this survey, and use it to copy
> language in the document. I intend to give about a week for each
> survey to complete (conveniently, I'll be very far from a computer for
> the next week, so I'll be able to tally the results when I come
> back). It's going to take a while, but it's a very difficult, and
> sensitive, subject.
>
> ---
>
> For this first round, I want us to focus on the categorisation of
> language extensions as proposed by Richard and Simon M (sections 2.1
> and 2.3, respectively, of our draft notes). As I feel that we will
> need to have these categories identified in order to discuss the later
> points.
>
> Here are the categories that are common to both (consult the document
> for more details):
>
> 1. Extensions that are either in GHC20xx or could be part of a future
>    GHC20xx (e.g. GADTs)
> 2. Experimental language features (e.g. LinearTypes)
> 3. Extensions that allow module-wide violation of some general
>    principle that holds elsewhere (e.g. OverlappingInstances)
> 4. Extensions that allow access to deprecated features (e.g.
> DatatypeContexts)
> 5. Extensions that should be compiler flags, which do not actually
>    change the accepted language (e.g. Safe)
>
> Richard adds another category
>
> 6. Extensions that change the semantics of existing constructs
>    (e.g. OverloadedStrings); as opposed to most extensions, which
>    create new syntax for the new feature.
>
> Richard's reasoning is twofold 1/ he doesn't believe that they should
> be candidate for inclusion in GHC20xx 2/ he believes that they are
> problematic for the same sort of reason as we've used to argue against
> fork-like behaviour: that to understand the meaning of a piece of code
> you need to know what language extensions have been loaded in the
> file.
>
> Simon M adds another category
>
> 7. Extensions for specialised use-cases (e.g. MagicHash,
>    UnboxedTuples)
>
> Simon's reasoning is that these should not be part of GHC20xx. At the
> very least they are not intended to. But they do extend the language,
> like 1, and unlike 5. Hence they deserve to be categorised separately
> from both.
>
> It is worth noting that Richard classifies Strict as a 6 and Simon M
> classifies Strict as a 7.
>
> Now the survey.
>
> Keeping in mind that the goal of this categorisation is to classify
> the extensions that currently exist, without judgement on whether we
> want to have things in these categories or not:
>
> Q1: Are all the categories 1–5 relevant? If you would like to remove
>        some categories, which and why (free form)?
> Q2: Is category 6 relevant?
> Q2.Y: If you found category 6 to be relevant: should it be its own
>            category, or should it be a subcategory of 1?
> Q2.N: If you found category 6 not to be relevant, in which category
>             would you classify OverloadedStrings? What about PolyKinds?
> Q3: Is category 7 relevant?
> Q3.Y: If you found category 7 to be relevant: should it be its own
>            category or should it be a subcategory of 5?
> Q3.N: If you found category 7 not to be relevant: in which category
>            would you classify MagicHash? What about UnboxedTuples?
>  Q4: In which category would you classify Strict?
>  Q5: Is there any category that you feel is missing from the list? If
>        so, please argue (free form).
>
> Best,
> Arnaud
> _______________________________________________
> 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/20230330/cd97c050/attachment.html>

From arnaud.spiwack at tweag.io  Thu Mar 30 08:45:52 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Thu, 30 Mar 2023 10:45:52 +0200
Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?=
	=?utf-8?b?4oCTIFJvdW5kIDE=?=
In-Reply-To: <CAJKmMz_q7wAO-8D9jkA55OJJ9sbs_YwhZuLY-3J2Qn40=3vNOQ@mail.gmail.com>
References: <CAGwnsnn=rY=Xzwi23HjQ2zGSRAhtqAS8Xi8Em6M5oqfpG3aYWw@mail.gmail.com>
 <CAJKmMz_q7wAO-8D9jkA55OJJ9sbs_YwhZuLY-3J2Qn40=3vNOQ@mail.gmail.com>
Message-ID: <CAGwnsnnMkR2rNT9T+d_b0igy5-p0wHY5PVkzP5KmtZrYeKBZKg@mail.gmail.com>

Simon,

Quite funny that you're writing this now, as I'm finishing writing my next
email, after a pretty long unplanned absence (apologies about that).

Thanks for forwarding Richard's suggestion, which I hadn't seen.

/Arnaud

On Thu, 30 Mar 2023 at 09:00, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> Where are we on this thread, Arnaud?
>
> Separately Richard has suggested
> <https://github.com/ghc-proposals/ghc-proposals/pull/536#issuecomment-1475395448>
> :
>
> I think *all* extensions that just enable new syntax (without changing
>> the meaning of any existing programs) should be warnings.
>>
>
> That seems like a possible principle, which could form part of this
> discussion.
>
> Simon
>
> On Fri, 17 Feb 2023 at 14:07, Arnaud Spiwack <arnaud.spiwack at tweag.io>
> wrote:
>
>> Dear all,
>>
>> I am to shepherd the making of our language extension policy, working
>> off our draft document
>> [
>> https://docs.google.com/document/d/1_-hPh8BRhKNlzM0dC1IRSmjCqPym9mXx9NjC7jUlpRQ/
>> ].
>> As a prelude to my introduction, I first want to apologise for taking
>> that long to get back to this subject, time has, I'm afraid, gotten away
>> from me. Part of the reason, though, is that we've been pulling in
>> many directions, and I felt it difficult to find a path toward
>> consensus among all that.
>>
>> In the time since I accepted the task, I have therefore spent a lot of
>> time reading through the entire document multiple time, to try and
>> identify the points where we agree and the points where we
>> diverge. And try to build a methodology.
>>
>> If you go to the document, you'll see that I've separated out our
>> notes after a horizontal line. I will grow the document above the line
>> with decisions from this mailing list. Hopefully, the process will
>> make sure that we are in broad agreement that the text does reflect
>> our collective position.
>>
>> The way I'm going to proceed is to organise votes. Or maybe they
>> should rather be seen as surveys. They'll have a bunch of questions,
>> pertaining to bits of the documents that I want us to converge on. I'll
>> extract a broad consensus from this survey, and use it to copy
>> language in the document. I intend to give about a week for each
>> survey to complete (conveniently, I'll be very far from a computer for
>> the next week, so I'll be able to tally the results when I come
>> back). It's going to take a while, but it's a very difficult, and
>> sensitive, subject.
>>
>> ---
>>
>> For this first round, I want us to focus on the categorisation of
>> language extensions as proposed by Richard and Simon M (sections 2.1
>> and 2.3, respectively, of our draft notes). As I feel that we will
>> need to have these categories identified in order to discuss the later
>> points.
>>
>> Here are the categories that are common to both (consult the document
>> for more details):
>>
>> 1. Extensions that are either in GHC20xx or could be part of a future
>>    GHC20xx (e.g. GADTs)
>> 2. Experimental language features (e.g. LinearTypes)
>> 3. Extensions that allow module-wide violation of some general
>>    principle that holds elsewhere (e.g. OverlappingInstances)
>> 4. Extensions that allow access to deprecated features (e.g.
>> DatatypeContexts)
>> 5. Extensions that should be compiler flags, which do not actually
>>    change the accepted language (e.g. Safe)
>>
>> Richard adds another category
>>
>> 6. Extensions that change the semantics of existing constructs
>>    (e.g. OverloadedStrings); as opposed to most extensions, which
>>    create new syntax for the new feature.
>>
>> Richard's reasoning is twofold 1/ he doesn't believe that they should
>> be candidate for inclusion in GHC20xx 2/ he believes that they are
>> problematic for the same sort of reason as we've used to argue against
>> fork-like behaviour: that to understand the meaning of a piece of code
>> you need to know what language extensions have been loaded in the
>> file.
>>
>> Simon M adds another category
>>
>> 7. Extensions for specialised use-cases (e.g. MagicHash,
>>    UnboxedTuples)
>>
>> Simon's reasoning is that these should not be part of GHC20xx. At the
>> very least they are not intended to. But they do extend the language,
>> like 1, and unlike 5. Hence they deserve to be categorised separately
>> from both.
>>
>> It is worth noting that Richard classifies Strict as a 6 and Simon M
>> classifies Strict as a 7.
>>
>> Now the survey.
>>
>> Keeping in mind that the goal of this categorisation is to classify
>> the extensions that currently exist, without judgement on whether we
>> want to have things in these categories or not:
>>
>> Q1: Are all the categories 1–5 relevant? If you would like to remove
>>        some categories, which and why (free form)?
>> Q2: Is category 6 relevant?
>> Q2.Y: If you found category 6 to be relevant: should it be its own
>>            category, or should it be a subcategory of 1?
>> Q2.N: If you found category 6 not to be relevant, in which category
>>             would you classify OverloadedStrings? What about PolyKinds?
>> Q3: Is category 7 relevant?
>> Q3.Y: If you found category 7 to be relevant: should it be its own
>>            category or should it be a subcategory of 5?
>> Q3.N: If you found category 7 not to be relevant: in which category
>>            would you classify MagicHash? What about UnboxedTuples?
>>  Q4: In which category would you classify Strict?
>>  Q5: Is there any category that you feel is missing from the list? If
>>        so, please argue (free form).
>>
>> Best,
>> Arnaud
>> _______________________________________________
>> 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/20230330/40aedd9b/attachment-0001.html>

From mail at joachim-breitner.de  Thu Mar 30 08:54:18 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 30 Mar 2023 10:54:18 +0200
Subject: [ghc-steering-committee] Please review #579: Backward compat
 proposal section, Shepherd: Simon PJ
Message-ID: <2267dc569fc36e121a5372fae16f23089f4c68cd.camel@joachim-breitner.de>

Dear Committee,

Adam proposes adding a section on backward compatibility to the
proposal template:

https://github.com/ghc-proposals/ghc-proposals/pull/579

Richard said that this, even although likely uncontroverisal, should
have broad committee visibility, so I’m assigning this to Simon PJ (as
the chair) to shepherd this.

Please guide us to a conclusion as outlined in 
https://github.com/ghc-proposals/ghc-proposals#committee-process


Cheers,
Joachim





-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/


From simon.peytonjones at gmail.com  Thu Mar 30 08:59:41 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Thu, 30 Mar 2023 09:59:41 +0100
Subject: [ghc-steering-committee] Please review #579: Backward compat
 proposal section, Shepherd: Simon PJ
In-Reply-To: <2267dc569fc36e121a5372fae16f23089f4c68cd.camel@joachim-breitner.de>
References: <2267dc569fc36e121a5372fae16f23089f4c68cd.camel@joachim-breitner.de>
Message-ID: <CAJKmMz_Ey3_iNEoBnkO+cjhNn8AUaAJ9reP=dKaLQ456NCdVvQ@mail.gmail.com>

Dear Steering Commitee

Please review https://github.com/ghc-proposals/ghc-proposals/pull/579

I propose acceptance.  On this one I'll take silence as assent.

Please reply by Tuesday 4 April

Simon

On Thu, 30 Mar 2023 at 09:54, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Dear Committee,
>
> Adam proposes adding a section on backward compatibility to the
> proposal template:
>
> https://github.com/ghc-proposals/ghc-proposals/pull/579
>
> Richard said that this, even although likely uncontroverisal, should
> have broad committee visibility, so I’m assigning this to Simon PJ (as
> the chair) to shepherd this.
>
> Please guide us to a conclusion as outlined in
> https://github.com/ghc-proposals/ghc-proposals#committee-process
>
>
> Cheers,
> Joachim
>
>
>
>
>
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230330/fa8b2c96/attachment.html>

From arnaud.spiwack at tweag.io  Thu Mar 30 09:03:18 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Thu, 30 Mar 2023 11:03:18 +0200
Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?=
	=?utf-8?b?4oCTIFJvdW5kIDEn?=
Message-ID: <CAGwnsnmHG5mTn9w6-ab-5ZynA1d=k_3vge7t2Dfo1b3LuripMA@mail.gmail.com>

Dear all,

Sorry for the long silence. I was named and shamed by Joachim the
other day, which is fair enough. I've basically disappeared from my
email for a while. I am aware that not having solved this is holding
us back, I'll be more consistent in the future.

As I said in my last email, I'd like to start the conversation again
from the point of view of use-cases, as proposed by Adam, and see if
it helps us go forward. What I want to do, today, is to describe what
Haskell programmers have been using extension for. This is meant to be
purely a description, without judgement on whether the proposed
use-cases are good ideas. When the use-cases are listed, we'll turn to
which we want to support and how.

Without further ado, here is a list of use-cases, based on Adam's list
(my rephrasing), with additions by me. Haskell programmers use
extensions to:

1. Gain early access to experimental or unstable features
   (e.g. because they're working on a research prototype, or because
   the feature is valuable enough to them to forgo some stability)
2. Restrict the use of more complex features (e.g. for easier
   onboarding of new developers or as educators to teach a
   well-delimited subset of the language)
3. As library authors, to signal which features the library actually
   uses, hence which version of GHC the library is compatible with.
4. Retain access to deprecated features to smooth out migration over
   the deprecation period.
5. Retain access to deprecated features indefinitely.
6. Change the default behaviour of (part of) the language
   (e.g. StrictData, I think some of the dependent Haskell work falls
   in this category, but I can't pinpoint an example)
7. Extend the language in a way that is not backward compatible
   (e.g. OverloadedList, probably some dependent Haskell things too)
8. Enable features whose mere presence has a performance impact
   (e.g. Template Haskell, and that's probably it)
9. CPP (this one is very unique isn't it?)


(Note: Adam proposed some use-cases which are not included here: using
extension to ensure stability (which is the contrapositive of 1), and
as a GHC dev, make features available to early adopters (which is the
dual of 1). I didn't include them because I consider that they are
contained in 1, but if you disagree, please argue otherwise)

Questions:
1. Have we missed some use-cases, if so describe? (I'm sure we have,
   so I'd be surprised if nothing turns up here)
2. Do you think some of the use-cases above should be split into
   several use-cases?
3. Conversely, are there distinctions that don't make sense to you and
   you would argue should be merged?

Before answering, take note that while some of the proposed use-cases
can be seen as a list of extensions that behave a certain way, some
extensions may be used in several use-cases (4 and 5, by definition
concern the same set of extensions), some use-cases (like 3) are
independent of the behaviour of extensions. This is not a
classification of extension, but of how they are consumed.

I'll tally the result on Tuesday 10th April.

Best,
Arnaud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230330/5c1b3313/attachment.html>

From arnaud.spiwack at tweag.io  Thu Mar 30 09:13:39 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Thu, 30 Mar 2023 11:13:39 +0200
Subject: [ghc-steering-committee] Please review #579: Backward compat
 proposal section, Shepherd: Simon PJ
In-Reply-To: <CAJKmMz_Ey3_iNEoBnkO+cjhNn8AUaAJ9reP=dKaLQ456NCdVvQ@mail.gmail.com>
References: <2267dc569fc36e121a5372fae16f23089f4c68cd.camel@joachim-breitner.de>
 <CAJKmMz_Ey3_iNEoBnkO+cjhNn8AUaAJ9reP=dKaLQ456NCdVvQ@mail.gmail.com>
Message-ID: <CAGwnsn=xS39=8X+mmvyi=AvzS2e3mT9OnQ9VRdQnvjPn0htzbQ@mail.gmail.com>

Asked for a few questions to be answered on Github. Other than that, this
sounds absolutely a positive change to me.

On Thu, 30 Mar 2023 at 10:58, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> Dear Steering Commitee
>
> Please review https://github.com/ghc-proposals/ghc-proposals/pull/579
>
> I propose acceptance.  On this one I'll take silence as assent.
>
> Please reply by Tuesday 4 April
>
> Simon
>
> On Thu, 30 Mar 2023 at 09:54, Joachim Breitner <mail at joachim-breitner.de>
> wrote:
>
>> Dear Committee,
>>
>> Adam proposes adding a section on backward compatibility to the
>> proposal template:
>>
>> https://github.com/ghc-proposals/ghc-proposals/pull/579
>>
>> Richard said that this, even although likely uncontroverisal, should
>> have broad committee visibility, so I’m assigning this to Simon PJ (as
>> the chair) to shepherd this.
>>
>> Please guide us to a conclusion as outlined in
>> https://github.com/ghc-proposals/ghc-proposals#committee-process
>>
>>
>> Cheers,
>> Joachim
>>
>>
>>
>>
>>
>> --
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230330/0905ae7f/attachment-0001.html>

From simon.peytonjones at gmail.com  Thu Mar 30 09:33:09 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Thu, 30 Mar 2023 10:33:09 +0100
Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?=
	=?utf-8?b?4oCTIFJvdW5kIDEn?=
In-Reply-To: <CAGwnsnmHG5mTn9w6-ab-5ZynA1d=k_3vge7t2Dfo1b3LuripMA@mail.gmail.com>
References: <CAGwnsnmHG5mTn9w6-ab-5ZynA1d=k_3vge7t2Dfo1b3LuripMA@mail.gmail.com>
Message-ID: <CAJKmMz97C0hrCtBg01LvvOGYpMAGXyh_bDcDnzpAbQBHe7V_Cg@mail.gmail.com>

Thanks Arnaud.  I'm not sure of the use to which you plan to put this list
- but it seems like a reasonable starting point.

S

On Thu, 30 Mar 2023 at 10:04, Arnaud Spiwack <arnaud.spiwack at tweag.io>
wrote:

> Dear all,
>
> Sorry for the long silence. I was named and shamed by Joachim the
> other day, which is fair enough. I've basically disappeared from my
> email for a while. I am aware that not having solved this is holding
> us back, I'll be more consistent in the future.
>
> As I said in my last email, I'd like to start the conversation again
> from the point of view of use-cases, as proposed by Adam, and see if
> it helps us go forward. What I want to do, today, is to describe what
> Haskell programmers have been using extension for. This is meant to be
> purely a description, without judgement on whether the proposed
> use-cases are good ideas. When the use-cases are listed, we'll turn to
> which we want to support and how.
>
> Without further ado, here is a list of use-cases, based on Adam's list
> (my rephrasing), with additions by me. Haskell programmers use
> extensions to:
>
> 1. Gain early access to experimental or unstable features
>    (e.g. because they're working on a research prototype, or because
>    the feature is valuable enough to them to forgo some stability)
> 2. Restrict the use of more complex features (e.g. for easier
>    onboarding of new developers or as educators to teach a
>    well-delimited subset of the language)
> 3. As library authors, to signal which features the library actually
>    uses, hence which version of GHC the library is compatible with.
> 4. Retain access to deprecated features to smooth out migration over
>    the deprecation period.
> 5. Retain access to deprecated features indefinitely.
> 6. Change the default behaviour of (part of) the language
>    (e.g. StrictData, I think some of the dependent Haskell work falls
>    in this category, but I can't pinpoint an example)
> 7. Extend the language in a way that is not backward compatible
>    (e.g. OverloadedList, probably some dependent Haskell things too)
> 8. Enable features whose mere presence has a performance impact
>    (e.g. Template Haskell, and that's probably it)
> 9. CPP (this one is very unique isn't it?)
>
>
> (Note: Adam proposed some use-cases which are not included here: using
> extension to ensure stability (which is the contrapositive of 1), and
> as a GHC dev, make features available to early adopters (which is the
> dual of 1). I didn't include them because I consider that they are
> contained in 1, but if you disagree, please argue otherwise)
>
> Questions:
> 1. Have we missed some use-cases, if so describe? (I'm sure we have,
>    so I'd be surprised if nothing turns up here)
> 2. Do you think some of the use-cases above should be split into
>    several use-cases?
> 3. Conversely, are there distinctions that don't make sense to you and
>    you would argue should be merged?
>
> Before answering, take note that while some of the proposed use-cases
> can be seen as a list of extensions that behave a certain way, some
> extensions may be used in several use-cases (4 and 5, by definition
> concern the same set of extensions), some use-cases (like 3) are
> independent of the behaviour of extensions. This is not a
> classification of extension, but of how they are consumed.
>
> I'll tally the result on Tuesday 10th April.
>
> Best,
> Arnaud
> _______________________________________________
> 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/20230330/b23609fd/attachment.html>