From arnaud.spiwack at tweag.io  Tue Jun  6 07:44:55 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Tue, 6 Jun 2023 09:44:55 +0200
Subject: [ghc-steering-committee] Please consider GHC Proposal #575 for
	acceptance.
In-Reply-To: <CAJKmMz9SNedZPc+9S+0HOgfunHDx2tsNQFnNhHwy9j7eic+b7g@mail.gmail.com>
References: <CAKfdd-wVEKB2wuuym4OHax+S6Y8J4Zo5hN1k9Ai-uf4Wyg1+9Q@mail.gmail.com>
 <CAJKmMz9SNedZPc+9S+0HOgfunHDx2tsNQFnNhHwy9j7eic+b7g@mail.gmail.com>
Message-ID: <CAGwnsnkEeNkTEOWydU2rCtTRFu3F5=7_6zNqOVLiZb9ZpSdVPA@mail.gmail.com>

I support acceptance as well.

Eric's concern is a good point, but it probably shouldn't be an obstacle to
acceptance as 1/ the current proposal is still a clear improvement on the
situation 2/ it's unlikely that there is a cost-effective way to improve on
this axis.

Adam complains about semantics in the Github thread [1]. Probably something
worth improving before merging.

[1]:
https://github.com/ghc-proposals/ghc-proposals/pull/575#discussion_r1213653866

On Wed, 24 May 2023 at 11:10, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> I support acceptance, but I have asked a question about syntax.
>
> Simon
>
> On Fri, 19 May 2023 at 10:05, Moritz Angermann <moritz.angermann at gmail.com>
> wrote:
>
>> Dear Steering Committee,
>>
>> I strongly endorse GHC Proposal #575
>> <https://github.com/ghc-proposals/ghc-proposals/pull/575>, which
>> suggests the introduction of deprecation pragmas on instances.
>>
>> The proposal is a logical extension of Haskell's existing deprecation
>> facilities. Its implementation would fill a notable gap in the language's
>> current deprecation capabilities.
>>
>> The lack of instance deprecation hinders controlled evolution of
>> libraries and codebases, often leading to unexpected changes for users. By
>> allowing instance deprecation, we can enhance the stability and
>> predictability of Haskell codebases and improve the user experience.
>>
>> In summary, Proposal #575 represents a valuable improvement for Haskell.
>> I urge the committee to give it favorable consideration.
>>
>> Best Regards, Moritz
>> _______________________________________________
>> 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
>


-- 
Arnaud Spiwack
Director, Research at https://moduscreate.com and https://tweag.io.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230606/0a413fe7/attachment.html>

From arnaud.spiwack at tweag.io  Tue Jun  6 07:55:59 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Tue, 6 Jun 2023 09:55:59 +0200
Subject: [ghc-steering-committee] Please review #579: Backward compat
 proposal section, Shepherd: Simon PJ
In-Reply-To: <09af40599bbd9eb23282ed646edf4dd390cef83a.camel@joachim-breitner.de>
References: <2267dc569fc36e121a5372fae16f23089f4c68cd.camel@joachim-breitner.de>
 <CAJKmMz_Ey3_iNEoBnkO+cjhNn8AUaAJ9reP=dKaLQ456NCdVvQ@mail.gmail.com>
 <CAGwnsn=xS39=8X+mmvyi=AvzS2e3mT9OnQ9VRdQnvjPn0htzbQ@mail.gmail.com>
 <547e8c6550a39c6e33ca433c0d9b91f7a2bc6e41.camel@joachim-breitner.de>
 <CAJKmMz-thui2oPBOoC_-aFohPhsaw8J_tW9OoaFVO0D7oQEE9g@mail.gmail.com>
 <CAJKmMz-6Gzdf_b3AbG4RqmnRccJzUzDBTEWTv0hZOWqojvW0Wg@mail.gmail.com>
 <09af40599bbd9eb23282ed646edf4dd390cef83a.camel@joachim-breitner.de>
Message-ID: <CAGwnsnnTtqL_c+3gPYGTfDDjasFH+vft3P1D3kj9frk43HCLMA@mail.gmail.com>

Argl, sorry, I had missed these emails.

My questions haven't been resolved in that the document didn't change to
reflect the position. I suppose that the onus is doubly on me to make
things better here as it partly depends on the Extension policy.

On Wed, 24 May 2023 at 11:14, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> Am Mittwoch, dem 24.05.2023 um 09:25 +0100 schrieb Simon Peyton Jones:
> > Let's declare it accepted.  Joachim please merge.
>
> done.
>
> 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
>


-- 
Arnaud Spiwack
Director, Research at https://moduscreate.com and https://tweag.io.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230606/8fd492ab/attachment.html>

From eric at seidel.io  Wed Jun  7 20:58:32 2023
From: eric at seidel.io (Eric Seidel)
Date: Wed, 07 Jun 2023 16:58:32 -0400
Subject: [ghc-steering-committee] Please consider GHC Proposal #575
	foracceptance.
In-Reply-To: <CAGwnsnkEeNkTEOWydU2rCtTRFu3F5=7_6zNqOVLiZb9ZpSdVPA@mail.gmail.com>
References: <CAKfdd-wVEKB2wuuym4OHax+S6Y8J4Zo5hN1k9Ai-uf4Wyg1+9Q@mail.gmail.com>
 <CAJKmMz9SNedZPc+9S+0HOgfunHDx2tsNQFnNhHwy9j7eic+b7g@mail.gmail.com>
 <CAGwnsnkEeNkTEOWydU2rCtTRFu3F5=7_6zNqOVLiZb9ZpSdVPA@mail.gmail.com>
Message-ID: <49adb594-dcaf-4a45-bfdc-0aa9eb686b1f@app.fastmail.com>

Yes, to be clear I don't my concern as something to block on, it's a watch-out-for for library authors.

On Tue, Jun 6, 2023, at 03:44, Arnaud Spiwack wrote:
> I support acceptance as well.
>
> Eric's concern is a good point, but it probably shouldn't be an 
> obstacle to acceptance as 1/ the current proposal is still a clear 
> improvement on the situation 2/ it's unlikely that there is a 
> cost-effective way to improve on this axis.
>
> Adam complains about semantics in the Github thread [1]. Probably 
> something worth improving before merging.
>
> [1]: 
> https://github.com/ghc-proposals/ghc-proposals/pull/575#discussion_r1213653866
>
> On Wed, 24 May 2023 at 11:10, Simon Peyton Jones 
> <simon.peytonjones at gmail.com> wrote:
>> I support acceptance, but I have asked a question about syntax.
>> 
>> Simon
>> 
>> On Fri, 19 May 2023 at 10:05, Moritz Angermann <moritz.angermann at gmail.com> wrote:
>>> Dear Steering Committee,
>>> 
>>> I strongly endorse GHC Proposal #575 <https://github.com/ghc-proposals/ghc-proposals/pull/575>, which suggests the introduction of deprecation pragmas on instances.
>>> 
>>> The proposal is a logical extension of Haskell's existing deprecation facilities. Its implementation would fill a notable gap in the language's current deprecation capabilities.
>>> 
>>> The lack of instance deprecation hinders controlled evolution of libraries and codebases, often leading to unexpected changes for users. By allowing instance deprecation, we can enhance the stability and predictability of Haskell codebases and improve the user experience.
>>> 
>>> In summary, Proposal #575 represents a valuable improvement for Haskell. I urge the committee to give it favorable consideration.
>>> 
>>> Best Regards, Moritz
>>> 
>>> _______________________________________________
>>> 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
>
>
> -- 
> Arnaud Spiwack
> Director, Research at https://moduscreate.com and https://tweag.io.
> _______________________________________________
> 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  Thu Jun 15 09:03:57 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Thu, 15 Jun 2023 10:03:57 +0100
Subject: [ghc-steering-committee] Base library organisation
Message-ID: <CAJKmMz-VCBsWarL-uDhS=vfNPOKecdnHfbxPTmwM9zP1cKYW1Q@mail.gmail.com>

Dear GHC Steering Committee

Over the last few weeks, Ben Gamari and I have been discussing with Andrew
and Julian from the Core Libraries Committee how to make the Core Libraries
Committee and the GHC developers work together more fluidly; and that
includes the GHC Steering Committee.

We now have a fairly well fleshed out proposal here.
<https://github.com/Ericson2314/tech-proposals/blob/ghc-base-libraries/proposals/accepted/050-ghc-base-libraries.rst>

I hope you like it.  As far as this committee is concerned there are two
particular points of note

   1. We propose a new package, *ghc-experimental*, which depends on *base*.
   Many GHC proposals involve defining new types and functions.  The idea is
   that these would initially be in *ghc-experimental*.  After they
   stabilise and become widely adopted, the author (or anyone else) can make a
   CLC proposal to move them to *base*, which has much stronger stability
   guarantees.
   2. Section 5.1 suggests a mechanism to involve CLC members in proposals
   that involve new functions and types, at an earlier stage.  Some
involve *changing
   *existing types and functions.  It is clearly unproductive for us to
   debate such things at length, and only *then *to land it on the CLC.

   Section 5.1 also suggests that proposals should explicitly (in a
   separate section) call out


   - What new types and functions it defines
   - What existing types and functions are changed.

We should add that to our template.

At the moment we are just sharing the proposal with relevant stakeholders
(yourselves, CLC, stack folk, cabal folk etc), so that we can polish any
rough edges before making it public.

So, any views?  Personally I think this is a Big Step Forward.

Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230615/0c9aaf91/attachment.html>

From chris at chrisdornan.com  Thu Jun 15 15:50:48 2023
From: chris at chrisdornan.com (Chris Dornan)
Date: Thu, 15 Jun 2023 16:50:48 +0100
Subject: [ghc-steering-committee] Split -Wunused-imports (recommend accept)
Message-ID: <E064DD1C-69A1-41F9-B56D-BB30ADC35E0B@chrisdornan.com>

Dear Committee,

Georgi Lyubenov has a simple proposal to improve the quality of life for many package maintainers that I recommend that we accept.

## Split -Wunused-imports

Rendered proposal: <https://github.com/googleson78/ghc-proposals/blob/split-unused-imports/proposals/0000-split-wunused-imports.md>
Discussion of proposal: <https://github.com/ghc-proposals/ghc-proposals/pull/586>

### Summary

(Straight from the proposal.)

We propose to split the -Wunused-imports warning into two parts:

- warn on actual unused imports
- warn on duplicate imports

while also not including the second in -Wall. This will greatly reduce "churn" for library authors.


## In more Detail

As we know, many Haskell developers, including significant commercial projects, incorporate -Wall
-Werror into their workflow at some stage. To this end it is important that we minimise 'false
negatives', whereby the compiler emits 'frivolous' warnings.

This proposal identifies an important class of -Wall warnings that many package maintainers
appear to regard quite bothersome, namely when the compiler warns that import statement is 
superflous even when it is importing an entity that is being used by the module. The issue is
the way `-Wunused-imports` works, which will issue a warning for the following program.

```haskell
import X -- exports some function @f@
import y -- exports the same function @f@

g = f
```

The compiler will warn that the second Y import is redundant.

Many developers do not want to be warned about this. As far as they are concerned each import is
yielding enties that are in use and the fact that one of them can be removed is just not 
interesting.

In contrast, developers that use -Wall do want to be warned about the following.

```haskell
import X -- exports some function @f@
import Z -- does not export f

g = f
```

Here our module has a completely false dependency on Z which should be cleaned up at the point that
warnings are cleaned up.

This proposal proposes modifying -Wunused-imports so that it will warn about the second example but
stay silent for the first, and adds a -Wduplicate-imports that will issue a warning for the the
first example. In effect the enabling of both warnings in the new proposal will restore the current
-Wunused-imports behaviour. -Wall should *not* enable -Wduplicate-imports but is avilable to those
developers that rely on the current behaviour of -Wunused-imports (which some clearly do).


## Recommendation

I recommend that we accept this proposal.


From simon.peytonjones at gmail.com  Thu Jun 15 16:12:28 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Thu, 15 Jun 2023 17:12:28 +0100
Subject: [ghc-steering-committee] Split -Wunused-imports (recommend
	accept)
In-Reply-To: <E064DD1C-69A1-41F9-B56D-BB30ADC35E0B@chrisdornan.com>
References: <E064DD1C-69A1-41F9-B56D-BB30ADC35E0B@chrisdornan.com>
Message-ID: <CAJKmMz9jXR3wXyPjxogRJxUrAWxKcdi+uc3yiuVoepz0i8WNiA@mail.gmail.com>

I'm good with accepting this.

Simon

On Thu, 15 Jun 2023 at 16:51, Chris Dornan <chris at chrisdornan.com> wrote:

> Dear Committee,
>
> Georgi Lyubenov has a simple proposal to improve the quality of life for
> many package maintainers that I recommend that we accept.
>
> ## Split -Wunused-imports
>
> Rendered proposal: <
> https://github.com/googleson78/ghc-proposals/blob/split-unused-imports/proposals/0000-split-wunused-imports.md
> >
> Discussion of proposal: <
> https://github.com/ghc-proposals/ghc-proposals/pull/586>
>
> ### Summary
>
> (Straight from the proposal.)
>
> We propose to split the -Wunused-imports warning into two parts:
>
> - warn on actual unused imports
> - warn on duplicate imports
>
> while also not including the second in -Wall. This will greatly reduce
> "churn" for library authors.
>
>
> ## In more Detail
>
> As we know, many Haskell developers, including significant commercial
> projects, incorporate -Wall
> -Werror into their workflow at some stage. To this end it is important
> that we minimise 'false
> negatives', whereby the compiler emits 'frivolous' warnings.
>
> This proposal identifies an important class of -Wall warnings that many
> package maintainers
> appear to regard quite bothersome, namely when the compiler warns that
> import statement is
> superflous even when it is importing an entity that is being used by the
> module. The issue is
> the way `-Wunused-imports` works, which will issue a warning for the
> following program.
>
> ```haskell
> import X -- exports some function @f@
> import y -- exports the same function @f@
>
> g = f
> ```
>
> The compiler will warn that the second Y import is redundant.
>
> Many developers do not want to be warned about this. As far as they are
> concerned each import is
> yielding enties that are in use and the fact that one of them can be
> removed is just not
> interesting.
>
> In contrast, developers that use -Wall do want to be warned about the
> following.
>
> ```haskell
> import X -- exports some function @f@
> import Z -- does not export f
>
> g = f
> ```
>
> Here our module has a completely false dependency on Z which should be
> cleaned up at the point that
> warnings are cleaned up.
>
> This proposal proposes modifying -Wunused-imports so that it will warn
> about the second example but
> stay silent for the first, and adds a -Wduplicate-imports that will issue
> a warning for the the
> first example. In effect the enabling of both warnings in the new proposal
> will restore the current
> -Wunused-imports behaviour. -Wall should *not* enable -Wduplicate-imports
> but is avilable to those
> developers that rely on the current behaviour of -Wunused-imports (which
> some clearly do).
>
>
> ## Recommendation
>
> I recommend that we accept this proposal.
>
> _______________________________________________
> 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/20230615/caa0601d/attachment.html>

From mail at joachim-breitner.de  Fri Jun 16 12:33:28 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 16 Jun 2023 14:33:28 +0200
Subject: [ghc-steering-committee] Split -Wunused-imports (recommend
 accept)
In-Reply-To: <E064DD1C-69A1-41F9-B56D-BB30ADC35E0B@chrisdornan.com>
References: <E064DD1C-69A1-41F9-B56D-BB30ADC35E0B@chrisdornan.com>
Message-ID: <b71417a6426514e3704d88f75d78d28344acd2c8.camel@joachim-breitner.de>

Hi,

this proposal highlights a fundamental tension with compiler warnings.

If you assume a never changing background of dependencies, then the
current behavior isn’t too bad: GHC correctly tell you that you can
remove a line of code, and that is a good thing. I don’t think that
this is directly what is bothering developers.

But dependencies do change, and exports get moved around, and code that
wasn’t warning before suddenly warns. And that is what’s annoying!

So there is a tension between “given the current assumptions, your code
can be improved” vs. “assumptions change”.

I agree that at least in this case (and probably in general) we want
the -Wall warnings to be reasonably insensitive to dependency changes,
so that good code stays “good”. Of course this is not a hard rule –
think of deprecation warnings, but a decent guideline.

Therefore in favor.


The proposal mentions as alternative “Relaxed redundant imports”, which
refines the warnings a bit more. In that alternative, an _duplicate
explicit import_ is cause for a warning; in Chris’ example that would
be

   import X (f) -- exports some function @f@
   import y (f) -- exports the same function @f@
   g = f

Under the current proposal, this would no longer warn with -Wall, but I
think it’s silly to not warn here, as even with changing dependencies,
this is a code smell. I sympathize with the author’s wish to not make
this more complicated than necessary to achieve the goal (warnings
about duplicate _implicit_ imports causing headcaches), but would like
to keep the door open for someone who wants to implement the refined
version in the future. That would probably entail a
  -Wduplicate-explicit-import
flag which can then live in -Wall, but is still compatible with this
proposal, so all izz well.



Adam points out (as quoted in the proposal) that users of
   -Weverything -Wno-unused-imports
might see new breakage. I don’t think someone using -Weverything can
expect any kind of stability, else we paint ourselves into a corner (or
start introducing -Wreally-everything, -Wreally-really-everything, …)


Cheers,
Joachim




Am Donnerstag, dem 15.06.2023 um 16:50 +0100 schrieb Chris Dornan:
> Dear Committee,
> 
> Georgi Lyubenov has a simple proposal to improve the quality of life for many package maintainers that I recommend that we accept.
> 
> ## Split -Wunused-imports
> 
> Rendered proposal: <https://github.com/googleson78/ghc-proposals/blob/split-unused-imports/proposals/0000-split-wunused-imports.md>
> Discussion of proposal: <https://github.com/ghc-proposals/ghc-proposals/pull/586>
> 
> ### Summary
> 
> (Straight from the proposal.)
> 
> We propose to split the -Wunused-imports warning into two parts:
> 
> - warn on actual unused imports
> - warn on duplicate imports
> 
> while also not including the second in -Wall. This will greatly reduce "churn" for library authors.
> 
> 
> ## In more Detail
> 
> As we know, many Haskell developers, including significant commercial projects, incorporate -Wall
> -Werror into their workflow at some stage. To this end it is important that we minimise 'false
> negatives', whereby the compiler emits 'frivolous' warnings.
> 
> This proposal identifies an important class of -Wall warnings that many package maintainers
> appear to regard quite bothersome, namely when the compiler warns that import statement is 
> superflous even when it is importing an entity that is being used by the module. The issue is
> the way `-Wunused-imports` works, which will issue a warning for the following program.
> 
> ```haskell
> import X -- exports some function @f@
> import y -- exports the same function @f@
> 
> g = f
> ```
> 
> The compiler will warn that the second Y import is redundant.
> 
> Many developers do not want to be warned about this. As far as they are concerned each import is
> yielding enties that are in use and the fact that one of them can be removed is just not 
> interesting.
> 
> In contrast, developers that use -Wall do want to be warned about the following.
> 
> ```haskell
> import X -- exports some function @f@
> import Z -- does not export f
> 
> g = f
> ```
> 
> Here our module has a completely false dependency on Z which should be cleaned up at the point that
> warnings are cleaned up.
> 
> This proposal proposes modifying -Wunused-imports so that it will warn about the second example but
> stay silent for the first, and adds a -Wduplicate-imports that will issue a warning for the the
> first example. In effect the enabling of both warnings in the new proposal will restore the current
> -Wunused-imports behaviour. -Wall should *not* enable -Wduplicate-imports but is avilable to those
> developers that rely on the current behaviour of -Wunused-imports (which some clearly do).
> 
> 
> ## Recommendation
> 
> I recommend that we accept this proposal.
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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


From chris at chrisdornan.com  Fri Jun 16 14:05:10 2023
From: chris at chrisdornan.com (Chris Dornan)
Date: Fri, 16 Jun 2023 15:05:10 +0100
Subject: [ghc-steering-committee] Split -Wunused-imports (recommend
 accept)
In-Reply-To: <b71417a6426514e3704d88f75d78d28344acd2c8.camel@joachim-breitner.de>
References: <E064DD1C-69A1-41F9-B56D-BB30ADC35E0B@chrisdornan.com>
 <b71417a6426514e3704d88f75d78d28344acd2c8.camel@joachim-breitner.de>
Message-ID: <6AC42B82-A845-41CA-A59A-51158464A576@chrisdornan.com>

Just for the record, I am also open to refinement of the import-warning toolbox in future but I think this proposal is the best next step.

Given how straightforward the proposition is, how about we set a week for objections to be raised and move to accept the proposal if none are forthcoming (by Saturday, 2023-06-24).

Chris

> On 16 Jun 2023, at 13:33, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> Hi,
> 
> this proposal highlights a fundamental tension with compiler warnings.
> 
> If you assume a never changing background of dependencies, then the
> current behavior isn’t too bad: GHC correctly tell you that you can
> remove a line of code, and that is a good thing. I don’t think that
> this is directly what is bothering developers.
> 
> But dependencies do change, and exports get moved around, and code that
> wasn’t warning before suddenly warns. And that is what’s annoying!
> 
> So there is a tension between “given the current assumptions, your code
> can be improved” vs. “assumptions change”.
> 
> I agree that at least in this case (and probably in general) we want
> the -Wall warnings to be reasonably insensitive to dependency changes,
> so that good code stays “good”. Of course this is not a hard rule –
> think of deprecation warnings, but a decent guideline.
> 
> Therefore in favor.
> 
> 
> The proposal mentions as alternative “Relaxed redundant imports”, which
> refines the warnings a bit more. In that alternative, an _duplicate
> explicit import_ is cause for a warning; in Chris’ example that would
> be
> 
>   import X (f) -- exports some function @f@
>   import y (f) -- exports the same function @f@
>   g = f
> 
> Under the current proposal, this would no longer warn with -Wall, but I
> think it’s silly to not warn here, as even with changing dependencies,
> this is a code smell. I sympathize with the author’s wish to not make
> this more complicated than necessary to achieve the goal (warnings
> about duplicate _implicit_ imports causing headcaches), but would like
> to keep the door open for someone who wants to implement the refined
> version in the future. That would probably entail a
>  -Wduplicate-explicit-import
> flag which can then live in -Wall, but is still compatible with this
> proposal, so all izz well.
> 
> 
> 
> Adam points out (as quoted in the proposal) that users of
>   -Weverything -Wno-unused-imports
> might see new breakage. I don’t think someone using -Weverything can
> expect any kind of stability, else we paint ourselves into a corner (or
> start introducing -Wreally-everything, -Wreally-really-everything, …)
> 
> 
> Cheers,
> Joachim
> 
> 
> 
> 
> Am Donnerstag, dem 15.06.2023 um 16:50 +0100 schrieb Chris Dornan:
>> Dear Committee,
>> 
>> Georgi Lyubenov has a simple proposal to improve the quality of life for many package maintainers that I recommend that we accept.
>> 
>> ## Split -Wunused-imports
>> 
>> Rendered proposal: <https://github.com/googleson78/ghc-proposals/blob/split-unused-imports/proposals/0000-split-wunused-imports.md>
>> Discussion of proposal: <https://github.com/ghc-proposals/ghc-proposals/pull/586>
>> 
>> ### Summary
>> 
>> (Straight from the proposal.)
>> 
>> We propose to split the -Wunused-imports warning into two parts:
>> 
>> - warn on actual unused imports
>> - warn on duplicate imports
>> 
>> while also not including the second in -Wall. This will greatly reduce "churn" for library authors.
>> 
>> 
>> ## In more Detail
>> 
>> As we know, many Haskell developers, including significant commercial projects, incorporate -Wall
>> -Werror into their workflow at some stage. To this end it is important that we minimise 'false
>> negatives', whereby the compiler emits 'frivolous' warnings.
>> 
>> This proposal identifies an important class of -Wall warnings that many package maintainers
>> appear to regard quite bothersome, namely when the compiler warns that import statement is 
>> superflous even when it is importing an entity that is being used by the module. The issue is
>> the way `-Wunused-imports` works, which will issue a warning for the following program.
>> 
>> ```haskell
>> import X -- exports some function @f@
>> import y -- exports the same function @f@
>> 
>> g = f
>> ```
>> 
>> The compiler will warn that the second Y import is redundant.
>> 
>> Many developers do not want to be warned about this. As far as they are concerned each import is
>> yielding enties that are in use and the fact that one of them can be removed is just not 
>> interesting.
>> 
>> In contrast, developers that use -Wall do want to be warned about the following.
>> 
>> ```haskell
>> import X -- exports some function @f@
>> import Z -- does not export f
>> 
>> g = f
>> ```
>> 
>> Here our module has a completely false dependency on Z which should be cleaned up at the point that
>> warnings are cleaned up.
>> 
>> This proposal proposes modifying -Wunused-imports so that it will warn about the second example but
>> stay silent for the first, and adds a -Wduplicate-imports that will issue a warning for the the
>> first example. In effect the enabling of both warnings in the new proposal will restore the current
>> -Wunused-imports behaviour. -Wall should *not* enable -Wduplicate-imports but is avilable to those
>> developers that rely on the current behaviour of -Wunused-imports (which some clearly do).
>> 
>> 
>> ## Recommendation
>> 
>> I recommend that we accept this proposal.
>> 
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 
> -- 
> 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


From simon.peytonjones at gmail.com  Mon Jun 19 21:10:36 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Mon, 19 Jun 2023 22:10:36 +0100
Subject: [ghc-steering-committee] Base library organisation
In-Reply-To: <CAJKmMz-VCBsWarL-uDhS=vfNPOKecdnHfbxPTmwM9zP1cKYW1Q@mail.gmail.com>
References: <CAJKmMz-VCBsWarL-uDhS=vfNPOKecdnHfbxPTmwM9zP1cKYW1Q@mail.gmail.com>
Message-ID: <CAJKmMz-vA38-QvWNdFQwPk0jyS9nkyYGk13AnBw8MADhNWwKaQ@mail.gmail.com>

Hello GHC steering committee,

Any views about this?

Simon

On Thu, 15 Jun 2023 at 10:03, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> Dear GHC Steering Committee
>
> Over the last few weeks, Ben Gamari and I have been discussing with Andrew
> and Julian from the Core Libraries Committee how to make the Core Libraries
> Committee and the GHC developers work together more fluidly; and that
> includes the GHC Steering Committee.
>
> We now have a fairly well fleshed out proposal here.
> <https://github.com/Ericson2314/tech-proposals/blob/ghc-base-libraries/proposals/accepted/050-ghc-base-libraries.rst>
>
> I hope you like it.  As far as this committee is concerned there are two
> particular points of note
>
>    1. We propose a new package, *ghc-experimental*, which depends on
>    *base*.  Many GHC proposals involve defining new types and functions.
>    The idea is that these would initially be in *ghc-experimental*.
>    After they stabilise and become widely adopted, the author (or anyone else)
>    can make a CLC proposal to move them to *base*, which has much
>    stronger stability guarantees.
>    2. Section 5.1 suggests a mechanism to involve CLC members in
>    proposals that involve new functions and types, at an earlier stage.  Some
>    involve *changing *existing types and functions.  It is clearly
>    unproductive for us to debate such things at length, and only *then *to
>    land it on the CLC.
>
>    Section 5.1 also suggests that proposals should explicitly (in a
>    separate section) call out
>
>
>    - What new types and functions it defines
>    - What existing types and functions are changed.
>
> We should add that to our template.
>
> At the moment we are just sharing the proposal with relevant stakeholders
> (yourselves, CLC, stack folk, cabal folk etc), so that we can polish any
> rough edges before making it public.
>
> So, any views?  Personally I think this is a Big Step Forward.
>
> Simon
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230619/c42e83f2/attachment.html>

From chris at chrisdornan.com  Tue Jun 20 07:03:26 2023
From: chris at chrisdornan.com (Chris Dornan)
Date: Tue, 20 Jun 2023 08:03:26 +0100
Subject: [ghc-steering-committee] Base library organisation
In-Reply-To: <CAJKmMz-vA38-QvWNdFQwPk0jyS9nkyYGk13AnBw8MADhNWwKaQ@mail.gmail.com>
References: <CAJKmMz-VCBsWarL-uDhS=vfNPOKecdnHfbxPTmwM9zP1cKYW1Q@mail.gmail.com>
 <CAJKmMz-vA38-QvWNdFQwPk0jyS9nkyYGk13AnBw8MADhNWwKaQ@mail.gmail.com>
Message-ID: <EF2A7EFB-D998-4DAE-BF30-EA102535AC6C@chrisdornan.com>

Really, all LGTM!

> On 19 Jun 2023, at 22:10, Simon Peyton Jones <simon.peytonjones at gmail.com> wrote:
> 
> Hello GHC steering committee,
> 
> Any views about this? 
> 
> Simon
> 
> On Thu, 15 Jun 2023 at 10:03, Simon Peyton Jones <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>> wrote:
>> Dear GHC Steering Committee
>> 
>> Over the last few weeks, Ben Gamari and I have been discussing with Andrew and Julian from the Core Libraries Committee how to make the Core Libraries Committee and the GHC developers work together more fluidly; and that includes the GHC Steering Committee.
>> 
>> We now have a fairly well fleshed out proposal here. <https://github.com/Ericson2314/tech-proposals/blob/ghc-base-libraries/proposals/accepted/050-ghc-base-libraries.rst>
>> 
>> I hope you like it.  As far as this committee is concerned there are two particular points of note
>> We propose a new package, ghc-experimental, which depends on base.  Many GHC proposals involve defining new types and functions.  The idea is that these would initially be in ghc-experimental.  After they stabilise and become widely adopted, the author (or anyone else) can make a CLC proposal to move them to base, which has much stronger stability guarantees.
>> Section 5.1 suggests a mechanism to involve CLC members in proposals that involve new functions and types, at an earlier stage.  Some involve changing existing types and functions.  It is clearly unproductive for us to debate such things at length, and only then to land it on the CLC.
>> 
>> Section 5.1 also suggests that proposals should explicitly (in a separate section) call out
>> What new types and functions it defines
>> What existing types and functions are changed.
>> We should add that to our template.
>> 
>> At the moment we are just sharing the proposal with relevant stakeholders (yourselves, CLC, stack folk, cabal folk etc), so that we can polish any rough edges before making it public.
>> 
>> So, any views?  Personally I think this is a Big Step Forward.
>> 
>> Simon
>> 
>> 
>> 
> _______________________________________________
> 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/20230620/04a71016/attachment.html>

From arnaud.spiwack at tweag.io  Tue Jun 27 12:39:57 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Tue, 27 Jun 2023 14:39:57 +0200
Subject: [ghc-steering-committee] Split -Wunused-imports (recommend
	accept)
In-Reply-To: <6AC42B82-A845-41CA-A59A-51158464A576@chrisdornan.com>
References: <E064DD1C-69A1-41F9-B56D-BB30ADC35E0B@chrisdornan.com>
 <b71417a6426514e3704d88f75d78d28344acd2c8.camel@joachim-breitner.de>
 <6AC42B82-A845-41CA-A59A-51158464A576@chrisdornan.com>
Message-ID: <CAGwnsnn=sM+X8+V9pNPSGMsmb7EZ49=w5BTG9NCJs+XwQE+xRg@mail.gmail.com>

The problem statement, as I understand it:

I'm writing a library, with dependency L-1 from where I import X and Y(f).
A new version L-2 is released, where X exports (f) as well.
My CI is set to reject all warnings, and start complaining on L-2.
Silencing the warning on L-2 requires some rather gratuitous contortion
(import X hiding (f)) just to be able to compile with L-1! (even if we
don't require L-1 to compile without warning).

I'm not really fond of the idea of removing this type of duplicate import
warning from -wall, to be honest. But I do agree that we shouldn't have to
contort the code that way if the libraries are otherwise completely
compatible. The fact that it's easy, by merely silencing a warning on
imports to break compatibility with a previous version is not something to
be proud of.

Therefore *I'm in favour* of this proposal (albeit reluctantly).

Oleg Grengrus's comment on the discussion thread makes me think that maybe
there should be two different recommended sets of warnings: one for
libraries (where compatibility with several versions of a dependency is
desirable), and one for applications (where you are typically bound to a
single version of your dependencies). Though it's probably too much
overhead for a single warning difference between the two.

On Fri, 16 Jun 2023 at 16:05, Chris Dornan <chris at chrisdornan.com> wrote:

> Just for the record, I am also open to refinement of the import-warning
> toolbox in future but I think this proposal is the best next step.
>
> Given how straightforward the proposition is, how about we set a week for
> objections to be raised and move to accept the proposal if none are
> forthcoming (by Saturday, 2023-06-24).
>
> Chris
>
> > On 16 Jun 2023, at 13:33, Joachim Breitner <mail at joachim-breitner.de>
> wrote:
> >
> > Hi,
> >
> > this proposal highlights a fundamental tension with compiler warnings.
> >
> > If you assume a never changing background of dependencies, then the
> > current behavior isn’t too bad: GHC correctly tell you that you can
> > remove a line of code, and that is a good thing. I don’t think that
> > this is directly what is bothering developers.
> >
> > But dependencies do change, and exports get moved around, and code that
> > wasn’t warning before suddenly warns. And that is what’s annoying!
> >
> > So there is a tension between “given the current assumptions, your code
> > can be improved” vs. “assumptions change”.
> >
> > I agree that at least in this case (and probably in general) we want
> > the -Wall warnings to be reasonably insensitive to dependency changes,
> > so that good code stays “good”. Of course this is not a hard rule –
> > think of deprecation warnings, but a decent guideline.
> >
> > Therefore in favor.
> >
> >
> > The proposal mentions as alternative “Relaxed redundant imports”, which
> > refines the warnings a bit more. In that alternative, an _duplicate
> > explicit import_ is cause for a warning; in Chris’ example that would
> > be
> >
> >   import X (f) -- exports some function @f@
> >   import y (f) -- exports the same function @f@
> >   g = f
> >
> > Under the current proposal, this would no longer warn with -Wall, but I
> > think it’s silly to not warn here, as even with changing dependencies,
> > this is a code smell. I sympathize with the author’s wish to not make
> > this more complicated than necessary to achieve the goal (warnings
> > about duplicate _implicit_ imports causing headcaches), but would like
> > to keep the door open for someone who wants to implement the refined
> > version in the future. That would probably entail a
> >  -Wduplicate-explicit-import
> > flag which can then live in -Wall, but is still compatible with this
> > proposal, so all izz well.
> >
> >
> >
> > Adam points out (as quoted in the proposal) that users of
> >   -Weverything -Wno-unused-imports
> > might see new breakage. I don’t think someone using -Weverything can
> > expect any kind of stability, else we paint ourselves into a corner (or
> > start introducing -Wreally-everything, -Wreally-really-everything, …)
> >
> >
> > Cheers,
> > Joachim
> >
> >
> >
> >
> > Am Donnerstag, dem 15.06.2023 um 16:50 +0100 schrieb Chris Dornan:
> >> Dear Committee,
> >>
> >> Georgi Lyubenov has a simple proposal to improve the quality of life
> for many package maintainers that I recommend that we accept.
> >>
> >> ## Split -Wunused-imports
> >>
> >> Rendered proposal: <
> https://github.com/googleson78/ghc-proposals/blob/split-unused-imports/proposals/0000-split-wunused-imports.md
> >
> >> Discussion of proposal: <
> https://github.com/ghc-proposals/ghc-proposals/pull/586>
> >>
> >> ### Summary
> >>
> >> (Straight from the proposal.)
> >>
> >> We propose to split the -Wunused-imports warning into two parts:
> >>
> >> - warn on actual unused imports
> >> - warn on duplicate imports
> >>
> >> while also not including the second in -Wall. This will greatly reduce
> "churn" for library authors.
> >>
> >>
> >> ## In more Detail
> >>
> >> As we know, many Haskell developers, including significant commercial
> projects, incorporate -Wall
> >> -Werror into their workflow at some stage. To this end it is important
> that we minimise 'false
> >> negatives', whereby the compiler emits 'frivolous' warnings.
> >>
> >> This proposal identifies an important class of -Wall warnings that many
> package maintainers
> >> appear to regard quite bothersome, namely when the compiler warns that
> import statement is
> >> superflous even when it is importing an entity that is being used by
> the module. The issue is
> >> the way `-Wunused-imports` works, which will issue a warning for the
> following program.
> >>
> >> ```haskell
> >> import X -- exports some function @f@
> >> import y -- exports the same function @f@
> >>
> >> g = f
> >> ```
> >>
> >> The compiler will warn that the second Y import is redundant.
> >>
> >> Many developers do not want to be warned about this. As far as they are
> concerned each import is
> >> yielding enties that are in use and the fact that one of them can be
> removed is just not
> >> interesting.
> >>
> >> In contrast, developers that use -Wall do want to be warned about the
> following.
> >>
> >> ```haskell
> >> import X -- exports some function @f@
> >> import Z -- does not export f
> >>
> >> g = f
> >> ```
> >>
> >> Here our module has a completely false dependency on Z which should be
> cleaned up at the point that
> >> warnings are cleaned up.
> >>
> >> This proposal proposes modifying -Wunused-imports so that it will warn
> about the second example but
> >> stay silent for the first, and adds a -Wduplicate-imports that will
> issue a warning for the the
> >> first example. In effect the enabling of both warnings in the new
> proposal will restore the current
> >> -Wunused-imports behaviour. -Wall should *not* enable
> -Wduplicate-imports but is avilable to those
> >> developers that rely on the current behaviour of -Wunused-imports
> (which some clearly do).
> >>
> >>
> >> ## Recommendation
> >>
> >> I recommend that we accept this proposal.
> >>
> >> _______________________________________________
> >> ghc-steering-committee mailing list
> >> ghc-steering-committee at haskell.org
> >>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> >
> > --
> > 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
>


-- 
Arnaud Spiwack
Director, Research at https://moduscreate.com and https://tweag.io.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230627/aa1b81ca/attachment.html>

From arnaud.spiwack at tweag.io  Tue Jun 27 13:08:48 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Tue, 27 Jun 2023 15:08:48 +0200
Subject: [ghc-steering-committee] Base library organisation
In-Reply-To: <EF2A7EFB-D998-4DAE-BF30-EA102535AC6C@chrisdornan.com>
References: <CAJKmMz-VCBsWarL-uDhS=vfNPOKecdnHfbxPTmwM9zP1cKYW1Q@mail.gmail.com>
 <CAJKmMz-vA38-QvWNdFQwPk0jyS9nkyYGk13AnBw8MADhNWwKaQ@mail.gmail.com>
 <EF2A7EFB-D998-4DAE-BF30-EA102535AC6C@chrisdornan.com>
Message-ID: <CAGwnsnkjE+Wq4Y9SW7mWEDdfEKsKtBtj7epSQXfek7vF5N5nDQ@mail.gmail.com>

I don't have a strong opinion. I trust the people involved.

The one thing I'll note is that the part about discouraging people from
depending on ghc-internals seems to involve an awful lot of work. I
wouldn't count on such work being done promptly. The one thing in the least
that can be done reasonably cheaply is making sure that every module in
ghc-internals to be annotated with {-# OPTIONS_HADDOCK hide #-} (so that
Haddock only generate documentation for the source but not for the module
interfaces).

/Arnaud

On Tue, 20 Jun 2023 at 09:03, Chris Dornan <chris at chrisdornan.com> wrote:

> Really, all LGTM!
>
> On 19 Jun 2023, at 22:10, Simon Peyton Jones <simon.peytonjones at gmail.com>
> wrote:
>
> Hello GHC steering committee,
>
> Any views about this?
>
> Simon
>
> On Thu, 15 Jun 2023 at 10:03, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
>> Dear GHC Steering Committee
>>
>> Over the last few weeks, Ben Gamari and I have been discussing with
>> Andrew and Julian from the Core Libraries Committee how to make the Core
>> Libraries Committee and the GHC developers work together more fluidly; and
>> that includes the GHC Steering Committee.
>>
>> We now have a fairly well fleshed out proposal here.
>> <https://github.com/Ericson2314/tech-proposals/blob/ghc-base-libraries/proposals/accepted/050-ghc-base-libraries.rst>
>>
>> I hope you like it.  As far as this committee is concerned there are two
>> particular points of note
>>
>>    1. We propose a new package, *ghc-experimental*, which depends on
>>    *base*.  Many GHC proposals involve defining new types and
>>    functions.  The idea is that these would initially be in
>>    *ghc-experimental*.  After they stabilise and become widely adopted,
>>    the author (or anyone else) can make a CLC proposal to move them to
>>    *base*, which has much stronger stability guarantees.
>>    2. Section 5.1 suggests a mechanism to involve CLC members in
>>    proposals that involve new functions and types, at an earlier stage.  Some
>>    involve *changing *existing types and functions.  It is clearly
>>    unproductive for us to debate such things at length, and only *then *to
>>    land it on the CLC.
>>
>>    Section 5.1 also suggests that proposals should explicitly (in a
>>    separate section) call out
>>
>>
>>    - What new types and functions it defines
>>    - What existing types and functions are changed.
>>
>> We should add that to our template.
>>
>> At the moment we are just sharing the proposal with relevant stakeholders
>> (yourselves, CLC, stack folk, cabal folk etc), so that we can polish any
>> rough edges before making it public.
>>
>> So, any views?  Personally I think this is a Big Step Forward.
>>
>> Simon
>>
>>
>>
>> _______________________________________________
> 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
>


-- 
Arnaud Spiwack
Director, Research at https://moduscreate.com and https://tweag.io.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230627/7468cda4/attachment-0001.html>

From moritz.angermann at gmail.com  Tue Jun 27 13:59:18 2023
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Tue, 27 Jun 2023 15:59:18 +0200
Subject: [ghc-steering-committee] Base library organisation
In-Reply-To: <CAGwnsnkjE+Wq4Y9SW7mWEDdfEKsKtBtj7epSQXfek7vF5N5nDQ@mail.gmail.com>
References: <CAJKmMz-VCBsWarL-uDhS=vfNPOKecdnHfbxPTmwM9zP1cKYW1Q@mail.gmail.com>
 <CAJKmMz-vA38-QvWNdFQwPk0jyS9nkyYGk13AnBw8MADhNWwKaQ@mail.gmail.com>
 <EF2A7EFB-D998-4DAE-BF30-EA102535AC6C@chrisdornan.com>
 <CAGwnsnkjE+Wq4Y9SW7mWEDdfEKsKtBtj7epSQXfek7vF5N5nDQ@mail.gmail.com>
Message-ID: <CAKfdd-xrY0WeY_Pn657keo4E37nEXM4Fqi6JgN8e6wcOJJvo6g@mail.gmail.com>

I have some concern around the discouraging concept as well.

Ideally we had some marker INTERNAL like DEPRECATED, that could be attached
to individual bindings, complete modules or even packages. If this existed,
we could have code either error if it used any INTERNAL binding, and no
-fpermit-internals was provided. If this was attached to already exposed
bindings we’d want a warning phase for at least two releases which I
believe DEPRECATED could do?

However, we don’t have this today, so I wouldn’t want this to block this
proposal from progressing.

I’m not so much for hiding it. Reading up on it and knowing the details (or
even looking at the source) can be helpful at times. Making discovery
harder by hiding it would not be my preferred route.

Cheers,
 Moritz

On Tue, 27 Jun 2023 at 3:09 PM, Arnaud Spiwack <arnaud.spiwack at tweag.io>
wrote:

> I don't have a strong opinion. I trust the people involved.
>
> The one thing I'll note is that the part about discouraging people from
> depending on ghc-internals seems to involve an awful lot of work. I
> wouldn't count on such work being done promptly. The one thing in the least
> that can be done reasonably cheaply is making sure that every module in
> ghc-internals to be annotated with {-# OPTIONS_HADDOCK hide #-} (so that
> Haddock only generate documentation for the source but not for the module
> interfaces).
>
> /Arnaud
>
> On Tue, 20 Jun 2023 at 09:03, Chris Dornan <chris at chrisdornan.com> wrote:
>
>> Really, all LGTM!
>>
>> On 19 Jun 2023, at 22:10, Simon Peyton Jones <simon.peytonjones at gmail.com>
>> wrote:
>>
>> Hello GHC steering committee,
>>
>> Any views about this?
>>
>> Simon
>>
>> On Thu, 15 Jun 2023 at 10:03, Simon Peyton Jones <
>> simon.peytonjones at gmail.com> wrote:
>>
>>> Dear GHC Steering Committee
>>>
>>> Over the last few weeks, Ben Gamari and I have been discussing with
>>> Andrew and Julian from the Core Libraries Committee how to make the Core
>>> Libraries Committee and the GHC developers work together more fluidly; and
>>> that includes the GHC Steering Committee.
>>>
>>> We now have a fairly well fleshed out proposal here.
>>> <https://github.com/Ericson2314/tech-proposals/blob/ghc-base-libraries/proposals/accepted/050-ghc-base-libraries.rst>
>>>
>>> I hope you like it.  As far as this committee is concerned there are two
>>> particular points of note
>>>
>>>    1. We propose a new package, *ghc-experimental*, which depends on
>>>    *base*.  Many GHC proposals involve defining new types and
>>>    functions.  The idea is that these would initially be in
>>>    *ghc-experimental*.  After they stabilise and become widely adopted,
>>>    the author (or anyone else) can make a CLC proposal to move them to
>>>    *base*, which has much stronger stability guarantees.
>>>    2. Section 5.1 suggests a mechanism to involve CLC members in
>>>    proposals that involve new functions and types, at an earlier stage.  Some
>>>    involve *changing *existing types and functions.  It is clearly
>>>    unproductive for us to debate such things at length, and only *then *to
>>>    land it on the CLC.
>>>
>>>    Section 5.1 also suggests that proposals should explicitly (in a
>>>    separate section) call out
>>>
>>>
>>>    - What new types and functions it defines
>>>    - What existing types and functions are changed.
>>>
>>> We should add that to our template.
>>>
>>> At the moment we are just sharing the proposal with relevant
>>> stakeholders (yourselves, CLC, stack folk, cabal folk etc), so that we can
>>> polish any rough edges before making it public.
>>>
>>> So, any views?  Personally I think this is a Big Step Forward.
>>>
>>> Simon
>>>
>>>
>>>
>>> _______________________________________________
>> 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
>>
>
>
> --
> Arnaud Spiwack
> Director, Research at https://moduscreate.com and https://tweag.io.
> _______________________________________________
> 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/20230627/8e409ea0/attachment.html>

From simon.peytonjones at gmail.com  Tue Jun 27 14:10:17 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Tue, 27 Jun 2023 15:10:17 +0100
Subject: [ghc-steering-committee] Base library organisation
In-Reply-To: <CAKfdd-xrY0WeY_Pn657keo4E37nEXM4Fqi6JgN8e6wcOJJvo6g@mail.gmail.com>
References: <CAJKmMz-VCBsWarL-uDhS=vfNPOKecdnHfbxPTmwM9zP1cKYW1Q@mail.gmail.com>
 <CAJKmMz-vA38-QvWNdFQwPk0jyS9nkyYGk13AnBw8MADhNWwKaQ@mail.gmail.com>
 <EF2A7EFB-D998-4DAE-BF30-EA102535AC6C@chrisdornan.com>
 <CAGwnsnkjE+Wq4Y9SW7mWEDdfEKsKtBtj7epSQXfek7vF5N5nDQ@mail.gmail.com>
 <CAKfdd-xrY0WeY_Pn657keo4E37nEXM4Fqi6JgN8e6wcOJJvo6g@mail.gmail.com>
Message-ID: <CAJKmMz8R8ZixNMGOGV7HtR48TQLuTQgugGmRR=D+bDhMvR_-2g@mail.gmail.com>

I don't think we want to flag *individual *bindings in ghc-internals; they
are all there for a good, internal, non-deprecated reason.  What we want to
discourage is for GHC clients to depend on *any module *in ghc-internals
casually, without having a Strong Reason to do so. Why discourage?

   - Everything they want should be in base.  And maybe it already is!   If
   not, and if they have a need, and base doesn't have it, then they may want
   to depend on ghc-internals temporarily and petition CLC to extend base.
   - If they casually depend on ghc-internals, they impose costs on
   themselves (when we change the API) and on us (when they complain about us
   changing the API).

I have no strong opinion about want form "discourage" takes.  Certainly not
"prevent".

Simon



On Tue, 27 Jun 2023 at 14:59, Moritz Angermann <moritz.angermann at gmail.com>
wrote:

> I have some concern around the discouraging concept as well.
>
> Ideally we had some marker INTERNAL like DEPRECATED, that could be
> attached to individual bindings, complete modules or even packages. If this
> existed, we could have code either error if it used any INTERNAL binding,
> and no -fpermit-internals was provided. If this was attached to already
> exposed bindings we’d want a warning phase for at least two releases which
> I believe DEPRECATED could do?
>
> However, we don’t have this today, so I wouldn’t want this to block this
> proposal from progressing.
>
> I’m not so much for hiding it. Reading up on it and knowing the details
> (or even looking at the source) can be helpful at times. Making discovery
> harder by hiding it would not be my preferred route.
>
> Cheers,
>  Moritz
>
> On Tue, 27 Jun 2023 at 3:09 PM, Arnaud Spiwack <arnaud.spiwack at tweag.io>
> wrote:
>
>> I don't have a strong opinion. I trust the people involved.
>>
>> The one thing I'll note is that the part about discouraging people from
>> depending on ghc-internals seems to involve an awful lot of work. I
>> wouldn't count on such work being done promptly. The one thing in the least
>> that can be done reasonably cheaply is making sure that every module in
>> ghc-internals to be annotated with {-# OPTIONS_HADDOCK hide #-} (so that
>> Haddock only generate documentation for the source but not for the module
>> interfaces).
>>
>> /Arnaud
>>
>> On Tue, 20 Jun 2023 at 09:03, Chris Dornan <chris at chrisdornan.com> wrote:
>>
>>> Really, all LGTM!
>>>
>>> On 19 Jun 2023, at 22:10, Simon Peyton Jones <
>>> simon.peytonjones at gmail.com> wrote:
>>>
>>> Hello GHC steering committee,
>>>
>>> Any views about this?
>>>
>>> Simon
>>>
>>> On Thu, 15 Jun 2023 at 10:03, Simon Peyton Jones <
>>> simon.peytonjones at gmail.com> wrote:
>>>
>>>> Dear GHC Steering Committee
>>>>
>>>> Over the last few weeks, Ben Gamari and I have been discussing with
>>>> Andrew and Julian from the Core Libraries Committee how to make the Core
>>>> Libraries Committee and the GHC developers work together more fluidly; and
>>>> that includes the GHC Steering Committee.
>>>>
>>>> We now have a fairly well fleshed out proposal here.
>>>> <https://github.com/Ericson2314/tech-proposals/blob/ghc-base-libraries/proposals/accepted/050-ghc-base-libraries.rst>
>>>>
>>>> I hope you like it.  As far as this committee is concerned there are
>>>> two particular points of note
>>>>
>>>>    1. We propose a new package, *ghc-experimental*, which depends on
>>>>    *base*.  Many GHC proposals involve defining new types and
>>>>    functions.  The idea is that these would initially be in
>>>>    *ghc-experimental*.  After they stabilise and become widely
>>>>    adopted, the author (or anyone else) can make a CLC proposal to move them
>>>>    to *base*, which has much stronger stability guarantees.
>>>>    2. Section 5.1 suggests a mechanism to involve CLC members in
>>>>    proposals that involve new functions and types, at an earlier stage.  Some
>>>>    involve *changing *existing types and functions.  It is clearly
>>>>    unproductive for us to debate such things at length, and only *then
>>>>    *to land it on the CLC.
>>>>
>>>>    Section 5.1 also suggests that proposals should explicitly (in a
>>>>    separate section) call out
>>>>
>>>>
>>>>    - What new types and functions it defines
>>>>    - What existing types and functions are changed.
>>>>
>>>> We should add that to our template.
>>>>
>>>> At the moment we are just sharing the proposal with relevant
>>>> stakeholders (yourselves, CLC, stack folk, cabal folk etc), so that we can
>>>> polish any rough edges before making it public.
>>>>
>>>> So, any views?  Personally I think this is a Big Step Forward.
>>>>
>>>> Simon
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>> 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
>>>
>>
>>
>> --
>> Arnaud Spiwack
>> Director, Research at https://moduscreate.com and https://tweag.io.
>> _______________________________________________
>> 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/20230627/926a5470/attachment-0001.html>

From moritz.angermann at gmail.com  Tue Jun 27 14:43:11 2023
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Tue, 27 Jun 2023 16:43:11 +0200
Subject: [ghc-steering-committee] Base library organisation
In-Reply-To: <CAJKmMz8R8ZixNMGOGV7HtR48TQLuTQgugGmRR=D+bDhMvR_-2g@mail.gmail.com>
References: <CAJKmMz-VCBsWarL-uDhS=vfNPOKecdnHfbxPTmwM9zP1cKYW1Q@mail.gmail.com>
 <CAJKmMz-vA38-QvWNdFQwPk0jyS9nkyYGk13AnBw8MADhNWwKaQ@mail.gmail.com>
 <EF2A7EFB-D998-4DAE-BF30-EA102535AC6C@chrisdornan.com>
 <CAGwnsnkjE+Wq4Y9SW7mWEDdfEKsKtBtj7epSQXfek7vF5N5nDQ@mail.gmail.com>
 <CAKfdd-xrY0WeY_Pn657keo4E37nEXM4Fqi6JgN8e6wcOJJvo6g@mail.gmail.com>
 <CAJKmMz8R8ZixNMGOGV7HtR48TQLuTQgugGmRR=D+bDhMvR_-2g@mail.gmail.com>
Message-ID: <CAKfdd-x175kURqEXPZaaZ-_HDhxf8VNKq4Jhfvm9T3X+VNdDhA@mail.gmail.com>

I have strong reasons to discourage them. As a consumer of components that
can transitively depend on any of those, I must make sure none of my
dependencies depend on these internals (other than GHC itself). Any
component that depends on ghc-internals is not fit for use in projects I’d
be responsible for.

I can not continue spending the obscene amounts we spend for compiler
upgrades.

If someone in a leaf node depends to use internals I have no problem with
this. If this unintentionally slips into any library that I transitively
depend on, I have a problem. This needs to be *very* loud and explicit. I
would almost call it tainted that something depends on APIs that have no
stability guarantees.

To illustrate this. Let’s assume we have a Haskell application which
depends on pkg A transitively though 10+ pkgs. pkg A-1.0 decides to depend
on GHC-internals. Next GHC comes around, breaks GHC-internals, pkg A is now
broken. pkg A’s master branch is at 3.0, and will now get the update and be
compatible with GHC-internals. What about 1.0? Touch luck. And now this
process ripples through 10+ layers of dependencies.

Not only is this exceptionally expensive to adapt to. It also means there
is no sensible way to measure regressions of the application. The compiler
upgrade has now caused lots of code changes throughout the whole codebase
(including dependencies).

Therefore, I’d want ghc-internals to be flagged as INTERNAL, GHC itself be
built with -fpermit-internals, but everyone else having explicitly to opt
in to that (and for me an easy way to prohibit the use of any
non-whitelisted packages using -fpermit-internals).

We want to decouple a stable set of base base libraries from the GHC
internal libraries that have less rigorous stability guarantees, because
they are explicitly internal after all. However if we let this leak out too
easily we have forfeit significant benefits this could bring.

As someone dealing with a massive codebase, how am I justifying spending
six figures to just make the code compatible with a new compiler and then
find out that I’m now facing performance regressions?!

Thus form a practical point of view, I want to insulate my codebase as much
as possible from depending in any form on GHC-internals or other libraries
with a reduced stability guarantee.

Depending on ghc-internals (or any such reduced stability library) should
come with high hurdles and excessive bells. (Which could be consciously
silenced by something like -fpermit-internals).

On the other hand if this is too easy to do, we end up with lots of
libraries on hackage depending on GHC-internals, and breaking every release
cycle we’ve won nothing but only complicated things.

Again, we don’t have the facilities for this today. But I would urge us to
get the asap.

On a final note:
> If not, and if they have a need, and base doesn't have it, then they may
want to depend on ghc-internals temporarily and petition CLC to extend base.

I consider this a very slippery slope. We want the split to be explicit and
conscious not for people to end up depending on base and GHC-internal
because they just need something. It need to be _strongly_ discouraged to
do so, and it need to be more painful to use than petition the CLC to
extend base. Otherwise the incentives are aligned in a way that people do
not petition the CLC but just use GHC-internals.

I do not want to prevent people from this. There are escape hatches. I want
to to be able to prevent any such software that uses those escape hatches.
And I also want to strongly discourage people from using escape hatches and
rather motivate them to petition the CLC to extend base with a stable
interface for their needs.

Cheers,
 Moritz

On Tue, 27 Jun 2023 at 4:10 PM, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> I don't think we want to flag *individual *bindings in ghc-internals;
> they are all there for a good, internal, non-deprecated reason.  What we
> want to discourage is for GHC clients to depend on *any module *in
> ghc-internals casually, without having a Strong Reason to do so. Why
> discourage?
>
>    - Everything they want should be in base.  And maybe it already is!
>    If not, and if they have a need, and base doesn't have it, then they may
>    want to depend on ghc-internals temporarily and petition CLC to extend base.
>    - If they casually depend on ghc-internals, they impose costs on
>    themselves (when we change the API) and on us (when they complain about us
>    changing the API).
>
> I have no strong opinion about want form "discourage" takes.  Certainly
> not "prevent".
>
> Simon
>
>
>
> On Tue, 27 Jun 2023 at 14:59, Moritz Angermann <moritz.angermann at gmail.com>
> wrote:
>
>> I have some concern around the discouraging concept as well.
>>
>> Ideally we had some marker INTERNAL like DEPRECATED, that could be
>> attached to individual bindings, complete modules or even packages. If this
>> existed, we could have code either error if it used any INTERNAL binding,
>> and no -fpermit-internals was provided. If this was attached to already
>> exposed bindings we’d want a warning phase for at least two releases which
>> I believe DEPRECATED could do?
>>
>> However, we don’t have this today, so I wouldn’t want this to block this
>> proposal from progressing.
>>
>> I’m not so much for hiding it. Reading up on it and knowing the details
>> (or even looking at the source) can be helpful at times. Making discovery
>> harder by hiding it would not be my preferred route.
>>
>> Cheers,
>>  Moritz
>>
>> On Tue, 27 Jun 2023 at 3:09 PM, Arnaud Spiwack <arnaud.spiwack at tweag.io>
>> wrote:
>>
>>> I don't have a strong opinion. I trust the people involved.
>>>
>>> The one thing I'll note is that the part about discouraging people from
>>> depending on ghc-internals seems to involve an awful lot of work. I
>>> wouldn't count on such work being done promptly. The one thing in the least
>>> that can be done reasonably cheaply is making sure that every module in
>>> ghc-internals to be annotated with {-# OPTIONS_HADDOCK hide #-} (so that
>>> Haddock only generate documentation for the source but not for the module
>>> interfaces).
>>>
>>> /Arnaud
>>>
>>> On Tue, 20 Jun 2023 at 09:03, Chris Dornan <chris at chrisdornan.com>
>>> wrote:
>>>
>>>> Really, all LGTM!
>>>>
>>>> On 19 Jun 2023, at 22:10, Simon Peyton Jones <
>>>> simon.peytonjones at gmail.com> wrote:
>>>>
>>>> Hello GHC steering committee,
>>>>
>>>> Any views about this?
>>>>
>>>> Simon
>>>>
>>>> On Thu, 15 Jun 2023 at 10:03, Simon Peyton Jones <
>>>> simon.peytonjones at gmail.com> wrote:
>>>>
>>>>> Dear GHC Steering Committee
>>>>>
>>>>> Over the last few weeks, Ben Gamari and I have been discussing with
>>>>> Andrew and Julian from the Core Libraries Committee how to make the Core
>>>>> Libraries Committee and the GHC developers work together more fluidly; and
>>>>> that includes the GHC Steering Committee.
>>>>>
>>>>> We now have a fairly well fleshed out proposal here.
>>>>> <https://github.com/Ericson2314/tech-proposals/blob/ghc-base-libraries/proposals/accepted/050-ghc-base-libraries.rst>
>>>>>
>>>>> I hope you like it.  As far as this committee is concerned there are
>>>>> two particular points of note
>>>>>
>>>>>    1. We propose a new package, *ghc-experimental*, which depends on
>>>>>    *base*.  Many GHC proposals involve defining new types and
>>>>>    functions.  The idea is that these would initially be in
>>>>>    *ghc-experimental*.  After they stabilise and become widely
>>>>>    adopted, the author (or anyone else) can make a CLC proposal to move them
>>>>>    to *base*, which has much stronger stability guarantees.
>>>>>    2. Section 5.1 suggests a mechanism to involve CLC members in
>>>>>    proposals that involve new functions and types, at an earlier stage.  Some
>>>>>    involve *changing *existing types and functions.  It is clearly
>>>>>    unproductive for us to debate such things at length, and only *then
>>>>>    *to land it on the CLC.
>>>>>
>>>>>    Section 5.1 also suggests that proposals should explicitly (in a
>>>>>    separate section) call out
>>>>>
>>>>>
>>>>>    - What new types and functions it defines
>>>>>    - What existing types and functions are changed.
>>>>>
>>>>> We should add that to our template.
>>>>>
>>>>> At the moment we are just sharing the proposal with relevant
>>>>> stakeholders (yourselves, CLC, stack folk, cabal folk etc), so that we can
>>>>> polish any rough edges before making it public.
>>>>>
>>>>> So, any views?  Personally I think this is a Big Step Forward.
>>>>>
>>>>> Simon
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>> 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
>>>>
>>>
>>>
>>> --
>>> Arnaud Spiwack
>>> Director, Research at https://moduscreate.com and https://tweag.io.
>>> _______________________________________________
>>> 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/20230627/d0ac501f/attachment-0001.html>

From simon.peytonjones at gmail.com  Tue Jun 27 15:02:10 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Tue, 27 Jun 2023 16:02:10 +0100
Subject: [ghc-steering-committee] Base library organisation
In-Reply-To: <CAKfdd-x175kURqEXPZaaZ-_HDhxf8VNKq4Jhfvm9T3X+VNdDhA@mail.gmail.com>
References: <CAJKmMz-VCBsWarL-uDhS=vfNPOKecdnHfbxPTmwM9zP1cKYW1Q@mail.gmail.com>
 <CAJKmMz-vA38-QvWNdFQwPk0jyS9nkyYGk13AnBw8MADhNWwKaQ@mail.gmail.com>
 <EF2A7EFB-D998-4DAE-BF30-EA102535AC6C@chrisdornan.com>
 <CAGwnsnkjE+Wq4Y9SW7mWEDdfEKsKtBtj7epSQXfek7vF5N5nDQ@mail.gmail.com>
 <CAKfdd-xrY0WeY_Pn657keo4E37nEXM4Fqi6JgN8e6wcOJJvo6g@mail.gmail.com>
 <CAJKmMz8R8ZixNMGOGV7HtR48TQLuTQgugGmRR=D+bDhMvR_-2g@mail.gmail.com>
 <CAKfdd-x175kURqEXPZaaZ-_HDhxf8VNKq4Jhfvm9T3X+VNdDhA@mail.gmail.com>
Message-ID: <CAJKmMz8rOGmAF6RmK+mDDf1ddNwyJexwA4dL+EEJRoHKLCq-aQ@mail.gmail.com>

>
> And I also want to strongly discourage people from using escape hatches
> and rather motivate them to petition the CLC to extend base with a stable
> interface for their needs.
>

I'll all for that!

Therefore, I’d want ghc-internals to be flagged as INTERNAL, GHC itself be
> built with -fpermit-internals, but everyone else having explicitly to opt
> in to that (and for me an easy way to prohibit the use of any
> non-whitelisted packages using -fpermit-internals).
>
I think the question is: how do they "explicitly opt in"?  One possibility
is: they depend on ghc-internals in their .cabal file.  That's explicit,
and it's opting in.

There is some user interface design here, presumably involving cabal.

Simon

On Tue, 27 Jun 2023 at 15:43, Moritz Angermann <moritz.angermann at gmail.com>
wrote:

> I have strong reasons to discourage them. As a consumer of components that
> can transitively depend on any of those, I must make sure none of my
> dependencies depend on these internals (other than GHC itself). Any
> component that depends on ghc-internals is not fit for use in projects I’d
> be responsible for.
>
> I can not continue spending the obscene amounts we spend for compiler
> upgrades.
>
> If someone in a leaf node depends to use internals I have no problem with
> this. If this unintentionally slips into any library that I transitively
> depend on, I have a problem. This needs to be *very* loud and explicit. I
> would almost call it tainted that something depends on APIs that have no
> stability guarantees.
>
> To illustrate this. Let’s assume we have a Haskell application which
> depends on pkg A transitively though 10+ pkgs. pkg A-1.0 decides to depend
> on GHC-internals. Next GHC comes around, breaks GHC-internals, pkg A is now
> broken. pkg A’s master branch is at 3.0, and will now get the update and be
> compatible with GHC-internals. What about 1.0? Touch luck. And now this
> process ripples through 10+ layers of dependencies.
>
> Not only is this exceptionally expensive to adapt to. It also means there
> is no sensible way to measure regressions of the application. The compiler
> upgrade has now caused lots of code changes throughout the whole codebase
> (including dependencies).
>
> Therefore, I’d want ghc-internals to be flagged as INTERNAL, GHC itself be
> built with -fpermit-internals, but everyone else having explicitly to opt
> in to that (and for me an easy way to prohibit the use of any
> non-whitelisted packages using -fpermit-internals).
>
> We want to decouple a stable set of base base libraries from the GHC
> internal libraries that have less rigorous stability guarantees, because
> they are explicitly internal after all. However if we let this leak out too
> easily we have forfeit significant benefits this could bring.
>
> As someone dealing with a massive codebase, how am I justifying spending
> six figures to just make the code compatible with a new compiler and then
> find out that I’m now facing performance regressions?!
>
> Thus form a practical point of view, I want to insulate my codebase as
> much as possible from depending in any form on GHC-internals or other
> libraries with a reduced stability guarantee.
>
> Depending on ghc-internals (or any such reduced stability library) should
> come with high hurdles and excessive bells. (Which could be consciously
> silenced by something like -fpermit-internals).
>
> On the other hand if this is too easy to do, we end up with lots of
> libraries on hackage depending on GHC-internals, and breaking every release
> cycle we’ve won nothing but only complicated things.
>
> Again, we don’t have the facilities for this today. But I would urge us to
> get the asap.
>
> On a final note:
> > If not, and if they have a need, and base doesn't have it, then they
> may want to depend on ghc-internals temporarily and petition CLC to extend
> base.
>
> I consider this a very slippery slope. We want the split to be explicit
> and conscious not for people to end up depending on base and GHC-internal
> because they just need something. It need to be _strongly_ discouraged to
> do so, and it need to be more painful to use than petition the CLC to
> extend base. Otherwise the incentives are aligned in a way that people do
> not petition the CLC but just use GHC-internals.
>
> I do not want to prevent people from this. There are escape hatches. I
> want to to be able to prevent any such software that uses those escape
> hatches. And I also want to strongly discourage people from using escape
> hatches and rather motivate them to petition the CLC to extend base with a
> stable interface for their needs.
>
> Cheers,
>  Moritz
>
> On Tue, 27 Jun 2023 at 4:10 PM, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
>> I don't think we want to flag *individual *bindings in ghc-internals;
>> they are all there for a good, internal, non-deprecated reason.  What we
>> want to discourage is for GHC clients to depend on *any module *in
>> ghc-internals casually, without having a Strong Reason to do so. Why
>> discourage?
>>
>>    - Everything they want should be in base.  And maybe it already is!
>>    If not, and if they have a need, and base doesn't have it, then they may
>>    want to depend on ghc-internals temporarily and petition CLC to extend base.
>>    - If they casually depend on ghc-internals, they impose costs on
>>    themselves (when we change the API) and on us (when they complain about us
>>    changing the API).
>>
>> I have no strong opinion about want form "discourage" takes.  Certainly
>> not "prevent".
>>
>> Simon
>>
>>
>>
>> On Tue, 27 Jun 2023 at 14:59, Moritz Angermann <
>> moritz.angermann at gmail.com> wrote:
>>
>>> I have some concern around the discouraging concept as well.
>>>
>>> Ideally we had some marker INTERNAL like DEPRECATED, that could be
>>> attached to individual bindings, complete modules or even packages. If this
>>> existed, we could have code either error if it used any INTERNAL binding,
>>> and no -fpermit-internals was provided. If this was attached to already
>>> exposed bindings we’d want a warning phase for at least two releases which
>>> I believe DEPRECATED could do?
>>>
>>> However, we don’t have this today, so I wouldn’t want this to block this
>>> proposal from progressing.
>>>
>>> I’m not so much for hiding it. Reading up on it and knowing the details
>>> (or even looking at the source) can be helpful at times. Making discovery
>>> harder by hiding it would not be my preferred route.
>>>
>>> Cheers,
>>>  Moritz
>>>
>>> On Tue, 27 Jun 2023 at 3:09 PM, Arnaud Spiwack <arnaud.spiwack at tweag.io>
>>> wrote:
>>>
>>>> I don't have a strong opinion. I trust the people involved.
>>>>
>>>> The one thing I'll note is that the part about discouraging people from
>>>> depending on ghc-internals seems to involve an awful lot of work. I
>>>> wouldn't count on such work being done promptly. The one thing in the least
>>>> that can be done reasonably cheaply is making sure that every module in
>>>> ghc-internals to be annotated with {-# OPTIONS_HADDOCK hide #-} (so that
>>>> Haddock only generate documentation for the source but not for the module
>>>> interfaces).
>>>>
>>>> /Arnaud
>>>>
>>>> On Tue, 20 Jun 2023 at 09:03, Chris Dornan <chris at chrisdornan.com>
>>>> wrote:
>>>>
>>>>> Really, all LGTM!
>>>>>
>>>>> On 19 Jun 2023, at 22:10, Simon Peyton Jones <
>>>>> simon.peytonjones at gmail.com> wrote:
>>>>>
>>>>> Hello GHC steering committee,
>>>>>
>>>>> Any views about this?
>>>>>
>>>>> Simon
>>>>>
>>>>> On Thu, 15 Jun 2023 at 10:03, Simon Peyton Jones <
>>>>> simon.peytonjones at gmail.com> wrote:
>>>>>
>>>>>> Dear GHC Steering Committee
>>>>>>
>>>>>> Over the last few weeks, Ben Gamari and I have been discussing with
>>>>>> Andrew and Julian from the Core Libraries Committee how to make the Core
>>>>>> Libraries Committee and the GHC developers work together more fluidly; and
>>>>>> that includes the GHC Steering Committee.
>>>>>>
>>>>>> We now have a fairly well fleshed out proposal here.
>>>>>> <https://github.com/Ericson2314/tech-proposals/blob/ghc-base-libraries/proposals/accepted/050-ghc-base-libraries.rst>
>>>>>>
>>>>>> I hope you like it.  As far as this committee is concerned there are
>>>>>> two particular points of note
>>>>>>
>>>>>>    1. We propose a new package, *ghc-experimental*, which depends on
>>>>>>    *base*.  Many GHC proposals involve defining new types and
>>>>>>    functions.  The idea is that these would initially be in
>>>>>>    *ghc-experimental*.  After they stabilise and become widely
>>>>>>    adopted, the author (or anyone else) can make a CLC proposal to move them
>>>>>>    to *base*, which has much stronger stability guarantees.
>>>>>>    2. Section 5.1 suggests a mechanism to involve CLC members in
>>>>>>    proposals that involve new functions and types, at an earlier stage.  Some
>>>>>>    involve *changing *existing types and functions.  It is clearly
>>>>>>    unproductive for us to debate such things at length, and only *then
>>>>>>    *to land it on the CLC.
>>>>>>
>>>>>>    Section 5.1 also suggests that proposals should explicitly (in a
>>>>>>    separate section) call out
>>>>>>
>>>>>>
>>>>>>    - What new types and functions it defines
>>>>>>    - What existing types and functions are changed.
>>>>>>
>>>>>> We should add that to our template.
>>>>>>
>>>>>> At the moment we are just sharing the proposal with relevant
>>>>>> stakeholders (yourselves, CLC, stack folk, cabal folk etc), so that we can
>>>>>> polish any rough edges before making it public.
>>>>>>
>>>>>> So, any views?  Personally I think this is a Big Step Forward.
>>>>>>
>>>>>> Simon
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>> 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
>>>>>
>>>>
>>>>
>>>> --
>>>> Arnaud Spiwack
>>>> Director, Research at https://moduscreate.com and https://tweag.io.
>>>> _______________________________________________
>>>> 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/20230627/bb616eee/attachment-0001.html>

From moritz.angermann at gmail.com  Tue Jun 27 16:19:03 2023
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Tue, 27 Jun 2023 18:19:03 +0200
Subject: [ghc-steering-committee] Base library organisation
In-Reply-To: <CAJKmMz8rOGmAF6RmK+mDDf1ddNwyJexwA4dL+EEJRoHKLCq-aQ@mail.gmail.com>
References: <CAJKmMz-VCBsWarL-uDhS=vfNPOKecdnHfbxPTmwM9zP1cKYW1Q@mail.gmail.com>
 <CAJKmMz-vA38-QvWNdFQwPk0jyS9nkyYGk13AnBw8MADhNWwKaQ@mail.gmail.com>
 <EF2A7EFB-D998-4DAE-BF30-EA102535AC6C@chrisdornan.com>
 <CAGwnsnkjE+Wq4Y9SW7mWEDdfEKsKtBtj7epSQXfek7vF5N5nDQ@mail.gmail.com>
 <CAKfdd-xrY0WeY_Pn657keo4E37nEXM4Fqi6JgN8e6wcOJJvo6g@mail.gmail.com>
 <CAJKmMz8R8ZixNMGOGV7HtR48TQLuTQgugGmRR=D+bDhMvR_-2g@mail.gmail.com>
 <CAKfdd-x175kURqEXPZaaZ-_HDhxf8VNKq4Jhfvm9T3X+VNdDhA@mail.gmail.com>
 <CAJKmMz8rOGmAF6RmK+mDDf1ddNwyJexwA4dL+EEJRoHKLCq-aQ@mail.gmail.com>
Message-ID: <CAKfdd-xapr2rhiO+B4zDNvmVJqyPftVEQqsxax8s4MtKzek_Yw@mail.gmail.com>

> I think the question is: how do they "explicitly opt in"?  One
possibility is: they depend on ghc-internals in their .cabal file.  That's
explicit, and it's opting in.

The opt-in needs to explicitly more involved than the same as it is for any
other library. For regular libraries we want to make this as easy as
possible, we want
people to be able to focus on code, not on maintenance. I can see tools
supporting developers (similar to what Java has been doing for decades) in
offering them
to import a module when they type a symbol. (The most likely from the
inferred type the symbol would need to have). We kind of have a manual
version of this with
hoogle, and going the extra mile to also add the packge to the
build-depends in cabal.

None of this would be good for ghc-internals. Those symbols need to carry a
special tag to indicate their loose stability guarantees. Such that any
usesite can be
flagged, and tools could filter/warn on those flags.

Ultimately what we say is: this symbol/module/package has reduced/no
stability guarantees, use with caution. If you end up using this, and you
are _not_ GHC, please
ensure to petition the CLC for adding this to the stable standard
library (base, ...) interface.

We can see the same topic happening for other packages as well. I remember
the discussion around the .Internal module naming, all to _permit_ people
to use internals
_if_ they so need to, without having to resort to forking modules.

Then again, I think this is getting off the rails a bit here. I am as I
have indicate here and elsewhere fine with the proposal, I think it moves
us a notch in the right direction. We should have a separate proposal for
the INTERNAL marker I believe. But that's not a pre-requisite for this
proposal. We will just have to use as much social discouragement as we can
muster until we have a more technically enforceable solution.

On Tue, 27 Jun 2023 at 17:02, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> And I also want to strongly discourage people from using escape hatches
>> and rather motivate them to petition the CLC to extend base with a stable
>> interface for their needs.
>>
>
> I'll all for that!
>
> Therefore, I’d want ghc-internals to be flagged as INTERNAL, GHC itself be
>> built with -fpermit-internals, but everyone else having explicitly to opt
>> in to that (and for me an easy way to prohibit the use of any
>> non-whitelisted packages using -fpermit-internals).
>>
> I think the question is: how do they "explicitly opt in"?  One possibility
> is: they depend on ghc-internals in their .cabal file.  That's explicit,
> and it's opting in.
>
> There is some user interface design here, presumably involving cabal.
>
> Simon
>
> On Tue, 27 Jun 2023 at 15:43, Moritz Angermann <moritz.angermann at gmail.com>
> wrote:
>
>> I have strong reasons to discourage them. As a consumer of components
>> that can transitively depend on any of those, I must make sure none of my
>> dependencies depend on these internals (other than GHC itself). Any
>> component that depends on ghc-internals is not fit for use in projects I’d
>> be responsible for.
>>
>> I can not continue spending the obscene amounts we spend for compiler
>> upgrades.
>>
>> If someone in a leaf node depends to use internals I have no problem with
>> this. If this unintentionally slips into any library that I transitively
>> depend on, I have a problem. This needs to be *very* loud and explicit. I
>> would almost call it tainted that something depends on APIs that have no
>> stability guarantees.
>>
>> To illustrate this. Let’s assume we have a Haskell application which
>> depends on pkg A transitively though 10+ pkgs. pkg A-1.0 decides to depend
>> on GHC-internals. Next GHC comes around, breaks GHC-internals, pkg A is now
>> broken. pkg A’s master branch is at 3.0, and will now get the update and be
>> compatible with GHC-internals. What about 1.0? Touch luck. And now this
>> process ripples through 10+ layers of dependencies.
>>
>> Not only is this exceptionally expensive to adapt to. It also means there
>> is no sensible way to measure regressions of the application. The compiler
>> upgrade has now caused lots of code changes throughout the whole codebase
>> (including dependencies).
>>
>> Therefore, I’d want ghc-internals to be flagged as INTERNAL, GHC itself
>> be built with -fpermit-internals, but everyone else having explicitly to
>> opt in to that (and for me an easy way to prohibit the use of any
>> non-whitelisted packages using -fpermit-internals).
>>
>> We want to decouple a stable set of base base libraries from the GHC
>> internal libraries that have less rigorous stability guarantees, because
>> they are explicitly internal after all. However if we let this leak out too
>> easily we have forfeit significant benefits this could bring.
>>
>> As someone dealing with a massive codebase, how am I justifying spending
>> six figures to just make the code compatible with a new compiler and then
>> find out that I’m now facing performance regressions?!
>>
>> Thus form a practical point of view, I want to insulate my codebase as
>> much as possible from depending in any form on GHC-internals or other
>> libraries with a reduced stability guarantee.
>>
>> Depending on ghc-internals (or any such reduced stability library) should
>> come with high hurdles and excessive bells. (Which could be consciously
>> silenced by something like -fpermit-internals).
>>
>> On the other hand if this is too easy to do, we end up with lots of
>> libraries on hackage depending on GHC-internals, and breaking every release
>> cycle we’ve won nothing but only complicated things.
>>
>> Again, we don’t have the facilities for this today. But I would urge us
>> to get the asap.
>>
>> On a final note:
>> > If not, and if they have a need, and base doesn't have it, then they
>> may want to depend on ghc-internals temporarily and petition CLC to extend
>> base.
>>
>> I consider this a very slippery slope. We want the split to be explicit
>> and conscious not for people to end up depending on base and GHC-internal
>> because they just need something. It need to be _strongly_ discouraged to
>> do so, and it need to be more painful to use than petition the CLC to
>> extend base. Otherwise the incentives are aligned in a way that people do
>> not petition the CLC but just use GHC-internals.
>>
>> I do not want to prevent people from this. There are escape hatches. I
>> want to to be able to prevent any such software that uses those escape
>> hatches. And I also want to strongly discourage people from using escape
>> hatches and rather motivate them to petition the CLC to extend base with a
>> stable interface for their needs.
>>
>> Cheers,
>>  Moritz
>>
>> On Tue, 27 Jun 2023 at 4:10 PM, Simon Peyton Jones <
>> simon.peytonjones at gmail.com> wrote:
>>
>>> I don't think we want to flag *individual *bindings in ghc-internals;
>>> they are all there for a good, internal, non-deprecated reason.  What we
>>> want to discourage is for GHC clients to depend on *any module *in
>>> ghc-internals casually, without having a Strong Reason to do so. Why
>>> discourage?
>>>
>>>    - Everything they want should be in base.  And maybe it already
>>>    is!   If not, and if they have a need, and base doesn't have it, then they
>>>    may want to depend on ghc-internals temporarily and petition CLC to extend
>>>    base.
>>>    - If they casually depend on ghc-internals, they impose costs on
>>>    themselves (when we change the API) and on us (when they complain about us
>>>    changing the API).
>>>
>>> I have no strong opinion about want form "discourage" takes.  Certainly
>>> not "prevent".
>>>
>>> Simon
>>>
>>>
>>>
>>> On Tue, 27 Jun 2023 at 14:59, Moritz Angermann <
>>> moritz.angermann at gmail.com> wrote:
>>>
>>>> I have some concern around the discouraging concept as well.
>>>>
>>>> Ideally we had some marker INTERNAL like DEPRECATED, that could be
>>>> attached to individual bindings, complete modules or even packages. If this
>>>> existed, we could have code either error if it used any INTERNAL binding,
>>>> and no -fpermit-internals was provided. If this was attached to already
>>>> exposed bindings we’d want a warning phase for at least two releases which
>>>> I believe DEPRECATED could do?
>>>>
>>>> However, we don’t have this today, so I wouldn’t want this to block
>>>> this proposal from progressing.
>>>>
>>>> I’m not so much for hiding it. Reading up on it and knowing the details
>>>> (or even looking at the source) can be helpful at times. Making discovery
>>>> harder by hiding it would not be my preferred route.
>>>>
>>>> Cheers,
>>>>  Moritz
>>>>
>>>> On Tue, 27 Jun 2023 at 3:09 PM, Arnaud Spiwack <arnaud.spiwack at tweag.io>
>>>> wrote:
>>>>
>>>>> I don't have a strong opinion. I trust the people involved.
>>>>>
>>>>> The one thing I'll note is that the part about discouraging people
>>>>> from depending on ghc-internals seems to involve an awful lot of work. I
>>>>> wouldn't count on such work being done promptly. The one thing in the least
>>>>> that can be done reasonably cheaply is making sure that every module in
>>>>> ghc-internals to be annotated with {-# OPTIONS_HADDOCK hide #-} (so that
>>>>> Haddock only generate documentation for the source but not for the module
>>>>> interfaces).
>>>>>
>>>>> /Arnaud
>>>>>
>>>>> On Tue, 20 Jun 2023 at 09:03, Chris Dornan <chris at chrisdornan.com>
>>>>> wrote:
>>>>>
>>>>>> Really, all LGTM!
>>>>>>
>>>>>> On 19 Jun 2023, at 22:10, Simon Peyton Jones <
>>>>>> simon.peytonjones at gmail.com> wrote:
>>>>>>
>>>>>> Hello GHC steering committee,
>>>>>>
>>>>>> Any views about this?
>>>>>>
>>>>>> Simon
>>>>>>
>>>>>> On Thu, 15 Jun 2023 at 10:03, Simon Peyton Jones <
>>>>>> simon.peytonjones at gmail.com> wrote:
>>>>>>
>>>>>>> Dear GHC Steering Committee
>>>>>>>
>>>>>>> Over the last few weeks, Ben Gamari and I have been discussing with
>>>>>>> Andrew and Julian from the Core Libraries Committee how to make the Core
>>>>>>> Libraries Committee and the GHC developers work together more fluidly; and
>>>>>>> that includes the GHC Steering Committee.
>>>>>>>
>>>>>>> We now have a fairly well fleshed out proposal here.
>>>>>>> <https://github.com/Ericson2314/tech-proposals/blob/ghc-base-libraries/proposals/accepted/050-ghc-base-libraries.rst>
>>>>>>>
>>>>>>> I hope you like it.  As far as this committee is concerned there are
>>>>>>> two particular points of note
>>>>>>>
>>>>>>>    1. We propose a new package, *ghc-experimental*, which depends
>>>>>>>    on *base*.  Many GHC proposals involve defining new types and
>>>>>>>    functions.  The idea is that these would initially be in
>>>>>>>    *ghc-experimental*.  After they stabilise and become widely
>>>>>>>    adopted, the author (or anyone else) can make a CLC proposal to move them
>>>>>>>    to *base*, which has much stronger stability guarantees.
>>>>>>>    2. Section 5.1 suggests a mechanism to involve CLC members in
>>>>>>>    proposals that involve new functions and types, at an earlier stage.  Some
>>>>>>>    involve *changing *existing types and functions.  It is clearly
>>>>>>>    unproductive for us to debate such things at length, and only *then
>>>>>>>    *to land it on the CLC.
>>>>>>>
>>>>>>>    Section 5.1 also suggests that proposals should explicitly (in a
>>>>>>>    separate section) call out
>>>>>>>
>>>>>>>
>>>>>>>    - What new types and functions it defines
>>>>>>>    - What existing types and functions are changed.
>>>>>>>
>>>>>>> We should add that to our template.
>>>>>>>
>>>>>>> At the moment we are just sharing the proposal with relevant
>>>>>>> stakeholders (yourselves, CLC, stack folk, cabal folk etc), so that we can
>>>>>>> polish any rough edges before making it public.
>>>>>>>
>>>>>>> So, any views?  Personally I think this is a Big Step Forward.
>>>>>>>
>>>>>>> Simon
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>> 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
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Arnaud Spiwack
>>>>> Director, Research at https://moduscreate.com and https://tweag.io.
>>>>> _______________________________________________
>>>>> 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/20230627/90ad89ad/attachment-0001.html>

From moritz.angermann at gmail.com  Wed Jun 28 05:18:55 2023
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Wed, 28 Jun 2023 07:18:55 +0200
Subject: [ghc-steering-committee] Please consider GHC Proposal #575
	foracceptance.
In-Reply-To: <49adb594-dcaf-4a45-bfdc-0aa9eb686b1f@app.fastmail.com>
References: <CAKfdd-wVEKB2wuuym4OHax+S6Y8J4Zo5hN1k9Ai-uf4Wyg1+9Q@mail.gmail.com>
 <CAJKmMz9SNedZPc+9S+0HOgfunHDx2tsNQFnNhHwy9j7eic+b7g@mail.gmail.com>
 <CAGwnsnkEeNkTEOWydU2rCtTRFu3F5=7_6zNqOVLiZb9ZpSdVPA@mail.gmail.com>
 <49adb594-dcaf-4a45-bfdc-0aa9eb686b1f@app.fastmail.com>
Message-ID: <CAKfdd-x5CQ5iYeGZz-FTh0kM8OW--z=ROQ00RF248mowNczXig@mail.gmail.com>

Dear all,

I believe the remaining concerns have been addressed. Are there any further
concerns
regarding this proposal? Otherwise, I recommend we accept it.

Cheers,
 Moritz

On Wed, 7 Jun 2023 at 22:59, Eric Seidel <eric at seidel.io> wrote:

> Yes, to be clear I don't my concern as something to block on, it's a
> watch-out-for for library authors.
>
> On Tue, Jun 6, 2023, at 03:44, Arnaud Spiwack wrote:
> > I support acceptance as well.
> >
> > Eric's concern is a good point, but it probably shouldn't be an
> > obstacle to acceptance as 1/ the current proposal is still a clear
> > improvement on the situation 2/ it's unlikely that there is a
> > cost-effective way to improve on this axis.
> >
> > Adam complains about semantics in the Github thread [1]. Probably
> > something worth improving before merging.
> >
> > [1]:
> >
> https://github.com/ghc-proposals/ghc-proposals/pull/575#discussion_r1213653866
> >
> > On Wed, 24 May 2023 at 11:10, Simon Peyton Jones
> > <simon.peytonjones at gmail.com> wrote:
> >> I support acceptance, but I have asked a question about syntax.
> >>
> >> Simon
> >>
> >> On Fri, 19 May 2023 at 10:05, Moritz Angermann <
> moritz.angermann at gmail.com> wrote:
> >>> Dear Steering Committee,
> >>>
> >>> I strongly endorse GHC Proposal #575 <
> https://github.com/ghc-proposals/ghc-proposals/pull/575>, which suggests
> the introduction of deprecation pragmas on instances.
> >>>
> >>> The proposal is a logical extension of Haskell's existing deprecation
> facilities. Its implementation would fill a notable gap in the language's
> current deprecation capabilities.
> >>>
> >>> The lack of instance deprecation hinders controlled evolution of
> libraries and codebases, often leading to unexpected changes for users. By
> allowing instance deprecation, we can enhance the stability and
> predictability of Haskell codebases and improve the user experience.
> >>>
> >>> In summary, Proposal #575 represents a valuable improvement for
> Haskell. I urge the committee to give it favorable consideration.
> >>>
> >>> Best Regards, Moritz
> >>>
> >>> _______________________________________________
> >>> 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
> >
> >
> > --
> > Arnaud Spiwack
> > Director, Research at https://moduscreate.com and https://tweag.io.
> > _______________________________________________
> > 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/20230628/a3d66737/attachment.html>

From moritz.angermann at gmail.com  Wed Jun 28 05:27:55 2023
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Wed, 28 Jun 2023 07:27:55 +0200
Subject: [ghc-steering-committee] Please consider GHC Proposal #581 for
	acceptance.
Message-ID: <CAKfdd-xreE+-NQjqkPnbym4SFyba-qYbMxvE=ZUMxwbpnM+9tw@mail.gmail.com>

Dear Steering Committee,

Adam, Artyom and Chris wrote the Namespace-specified imports proposal
<https://github.com/ghc-proposals/ghc-proposals/pull/581>. It seeks to make
importing more impressive, allowing import statements to choose from the
type and data namespaces explicitly.

I believe this proposal adds value in expressiveness to import statements.
After the last syntax refinement comes naturally to the language. I
recommend acceptance of this proposal.

Best regards,
 Moritz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230628/a0ba2b67/attachment.html>

From adam at well-typed.com  Wed Jun 28 06:50:10 2023
From: adam at well-typed.com (Adam Gundry)
Date: Wed, 28 Jun 2023 07:50:10 +0100
Subject: [ghc-steering-committee] Please consider GHC Proposal #575
 foracceptance.
In-Reply-To: <CAKfdd-x5CQ5iYeGZz-FTh0kM8OW--z=ROQ00RF248mowNczXig@mail.gmail.com>
References: <CAKfdd-wVEKB2wuuym4OHax+S6Y8J4Zo5hN1k9Ai-uf4Wyg1+9Q@mail.gmail.com>
 <CAJKmMz9SNedZPc+9S+0HOgfunHDx2tsNQFnNhHwy9j7eic+b7g@mail.gmail.com>
 <CAGwnsnkEeNkTEOWydU2rCtTRFu3F5=7_6zNqOVLiZb9ZpSdVPA@mail.gmail.com>
 <49adb594-dcaf-4a45-bfdc-0aa9eb686b1f@app.fastmail.com>
 <CAKfdd-x5CQ5iYeGZz-FTh0kM8OW--z=ROQ00RF248mowNczXig@mail.gmail.com>
Message-ID: <be08d5de-1a01-7de0-494b-10ad2dd291d5@well-typed.com>

I'm in support, this is a nice improvement.

Cheers,

Adam


On 28/06/2023 06:18, Moritz Angermann wrote:
> Dear all,
> 
> I believe the remaining concerns have been addressed. Are there any 
> further concerns
> regarding this proposal? Otherwise, I recommend we accept it.
> 
> Cheers,
>   Moritz
> 
> On Wed, 7 Jun 2023 at 22:59, Eric Seidel <eric at seidel.io 
> <mailto:eric at seidel.io>> wrote:
> 
>     Yes, to be clear I don't my concern as something to block on, it's a
>     watch-out-for for library authors.
> 
>     On Tue, Jun 6, 2023, at 03:44, Arnaud Spiwack wrote:
>      > I support acceptance as well.
>      >
>      > Eric's concern is a good point, but it probably shouldn't be an
>      > obstacle to acceptance as 1/ the current proposal is still a clear
>      > improvement on the situation 2/ it's unlikely that there is a
>      > cost-effective way to improve on this axis.
>      >
>      > Adam complains about semantics in the Github thread [1]. Probably
>      > something worth improving before merging.
>      >
>      > [1]:
>      >
>     https://github.com/ghc-proposals/ghc-proposals/pull/575#discussion_r1213653866 <https://github.com/ghc-proposals/ghc-proposals/pull/575#discussion_r1213653866>
>      >
>      > On Wed, 24 May 2023 at 11:10, Simon Peyton Jones
>      > <simon.peytonjones at gmail.com
>     <mailto:simon.peytonjones at gmail.com>> wrote:
>      >> I support acceptance, but I have asked a question about syntax.
>      >>
>      >> Simon
>      >>
>      >> On Fri, 19 May 2023 at 10:05, Moritz Angermann
>     <moritz.angermann at gmail.com <mailto:moritz.angermann at gmail.com>> wrote:
>      >>> Dear Steering Committee,
>      >>>
>      >>> I strongly endorse GHC Proposal #575
>     <https://github.com/ghc-proposals/ghc-proposals/pull/575
>     <https://github.com/ghc-proposals/ghc-proposals/pull/575>>, which
>     suggests the introduction of deprecation pragmas on instances.
>      >>>
>      >>> The proposal is a logical extension of Haskell's existing
>     deprecation facilities. Its implementation would fill a notable gap
>     in the language's current deprecation capabilities.
>      >>>
>      >>> The lack of instance deprecation hinders controlled evolution
>     of libraries and codebases, often leading to unexpected changes for
>     users. By allowing instance deprecation, we can enhance the
>     stability and predictability of Haskell codebases and improve the
>     user experience.
>      >>>
>      >>> In summary, Proposal #575 represents a valuable improvement for
>     Haskell. I urge the committee to give it favorable consideration.
>      >>>
>      >>> Best Regards, Moritz

-- 
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 adam at well-typed.com  Wed Jun 28 07:06:38 2023
From: adam at well-typed.com (Adam Gundry)
Date: Wed, 28 Jun 2023 08:06:38 +0100
Subject: [ghc-steering-committee] Split -Wunused-imports (recommend
 accept)
In-Reply-To: <CAGwnsnn=sM+X8+V9pNPSGMsmb7EZ49=w5BTG9NCJs+XwQE+xRg@mail.gmail.com>
References: <E064DD1C-69A1-41F9-B56D-BB30ADC35E0B@chrisdornan.com>
 <b71417a6426514e3704d88f75d78d28344acd2c8.camel@joachim-breitner.de>
 <6AC42B82-A845-41CA-A59A-51158464A576@chrisdornan.com>
 <CAGwnsnn=sM+X8+V9pNPSGMsmb7EZ49=w5BTG9NCJs+XwQE+xRg@mail.gmail.com>
Message-ID: <b28fe041-93ad-b59f-d26e-d5107aa8d55e@well-typed.com>

I'm content to accept this proposal. Like Joachim, my sense is that 
"relaxed redundant imports" would be worth exploring further; moreover 
the proposal's definitions of "unused" and "duplicate" are essentially 
specified only by GHC's implementation. But this proposal is a 
beneficial change and we can always further refine the warning flags in 
the future.

Cheers,

Adam


On 27/06/2023 13:39, Arnaud Spiwack wrote:
> The problem statement, as I understand it:
> 
> I'm writing a library, with dependency L-1 from where I import X and 
> Y(f). A new version L-2 is released, where X exports (f) as well.
> My CI is set to reject all warnings, and start complaining on L-2. 
> Silencing the warning on L-2 requires some rather gratuitous contortion 
> (import X hiding (f)) just to be able to compile with L-1! (even if we 
> don't require L-1 to compile without warning).
> 
> I'm not really fond of the idea of removing this type of duplicate 
> import warning from -wall, to be honest. But I do agree that we 
> shouldn't have to contort the code that way if the libraries are 
> otherwise completely compatible. The fact that it's easy, by merely 
> silencing a warning on imports to break compatibility with a previous 
> version is not something to be proud of.
> 
> Therefore *I'm in favour* of this proposal (albeit reluctantly).
> 
> Oleg Grengrus's comment on the discussion thread makes me think that 
> maybe there should be two different recommended sets of warnings: one 
> for libraries (where compatibility with several versions of a dependency 
> is desirable), and one for applications (where you are typically bound 
> to a single version of your dependencies). Though it's probably too much 
> overhead for a single warning difference between the two.
> 
> On Fri, 16 Jun 2023 at 16:05, Chris Dornan <chris at chrisdornan.com 
> <mailto:chris at chrisdornan.com>> wrote:
> 
>     Just for the record, I am also open to refinement of the
>     import-warning toolbox in future but I think this proposal is the
>     best next step.
> 
>     Given how straightforward the proposition is, how about we set a
>     week for objections to be raised and move to accept the proposal if
>     none are forthcoming (by Saturday, 2023-06-24).
> 
>     Chris
> 
>      > On 16 Jun 2023, at 13:33, Joachim Breitner
>     <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
>      >
>      > Hi,
>      >
>      > this proposal highlights a fundamental tension with compiler
>     warnings.
>      >
>      > If you assume a never changing background of dependencies, then the
>      > current behavior isn’t too bad: GHC correctly tell you that you can
>      > remove a line of code, and that is a good thing. I don’t think that
>      > this is directly what is bothering developers.
>      >
>      > But dependencies do change, and exports get moved around, and
>     code that
>      > wasn’t warning before suddenly warns. And that is what’s annoying!
>      >
>      > So there is a tension between “given the current assumptions,
>     your code
>      > can be improved” vs. “assumptions change”.
>      >
>      > I agree that at least in this case (and probably in general) we want
>      > the -Wall warnings to be reasonably insensitive to dependency
>     changes,
>      > so that good code stays “good”. Of course this is not a hard rule –
>      > think of deprecation warnings, but a decent guideline.
>      >
>      > Therefore in favor.
>      >
>      >
>      > The proposal mentions as alternative “Relaxed redundant imports”,
>     which
>      > refines the warnings a bit more. In that alternative, an _duplicate
>      > explicit import_ is cause for a warning; in Chris’ example that would
>      > be
>      >
>      >   import X (f) -- exports some function @f@
>      >   import y (f) -- exports the same function @f@
>      >   g = f
>      >
>      > Under the current proposal, this would no longer warn with -Wall,
>     but I
>      > think it’s silly to not warn here, as even with changing
>     dependencies,
>      > this is a code smell. I sympathize with the author’s wish to not make
>      > this more complicated than necessary to achieve the goal (warnings
>      > about duplicate _implicit_ imports causing headcaches), but would
>     like
>      > to keep the door open for someone who wants to implement the refined
>      > version in the future. That would probably entail a
>      >  -Wduplicate-explicit-import
>      > flag which can then live in -Wall, but is still compatible with this
>      > proposal, so all izz well.
>      >
>      >
>      >
>      > Adam points out (as quoted in the proposal) that users of
>      >   -Weverything -Wno-unused-imports
>      > might see new breakage. I don’t think someone using -Weverything can
>      > expect any kind of stability, else we paint ourselves into a
>     corner (or
>      > start introducing -Wreally-everything, -Wreally-really-everything, …)
>      >
>      >
>      > Cheers,
>      > Joachim
>      >
>      >
>      >
>      >
>      > Am Donnerstag, dem 15.06.2023 um 16:50 +0100 schrieb Chris Dornan:
>      >> Dear Committee,
>      >>
>      >> Georgi Lyubenov has a simple proposal to improve the quality of
>     life for many package maintainers that I recommend that we accept.
>      >>
>      >> ## Split -Wunused-imports
>      >>
>      >> Rendered proposal:
>     <https://github.com/googleson78/ghc-proposals/blob/split-unused-imports/proposals/0000-split-wunused-imports.md <https://github.com/googleson78/ghc-proposals/blob/split-unused-imports/proposals/0000-split-wunused-imports.md>>
>      >> Discussion of proposal:
>     <https://github.com/ghc-proposals/ghc-proposals/pull/586
>     <https://github.com/ghc-proposals/ghc-proposals/pull/586>>
>      >>
>      >> ### Summary
>      >>
>      >> (Straight from the proposal.)
>      >>
>      >> We propose to split the -Wunused-imports warning into two parts:
>      >>
>      >> - warn on actual unused imports
>      >> - warn on duplicate imports
>      >>
>      >> while also not including the second in -Wall. This will greatly
>     reduce "churn" for library authors.
>      >>
>      >>
>      >> ## In more Detail
>      >>
>      >> As we know, many Haskell developers, including significant
>     commercial projects, incorporate -Wall
>      >> -Werror into their workflow at some stage. To this end it is
>     important that we minimise 'false
>      >> negatives', whereby the compiler emits 'frivolous' warnings.
>      >>
>      >> This proposal identifies an important class of -Wall warnings
>     that many package maintainers
>      >> appear to regard quite bothersome, namely when the compiler
>     warns that import statement is
>      >> superflous even when it is importing an entity that is being
>     used by the module. The issue is
>      >> the way `-Wunused-imports` works, which will issue a warning for
>     the following program.
>      >>
>      >> ```haskell
>      >> import X -- exports some function @f@
>      >> import y -- exports the same function @f@
>      >>
>      >> g = f
>      >> ```
>      >>
>      >> The compiler will warn that the second Y import is redundant.
>      >>
>      >> Many developers do not want to be warned about this. As far as
>     they are concerned each import is
>      >> yielding enties that are in use and the fact that one of them
>     can be removed is just not
>      >> interesting.
>      >>
>      >> In contrast, developers that use -Wall do want to be warned
>     about the following.
>      >>
>      >> ```haskell
>      >> import X -- exports some function @f@
>      >> import Z -- does not export f
>      >>
>      >> g = f
>      >> ```
>      >>
>      >> Here our module has a completely false dependency on Z which
>     should be cleaned up at the point that
>      >> warnings are cleaned up.
>      >>
>      >> This proposal proposes modifying -Wunused-imports so that it
>     will warn about the second example but
>      >> stay silent for the first, and adds a -Wduplicate-imports that
>     will issue a warning for the the
>      >> first example. In effect the enabling of both warnings in the
>     new proposal will restore the current
>      >> -Wunused-imports behaviour. -Wall should *not* enable
>     -Wduplicate-imports but is avilable to those
>      >> developers that rely on the current behaviour of
>     -Wunused-imports (which some clearly do).
>      >>
>      >>
>      >> ## Recommendation
>      >>
>      >> I recommend that we accept this proposal.

-- 
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 simon.peytonjones at gmail.com  Wed Jun 28 07:14:27 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Wed, 28 Jun 2023 08:14:27 +0100
Subject: [ghc-steering-committee] Please consider GHC Proposal #575
	foracceptance.
In-Reply-To: <CAKfdd-x5CQ5iYeGZz-FTh0kM8OW--z=ROQ00RF248mowNczXig@mail.gmail.com>
References: <CAKfdd-wVEKB2wuuym4OHax+S6Y8J4Zo5hN1k9Ai-uf4Wyg1+9Q@mail.gmail.com>
 <CAJKmMz9SNedZPc+9S+0HOgfunHDx2tsNQFnNhHwy9j7eic+b7g@mail.gmail.com>
 <CAGwnsnkEeNkTEOWydU2rCtTRFu3F5=7_6zNqOVLiZb9ZpSdVPA@mail.gmail.com>
 <49adb594-dcaf-4a45-bfdc-0aa9eb686b1f@app.fastmail.com>
 <CAKfdd-x5CQ5iYeGZz-FTh0kM8OW--z=ROQ00RF248mowNczXig@mail.gmail.com>
Message-ID: <CAJKmMz-EdmkeP1cax4Ga3gCosvL-XC6Xt7nFNBzqg0gJ0tuw=w@mail.gmail.com>

I'm happy to accept.

I think I would gone a little further, and allowed the pragmas to appear in
either order (DEPRECATED then OVERLAPPABLE or OVERLAPPABLE then
DEPRECATED), but the proposal allows on the former.

But it's a matter of taste and I'm OK with the choice.

Simon

On Wed, 28 Jun 2023 at 06:19, Moritz Angermann <moritz.angermann at gmail.com>
wrote:

> Dear all,
>
> I believe the remaining concerns have been addressed. Are there any
> further concerns
> regarding this proposal? Otherwise, I recommend we accept it.
>
> Cheers,
>  Moritz
>
> On Wed, 7 Jun 2023 at 22:59, Eric Seidel <eric at seidel.io> wrote:
>
>> Yes, to be clear I don't my concern as something to block on, it's a
>> watch-out-for for library authors.
>>
>> On Tue, Jun 6, 2023, at 03:44, Arnaud Spiwack wrote:
>> > I support acceptance as well.
>> >
>> > Eric's concern is a good point, but it probably shouldn't be an
>> > obstacle to acceptance as 1/ the current proposal is still a clear
>> > improvement on the situation 2/ it's unlikely that there is a
>> > cost-effective way to improve on this axis.
>> >
>> > Adam complains about semantics in the Github thread [1]. Probably
>> > something worth improving before merging.
>> >
>> > [1]:
>> >
>> https://github.com/ghc-proposals/ghc-proposals/pull/575#discussion_r1213653866
>> >
>> > On Wed, 24 May 2023 at 11:10, Simon Peyton Jones
>> > <simon.peytonjones at gmail.com> wrote:
>> >> I support acceptance, but I have asked a question about syntax.
>> >>
>> >> Simon
>> >>
>> >> On Fri, 19 May 2023 at 10:05, Moritz Angermann <
>> moritz.angermann at gmail.com> wrote:
>> >>> Dear Steering Committee,
>> >>>
>> >>> I strongly endorse GHC Proposal #575 <
>> https://github.com/ghc-proposals/ghc-proposals/pull/575>, which suggests
>> the introduction of deprecation pragmas on instances.
>> >>>
>> >>> The proposal is a logical extension of Haskell's existing deprecation
>> facilities. Its implementation would fill a notable gap in the language's
>> current deprecation capabilities.
>> >>>
>> >>> The lack of instance deprecation hinders controlled evolution of
>> libraries and codebases, often leading to unexpected changes for users. By
>> allowing instance deprecation, we can enhance the stability and
>> predictability of Haskell codebases and improve the user experience.
>> >>>
>> >>> In summary, Proposal #575 represents a valuable improvement for
>> Haskell. I urge the committee to give it favorable consideration.
>> >>>
>> >>> Best Regards, Moritz
>> >>>
>> >>> _______________________________________________
>> >>> 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
>> >
>> >
>> > --
>> > Arnaud Spiwack
>> > Director, Research at https://moduscreate.com and https://tweag.io.
>> > _______________________________________________
>> > 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/20230628/aaf006ef/attachment.html>

From vlad.z.4096 at gmail.com  Wed Jun 28 07:18:57 2023
From: vlad.z.4096 at gmail.com (Vladislav)
Date: Wed, 28 Jun 2023 09:18:57 +0200
Subject: [ghc-steering-committee] Please consider GHC Proposal #581 for
 acceptance.
In-Reply-To: <CAKfdd-xreE+-NQjqkPnbym4SFyba-qYbMxvE=ZUMxwbpnM+9tw@mail.gmail.com>
References: <CAKfdd-xreE+-NQjqkPnbym4SFyba-qYbMxvE=ZUMxwbpnM+9tw@mail.gmail.com>
Message-ID: <LBCYWR.ITCRNEY2CF1V@gmail.com>

The proposed change allows us to fix a bug in ExplicitNamespaces 
(GitLab ticket #22581) and on top of that offers a reasonable way to 
manage punned imports in DH code (i.e. it plays nicely with our 
accepted GHC Proposal #378).

Strong +1 from me.

Vlad

On mer., juin 28 2023 at 07:27:55 +02:00:00, Moritz Angermann 
<moritz.angermann at gmail.com> wrote:
> Dear Steering Committee,
> 
> Adam, Artyom and Chris wrote the Namespace-specified imports proposal 
> <https://github.com/ghc-proposals/ghc-proposals/pull/581>. It seeks 
> to make importing more impressive, allowing import statements to 
> choose from the type and data namespaces explicitly.
> 
> I believe this proposal adds value in expressiveness to import 
> statements. After the last syntax refinement comes naturally to the 
> language. I recommend acceptance of this proposal.
> 
> Best regards,
>  Moritz

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

From adam at well-typed.com  Wed Jun 28 07:24:04 2023
From: adam at well-typed.com (Adam Gundry)
Date: Wed, 28 Jun 2023 08:24:04 +0100
Subject: [ghc-steering-committee] Please consider GHC Proposal #581 for
 acceptance.
In-Reply-To: <LBCYWR.ITCRNEY2CF1V@gmail.com>
References: <CAKfdd-xreE+-NQjqkPnbym4SFyba-qYbMxvE=ZUMxwbpnM+9tw@mail.gmail.com>
 <LBCYWR.ITCRNEY2CF1V@gmail.com>
Message-ID: <d15c5b38-8637-073e-701c-bfb7fd31af2e@well-typed.com>

Unsurprisingly, I'm in support too. Most of the credit should really go 
to Artyom and Vlad, because this proposal is really a distilling of the 
extension changes from #270 after I caused trouble in getting that 
accepted as it stood. :-)

Adam


On 28/06/2023 08:18, Vladislav wrote:
> The proposed change allows us to fix a bug in ExplicitNamespaces (GitLab 
> ticket #22581) and on top of that offers a reasonable way to manage 
> punned imports in DH code (i.e. it plays nicely with our accepted GHC 
> Proposal #378).
> 
> Strong +1 from me.
> 
> Vlad
> 
> On mer., juin 28 2023 at 07:27:55 +02:00:00, Moritz Angermann 
> <moritz.angermann at gmail.com> wrote:
>> Dear Steering Committee,
>>
>> Adam, Artyom and Chris wrote the Namespace-specified imports proposal 
>> <https://github.com/ghc-proposals/ghc-proposals/pull/581>. It seeks to 
>> make importing more impressive, allowing import statements to choose 
>> from the type and data namespaces explicitly.
>>
>> I believe this proposal adds value in expressiveness to import 
>> statements. After the last syntax refinement comes naturally to the 
>> language. I recommend acceptance of this proposal.
>>
>> Best regards,
>>  Moritz


-- 
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 simon.peytonjones at gmail.com  Wed Jun 28 07:24:14 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Wed, 28 Jun 2023 08:24:14 +0100
Subject: [ghc-steering-committee] Please consider GHC Proposal #581 for
	acceptance.
In-Reply-To: <CAKfdd-xreE+-NQjqkPnbym4SFyba-qYbMxvE=ZUMxwbpnM+9tw@mail.gmail.com>
References: <CAKfdd-xreE+-NQjqkPnbym4SFyba-qYbMxvE=ZUMxwbpnM+9tw@mail.gmail.com>
Message-ID: <CAJKmMz_p9w8hbRxVU4iO9eJuAwi+BjMuvCiMMV0VGJ2UjXVMuw@mail.gmail.com>

I support this.  Well written proposal

Simon

On Wed, 28 Jun 2023 at 06:28, Moritz Angermann <moritz.angermann at gmail.com>
wrote:

> Dear Steering Committee,
>
> Adam, Artyom and Chris wrote the Namespace-specified imports proposal
> <https://github.com/ghc-proposals/ghc-proposals/pull/581>. It seeks to
> make importing more impressive, allowing import statements to choose from
> the type and data namespaces explicitly.
>
> I believe this proposal adds value in expressiveness to import statements.
> After the last syntax refinement comes naturally to the language. I
> recommend acceptance of this proposal.
>
> Best regards,
>  Moritz
> _______________________________________________
> 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/20230628/edf5ef10/attachment-0001.html>

From arnaud.spiwack at tweag.io  Wed Jun 28 12:48:55 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Wed, 28 Jun 2023 14:48:55 +0200
Subject: [ghc-steering-committee] Please consider GHC Proposal #581 for
	acceptance.
In-Reply-To: <CAJKmMz_p9w8hbRxVU4iO9eJuAwi+BjMuvCiMMV0VGJ2UjXVMuw@mail.gmail.com>
References: <CAKfdd-xreE+-NQjqkPnbym4SFyba-qYbMxvE=ZUMxwbpnM+9tw@mail.gmail.com>
 <CAJKmMz_p9w8hbRxVU4iO9eJuAwi+BjMuvCiMMV0VGJ2UjXVMuw@mail.gmail.com>
Message-ID: <CAGwnsn=GvjFAC3-t_QGHG5JixmFVRi2mvH1eAF0UW43_N1oHhg@mail.gmail.com>

This all sounds reasonable. In favour.

On Wed, 28 Jun 2023 at 09:24, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> I support this.  Well written proposal
>
> Simon
>
> On Wed, 28 Jun 2023 at 06:28, Moritz Angermann <moritz.angermann at gmail.com>
> wrote:
>
>> Dear Steering Committee,
>>
>> Adam, Artyom and Chris wrote the Namespace-specified imports proposal
>> <https://github.com/ghc-proposals/ghc-proposals/pull/581>. It seeks to
>> make importing more impressive, allowing import statements to choose from
>> the type and data namespaces explicitly.
>>
>> I believe this proposal adds value in expressiveness to import
>> statements. After the last syntax refinement comes naturally to the
>> language. I recommend acceptance of this proposal.
>>
>> Best regards,
>>  Moritz
>> _______________________________________________
>> 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
>


-- 
Arnaud Spiwack
Director, Research at https://moduscreate.com and https://tweag.io.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230628/cab9dba6/attachment.html>

From chris at chrisdornan.com  Wed Jun 28 15:07:21 2023
From: chris at chrisdornan.com (Chris Dornan)
Date: Wed, 28 Jun 2023 16:07:21 +0100
Subject: [ghc-steering-committee] Please consider GHC Proposal #581 for
 acceptance.
In-Reply-To: <CAGwnsn=GvjFAC3-t_QGHG5JixmFVRi2mvH1eAF0UW43_N1oHhg@mail.gmail.com>
References: <CAKfdd-xreE+-NQjqkPnbym4SFyba-qYbMxvE=ZUMxwbpnM+9tw@mail.gmail.com>
 <CAJKmMz_p9w8hbRxVU4iO9eJuAwi+BjMuvCiMMV0VGJ2UjXVMuw@mail.gmail.com>
 <CAGwnsn=GvjFAC3-t_QGHG5JixmFVRi2mvH1eAF0UW43_N1oHhg@mail.gmail.com>
Message-ID: <FD37D4C1-8948-429D-9839-1DBF51C0CF41@chrisdornan.com>

+1 from me.

> On 28 Jun 2023, at 13:48, Arnaud Spiwack <arnaud.spiwack at tweag.io> wrote:
> 
> This all sounds reasonable. In favour. 
> 
> On Wed, 28 Jun 2023 at 09:24, Simon Peyton Jones <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>> wrote:
>> I support this.  Well written proposal
>> 
>> Simon
>> 
>> On Wed, 28 Jun 2023 at 06:28, Moritz Angermann <moritz.angermann at gmail.com <mailto:moritz.angermann at gmail.com>> wrote:
>>> Dear Steering Committee,
>>> 
>>> Adam, Artyom and Chris wrote the Namespace-specified imports proposal <https://github.com/ghc-proposals/ghc-proposals/pull/581>. It seeks to make importing more impressive, allowing import statements to choose from the type and data namespaces explicitly.
>>> 
>>> I believe this proposal adds value in expressiveness to import statements. After the last syntax refinement comes naturally to the language. I recommend acceptance of this proposal.
>>> 
>>> Best regards,
>>>  Moritz
>>> _______________________________________________
>>> 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
> 
> 
> -- 
> Arnaud Spiwack
> Director, Research at https://moduscreate.com <https://moduscreate.com/> and https://tweag.io <https://tweag.io/>.
> _______________________________________________
> 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/20230628/fe2b177c/attachment.html>

From chris at chrisdornan.com  Wed Jun 28 15:20:04 2023
From: chris at chrisdornan.com (Chris Dornan)
Date: Wed, 28 Jun 2023 16:20:04 +0100
Subject: [ghc-steering-committee] Split -Wunused-imports (recommend
 accept)
In-Reply-To: <b28fe041-93ad-b59f-d26e-d5107aa8d55e@well-typed.com>
References: <E064DD1C-69A1-41F9-B56D-BB30ADC35E0B@chrisdornan.com>
 <b71417a6426514e3704d88f75d78d28344acd2c8.camel@joachim-breitner.de>
 <6AC42B82-A845-41CA-A59A-51158464A576@chrisdornan.com>
 <CAGwnsnn=sM+X8+V9pNPSGMsmb7EZ49=w5BTG9NCJs+XwQE+xRg@mail.gmail.com>
 <b28fe041-93ad-b59f-d26e-d5107aa8d55e@well-typed.com>
Message-ID: <333725FC-2473-4666-B87A-08DBA8FB8A98@chrisdornan.com>

Joachim and everyone,

It looks like we are accepting this proposal -- I have changed the label to accepted on the repo. If anybody objects please speak up!

Chris


> On 28 Jun 2023, at 08:06, Adam Gundry <adam at well-typed.com> wrote:
> 
> I'm content to accept this proposal. Like Joachim, my sense is that "relaxed redundant imports" would be worth exploring further; moreover the proposal's definitions of "unused" and "duplicate" are essentially specified only by GHC's implementation. But this proposal is a beneficial change and we can always further refine the warning flags in the future.
> 
> Cheers,
> 
> Adam
> 
> 
> On 27/06/2023 13:39, Arnaud Spiwack wrote:
>> The problem statement, as I understand it:
>> I'm writing a library, with dependency L-1 from where I import X and Y(f). A new version L-2 is released, where X exports (f) as well.
>> My CI is set to reject all warnings, and start complaining on L-2. Silencing the warning on L-2 requires some rather gratuitous contortion (import X hiding (f)) just to be able to compile with L-1! (even if we don't require L-1 to compile without warning).
>> I'm not really fond of the idea of removing this type of duplicate import warning from -wall, to be honest. But I do agree that we shouldn't have to contort the code that way if the libraries are otherwise completely compatible. The fact that it's easy, by merely silencing a warning on imports to break compatibility with a previous version is not something to be proud of.
>> Therefore *I'm in favour* of this proposal (albeit reluctantly).
>> Oleg Grengrus's comment on the discussion thread makes me think that maybe there should be two different recommended sets of warnings: one for libraries (where compatibility with several versions of a dependency is desirable), and one for applications (where you are typically bound to a single version of your dependencies). Though it's probably too much overhead for a single warning difference between the two.
>> On Fri, 16 Jun 2023 at 16:05, Chris Dornan <chris at chrisdornan.com <mailto:chris at chrisdornan.com>> wrote:
>>    Just for the record, I am also open to refinement of the
>>    import-warning toolbox in future but I think this proposal is the
>>    best next step.
>>    Given how straightforward the proposition is, how about we set a
>>    week for objections to be raised and move to accept the proposal if
>>    none are forthcoming (by Saturday, 2023-06-24).
>>    Chris
>>     > On 16 Jun 2023, at 13:33, Joachim Breitner
>>    <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
>>     >
>>     > Hi,
>>     >
>>     > this proposal highlights a fundamental tension with compiler
>>    warnings.
>>     >
>>     > If you assume a never changing background of dependencies, then the
>>     > current behavior isn’t too bad: GHC correctly tell you that you can
>>     > remove a line of code, and that is a good thing. I don’t think that
>>     > this is directly what is bothering developers.
>>     >
>>     > But dependencies do change, and exports get moved around, and
>>    code that
>>     > wasn’t warning before suddenly warns. And that is what’s annoying!
>>     >
>>     > So there is a tension between “given the current assumptions,
>>    your code
>>     > can be improved” vs. “assumptions change”.
>>     >
>>     > I agree that at least in this case (and probably in general) we want
>>     > the -Wall warnings to be reasonably insensitive to dependency
>>    changes,
>>     > so that good code stays “good”. Of course this is not a hard rule –
>>     > think of deprecation warnings, but a decent guideline.
>>     >
>>     > Therefore in favor.
>>     >
>>     >
>>     > The proposal mentions as alternative “Relaxed redundant imports”,
>>    which
>>     > refines the warnings a bit more. In that alternative, an _duplicate
>>     > explicit import_ is cause for a warning; in Chris’ example that would
>>     > be
>>     >
>>     >   import X (f) -- exports some function @f@
>>     >   import y (f) -- exports the same function @f@
>>     >   g = f
>>     >
>>     > Under the current proposal, this would no longer warn with -Wall,
>>    but I
>>     > think it’s silly to not warn here, as even with changing
>>    dependencies,
>>     > this is a code smell. I sympathize with the author’s wish to not make
>>     > this more complicated than necessary to achieve the goal (warnings
>>     > about duplicate _implicit_ imports causing headcaches), but would
>>    like
>>     > to keep the door open for someone who wants to implement the refined
>>     > version in the future. That would probably entail a
>>     >  -Wduplicate-explicit-import
>>     > flag which can then live in -Wall, but is still compatible with this
>>     > proposal, so all izz well.
>>     >
>>     >
>>     >
>>     > Adam points out (as quoted in the proposal) that users of
>>     >   -Weverything -Wno-unused-imports
>>     > might see new breakage. I don’t think someone using -Weverything can
>>     > expect any kind of stability, else we paint ourselves into a
>>    corner (or
>>     > start introducing -Wreally-everything, -Wreally-really-everything, …)
>>     >
>>     >
>>     > Cheers,
>>     > Joachim
>>     >
>>     >
>>     >
>>     >
>>     > Am Donnerstag, dem 15.06.2023 um 16:50 +0100 schrieb Chris Dornan:
>>     >> Dear Committee,
>>     >>
>>     >> Georgi Lyubenov has a simple proposal to improve the quality of
>>    life for many package maintainers that I recommend that we accept.
>>     >>
>>     >> ## Split -Wunused-imports
>>     >>
>>     >> Rendered proposal:
>>    <https://github.com/googleson78/ghc-proposals/blob/split-unused-imports/proposals/0000-split-wunused-imports.md <https://github.com/googleson78/ghc-proposals/blob/split-unused-imports/proposals/0000-split-wunused-imports.md>>
>>     >> Discussion of proposal:
>>    <https://github.com/ghc-proposals/ghc-proposals/pull/586
>>    <https://github.com/ghc-proposals/ghc-proposals/pull/586>>
>>     >>
>>     >> ### Summary
>>     >>
>>     >> (Straight from the proposal.)
>>     >>
>>     >> We propose to split the -Wunused-imports warning into two parts:
>>     >>
>>     >> - warn on actual unused imports
>>     >> - warn on duplicate imports
>>     >>
>>     >> while also not including the second in -Wall. This will greatly
>>    reduce "churn" for library authors.
>>     >>
>>     >>
>>     >> ## In more Detail
>>     >>
>>     >> As we know, many Haskell developers, including significant
>>    commercial projects, incorporate -Wall
>>     >> -Werror into their workflow at some stage. To this end it is
>>    important that we minimise 'false
>>     >> negatives', whereby the compiler emits 'frivolous' warnings.
>>     >>
>>     >> This proposal identifies an important class of -Wall warnings
>>    that many package maintainers
>>     >> appear to regard quite bothersome, namely when the compiler
>>    warns that import statement is
>>     >> superflous even when it is importing an entity that is being
>>    used by the module. The issue is
>>     >> the way `-Wunused-imports` works, which will issue a warning for
>>    the following program.
>>     >>
>>     >> ```haskell
>>     >> import X -- exports some function @f@
>>     >> import y -- exports the same function @f@
>>     >>
>>     >> g = f
>>     >> ```
>>     >>
>>     >> The compiler will warn that the second Y import is redundant.
>>     >>
>>     >> Many developers do not want to be warned about this. As far as
>>    they are concerned each import is
>>     >> yielding enties that are in use and the fact that one of them
>>    can be removed is just not
>>     >> interesting.
>>     >>
>>     >> In contrast, developers that use -Wall do want to be warned
>>    about the following.
>>     >>
>>     >> ```haskell
>>     >> import X -- exports some function @f@
>>     >> import Z -- does not export f
>>     >>
>>     >> g = f
>>     >> ```
>>     >>
>>     >> Here our module has a completely false dependency on Z which
>>    should be cleaned up at the point that
>>     >> warnings are cleaned up.
>>     >>
>>     >> This proposal proposes modifying -Wunused-imports so that it
>>    will warn about the second example but
>>     >> stay silent for the first, and adds a -Wduplicate-imports that
>>    will issue a warning for the the
>>     >> first example. In effect the enabling of both warnings in the
>>    new proposal will restore the current
>>     >> -Wunused-imports behaviour. -Wall should *not* enable
>>    -Wduplicate-imports but is avilable to those
>>     >> developers that rely on the current behaviour of
>>    -Wunused-imports (which some clearly do).
>>     >>
>>     >>
>>     >> ## Recommendation
>>     >>
>>     >> I recommend that we accept this proposal.
> 
> -- 
> 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 mail at joachim-breitner.de  Wed Jun 28 19:42:57 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 28 Jun 2023 21:42:57 +0200
Subject: [ghc-steering-committee] Split -Wunused-imports (recommend
 accept)
In-Reply-To: <333725FC-2473-4666-B87A-08DBA8FB8A98@chrisdornan.com>
References: <E064DD1C-69A1-41F9-B56D-BB30ADC35E0B@chrisdornan.com>
 <b71417a6426514e3704d88f75d78d28344acd2c8.camel@joachim-breitner.de>
 <6AC42B82-A845-41CA-A59A-51158464A576@chrisdornan.com>
 <CAGwnsnn=sM+X8+V9pNPSGMsmb7EZ49=w5BTG9NCJs+XwQE+xRg@mail.gmail.com>
 <b28fe041-93ad-b59f-d26e-d5107aa8d55e@well-typed.com>
 <333725FC-2473-4666-B87A-08DBA8FB8A98@chrisdornan.com>
Message-ID: <f57d1c10a890b2aa59b83399f66b0cbd980c9fb8.camel@joachim-breitner.de>

Hi,

Am Mittwoch, dem 28.06.2023 um 16:20 +0100 schrieb Chris Dornan:
> It looks like we are accepting this proposal -- I have changed the label to accepted on the repo. If anybody objects please speak up!

thanks, merged


Cheers,
Joachim

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


From mail at joachim-breitner.de  Wed Jun 28 19:44:34 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 28 Jun 2023 21:44:34 +0200
Subject: [ghc-steering-committee] Please consider GHC Proposal #575
 foracceptance.
In-Reply-To: <CAKfdd-x5CQ5iYeGZz-FTh0kM8OW--z=ROQ00RF248mowNczXig@mail.gmail.com>
References: <CAKfdd-wVEKB2wuuym4OHax+S6Y8J4Zo5hN1k9Ai-uf4Wyg1+9Q@mail.gmail.com>
 <CAJKmMz9SNedZPc+9S+0HOgfunHDx2tsNQFnNhHwy9j7eic+b7g@mail.gmail.com>
 <CAGwnsnkEeNkTEOWydU2rCtTRFu3F5=7_6zNqOVLiZb9ZpSdVPA@mail.gmail.com>
 <49adb594-dcaf-4a45-bfdc-0aa9eb686b1f@app.fastmail.com>
 <CAKfdd-x5CQ5iYeGZz-FTh0kM8OW--z=ROQ00RF248mowNczXig@mail.gmail.com>
Message-ID: <f6305f47911914b3fd1d2e48faef49aa0c3fde1b.camel@joachim-breitner.de>

Hi, 

with plenty of supporting voices and no dissent, this is accepted. Will
merge.

Cheers,
Joachim

Am Mittwoch, dem 28.06.2023 um 07:18 +0200 schrieb Moritz Angermann:
> Dear all,
> 
> I believe the remaining concerns have been addressed. Are there any
> further concerns
> regarding this proposal? Otherwise, I recommend we accept it.
> 
> Cheers,
>  Moritz
> 
> On Wed, 7 Jun 2023 at 22:59, Eric Seidel <eric at seidel.io> wrote:
> > Yes, to be clear I don't my concern as something to block on, it's
> > a watch-out-for for library authors.
> > 
> > On Tue, Jun 6, 2023, at 03:44, Arnaud Spiwack wrote:
> > > I support acceptance as well.
> > > 
> > > Eric's concern is a good point, but it probably shouldn't be an 
> > > obstacle to acceptance as 1/ the current proposal is still a
> > > clear 
> > > improvement on the situation 2/ it's unlikely that there is a 
> > > cost-effective way to improve on this axis.
> > > 
> > > Adam complains about semantics in the Github thread [1]. Probably
> > > something worth improving before merging.
> > > 
> > > [1]: 
> > > https://github.com/ghc-proposals/ghc-proposals/pull/575#discussion_r1213653866
> > > 
> > > On Wed, 24 May 2023 at 11:10, Simon Peyton Jones 
> > > <simon.peytonjones at gmail.com> wrote:
> > > > I support acceptance, but I have asked a question about syntax.
> > > > 
> > > > Simon
> > > > 
> > > > On Fri, 19 May 2023 at 10:05, Moritz Angermann
> > > > <moritz.angermann at gmail.com> wrote:
> > > > > Dear Steering Committee,
> > > > > 
> > > > > I strongly endorse GHC Proposal #575
> > > > > <https://github.com/ghc-proposals/ghc-proposals/pull/575>,
> > > > > which suggests the introduction of deprecation pragmas on
> > > > > instances.
> > > > > 
> > > > > The proposal is a logical extension of Haskell's existing
> > > > > deprecation facilities. Its implementation would fill a
> > > > > notable gap in the language's current deprecation
> > > > > capabilities.
> > > > > 
> > > > > The lack of instance deprecation hinders controlled evolution
> > > > > of libraries and codebases, often leading to unexpected
> > > > > changes for users. By allowing instance deprecation, we can
> > > > > enhance the stability and predictability of Haskell codebases
> > > > > and improve the user experience.
> > > > > 
> > > > > In summary, Proposal #575 represents a valuable improvement
> > > > > for Haskell. I urge the committee to give it favorable
> > > > > consideration.
> > > > > 
> > > > > Best Regards, Moritz
> > > > > 
> > > > > _______________________________________________
> > > > > 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
> > > 
> > > 
> > > -- 
> > > Arnaud Spiwack
> > > Director, Research at https://moduscreate.com and
> > > https://tweag.io.
> > > _______________________________________________
> > > 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

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


From mail at joachim-breitner.de  Wed Jun 28 19:49:30 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 28 Jun 2023 21:49:30 +0200
Subject: [ghc-steering-committee] Please mention both PR number and title in
	the email subject
Message-ID: <0c7fb50fcaa97937ef2b13f3c298ad947d61a119.camel@joachim-breitner.de>

Dear Shepherds,

you’ll make my live easier if the email thread you start has both the
PR number and the title in the subject line. A good example is

  #330: Decorate exceptions with backtrace information, rec: accept

(but any subject line is better than no email, so thanks for your
service in either case!)

Cheers,
Joachim

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


From mail at joachim-breitner.de  Thu Jun 29 06:20:59 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 29 Jun 2023 08:20:59 +0200
Subject: [ghc-steering-committee] #596: sized literals in Show, rec: accept
Message-ID: <0a90849c93122ead8026bf5f9414f8da91a5f3c2.camel@joachim-breitner.de>

Dear committee,

Krzysztof Gogolewski in
https://github.com/ghc-proposals/ghc-proposals/pull/596
amends the sized literals proposal so that GHC uses the syntax 
42#Int8 instead of (intToInt8# 42#) in the stock derived Show instances
for data types with sized unboxed numbers.

Implementation is also ready.

Now that we have a syntax for these literals it’s clear that we want to
use them in the show instances. 


There is no risk of breaking Show-Read-roundtripping, as Read instances
cannot be derived (at the moment).

This is a change in behavior of Show, so we should think for a moment
how this affects stability. But none of the libraries in libraries/, in
particularly not base, are affected by this change, according to
Krzysztof.

So I recommend to accept this.

Cheers,
Joachim



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


From simon.peytonjones at gmail.com  Thu Jun 29 07:16:09 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Thu, 29 Jun 2023 08:16:09 +0100
Subject: [ghc-steering-committee] #596: sized literals in Show,
	rec: accept
In-Reply-To: <0a90849c93122ead8026bf5f9414f8da91a5f3c2.camel@joachim-breitner.de>
References: <0a90849c93122ead8026bf5f9414f8da91a5f3c2.camel@joachim-breitner.de>
Message-ID: <CAJKmMz96+rypF73qgb2=wxFhT34rpObR+gE-wLJWY7est=r7Wg@mail.gmail.com>

Looks good to me.

I have suggested that @monoidal opens a CLC issue.  (This change the `base`
API.)

Simon

On Thu, 29 Jun 2023 at 07:21, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Dear committee,
>
> Krzysztof Gogolewski in
> https://github.com/ghc-proposals/ghc-proposals/pull/596
> amends the sized literals proposal so that GHC uses the syntax
> 42#Int8 instead of (intToInt8# 42#) in the stock derived Show instances
> for data types with sized unboxed numbers.
>
> Implementation is also ready.
>
> Now that we have a syntax for these literals it’s clear that we want to
> use them in the show instances.
>
>
> There is no risk of breaking Show-Read-roundtripping, as Read instances
> cannot be derived (at the moment).
>
> This is a change in behavior of Show, so we should think for a moment
> how this affects stability. But none of the libraries in libraries/, in
> particularly not base, are affected by this change, according to
> Krzysztof.
>
> So I recommend to accept this.
>
> 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/20230629/cad284de/attachment.html>

From marlowsd at gmail.com  Thu Jun 29 07:26:17 2023
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu, 29 Jun 2023 08:26:17 +0100
Subject: [ghc-steering-committee] Base library organisation
In-Reply-To: <CAJKmMz-VCBsWarL-uDhS=vfNPOKecdnHfbxPTmwM9zP1cKYW1Q@mail.gmail.com>
References: <CAJKmMz-VCBsWarL-uDhS=vfNPOKecdnHfbxPTmwM9zP1cKYW1Q@mail.gmail.com>
Message-ID: <CANsrgPKhcaxa6Kd1_fPr3_jygvZf1SsrUE1xTmHQc7yZcKZCUg@mail.gmail.com>

The link in the email is broken BTW, is there any updated URL?

Just based on the summary in the email, what immediately springs to mind is
that adding functions to ghc-experimental and then moving them to base
implies an extra migration that clients have to do in the future (would the
APIs in ghc-experimental be deprecated first? For how long? etc.). It
probably makes sense only to do this for additions of fairly large new
APIs, and for smaller changes we should probably shortcut the process and
make the GHC proposal in conjunction with a CLC proposal and land them in
GHC together. Streamlining this process would be good. Maybe the actual
proposal already says a lot of this?

Cheers
Simon


On Thu, 15 Jun 2023 at 10:04, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> Dear GHC Steering Committee
>
> Over the last few weeks, Ben Gamari and I have been discussing with Andrew
> and Julian from the Core Libraries Committee how to make the Core Libraries
> Committee and the GHC developers work together more fluidly; and that
> includes the GHC Steering Committee.
>
> We now have a fairly well fleshed out proposal here.
> <https://github.com/Ericson2314/tech-proposals/blob/ghc-base-libraries/proposals/accepted/050-ghc-base-libraries.rst>
>
> I hope you like it.  As far as this committee is concerned there are two
> particular points of note
>
>    1. We propose a new package, *ghc-experimental*, which depends on
>    *base*.  Many GHC proposals involve defining new types and functions.
>    The idea is that these would initially be in *ghc-experimental*.
>    After they stabilise and become widely adopted, the author (or anyone else)
>    can make a CLC proposal to move them to *base*, which has much
>    stronger stability guarantees.
>    2. Section 5.1 suggests a mechanism to involve CLC members in
>    proposals that involve new functions and types, at an earlier stage.  Some
>    involve *changing *existing types and functions.  It is clearly
>    unproductive for us to debate such things at length, and only *then *to
>    land it on the CLC.
>
>    Section 5.1 also suggests that proposals should explicitly (in a
>    separate section) call out
>
>
>    - What new types and functions it defines
>    - What existing types and functions are changed.
>
> We should add that to our template.
>
> At the moment we are just sharing the proposal with relevant stakeholders
> (yourselves, CLC, stack folk, cabal folk etc), so that we can polish any
> rough edges before making it public.
>
> So, any views?  Personally I think this is a Big Step Forward.
>
> Simon
>
>
>
> _______________________________________________
> 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/20230629/3868224d/attachment-0001.html>

From moritz.angermann at gmail.com  Thu Jun 29 07:37:52 2023
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Thu, 29 Jun 2023 09:37:52 +0200
Subject: [ghc-steering-committee] Base library organisation
In-Reply-To: <CANsrgPKhcaxa6Kd1_fPr3_jygvZf1SsrUE1xTmHQc7yZcKZCUg@mail.gmail.com>
References: <CAJKmMz-VCBsWarL-uDhS=vfNPOKecdnHfbxPTmwM9zP1cKYW1Q@mail.gmail.com>
 <CANsrgPKhcaxa6Kd1_fPr3_jygvZf1SsrUE1xTmHQc7yZcKZCUg@mail.gmail.com>
Message-ID: <CAKfdd-wcsCK-ZQDpR92WX3MgqmVeBs8_522CmXjCWKNC23x5QA@mail.gmail.com>

Hopefully this URL will be more stable (and reference the rendered
proposal): https://github.com/haskellfoundation/tech-proposals/pull/51



On Thu, 29 Jun 2023 at 09:27, Simon Marlow <marlowsd at gmail.com> wrote:

> The link in the email is broken BTW, is there any updated URL?
>
> Just based on the summary in the email, what immediately springs to mind
> is that adding functions to ghc-experimental and then moving them to base
> implies an extra migration that clients have to do in the future (would the
> APIs in ghc-experimental be deprecated first? For how long? etc.). It
> probably makes sense only to do this for additions of fairly large new
> APIs, and for smaller changes we should probably shortcut the process and
> make the GHC proposal in conjunction with a CLC proposal and land them in
> GHC together. Streamlining this process would be good. Maybe the actual
> proposal already says a lot of this?
>
> Cheers
> Simon
>
>
> On Thu, 15 Jun 2023 at 10:04, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
>> Dear GHC Steering Committee
>>
>> Over the last few weeks, Ben Gamari and I have been discussing with
>> Andrew and Julian from the Core Libraries Committee how to make the Core
>> Libraries Committee and the GHC developers work together more fluidly; and
>> that includes the GHC Steering Committee.
>>
>> We now have a fairly well fleshed out proposal here.
>> <https://github.com/Ericson2314/tech-proposals/blob/ghc-base-libraries/proposals/accepted/050-ghc-base-libraries.rst>
>>
>> I hope you like it.  As far as this committee is concerned there are two
>> particular points of note
>>
>>    1. We propose a new package, *ghc-experimental*, which depends on
>>    *base*.  Many GHC proposals involve defining new types and
>>    functions.  The idea is that these would initially be in
>>    *ghc-experimental*.  After they stabilise and become widely adopted,
>>    the author (or anyone else) can make a CLC proposal to move them to
>>    *base*, which has much stronger stability guarantees.
>>    2. Section 5.1 suggests a mechanism to involve CLC members in
>>    proposals that involve new functions and types, at an earlier stage.  Some
>>    involve *changing *existing types and functions.  It is clearly
>>    unproductive for us to debate such things at length, and only *then *to
>>    land it on the CLC.
>>
>>    Section 5.1 also suggests that proposals should explicitly (in a
>>    separate section) call out
>>
>>
>>    - What new types and functions it defines
>>    - What existing types and functions are changed.
>>
>> We should add that to our template.
>>
>> At the moment we are just sharing the proposal with relevant stakeholders
>> (yourselves, CLC, stack folk, cabal folk etc), so that we can polish any
>> rough edges before making it public.
>>
>> So, any views?  Personally I think this is a Big Step Forward.
>>
>> Simon
>>
>>
>>
>> _______________________________________________
>> 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/20230629/1929bbe9/attachment.html>

From chris at chrisdornan.com  Thu Jun 29 08:35:57 2023
From: chris at chrisdornan.com (Chris Dornan)
Date: Thu, 29 Jun 2023 09:35:57 +0100
Subject: [ghc-steering-committee] #596: sized literals in Show,
 rec: accept
In-Reply-To: <CAJKmMz96+rypF73qgb2=wxFhT34rpObR+gE-wLJWY7est=r7Wg@mail.gmail.com>
References: <0a90849c93122ead8026bf5f9414f8da91a5f3c2.camel@joachim-breitner.de>
 <CAJKmMz96+rypF73qgb2=wxFhT34rpObR+gE-wLJWY7est=r7Wg@mail.gmail.com>
Message-ID: <602795CF-E38E-4122-AC02-132757A5034E@chrisdornan.com>

Agreed on both points: LGTM; lets keep the CLC in the loop.

> On 29 Jun 2023, at 08:16, Simon Peyton Jones <simon.peytonjones at gmail.com> wrote:
> 
> Looks good to me.
> 
> I have suggested that @monoidal opens a CLC issue.  (This change the `base` API.)
> 
> Simon
> 
> On Thu, 29 Jun 2023 at 07:21, Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
>> Dear committee,
>> 
>> Krzysztof Gogolewski in
>> https://github.com/ghc-proposals/ghc-proposals/pull/596
>> amends the sized literals proposal so that GHC uses the syntax 
>> 42#Int8 instead of (intToInt8# 42#) in the stock derived Show instances
>> for data types with sized unboxed numbers.
>> 
>> Implementation is also ready.
>> 
>> Now that we have a syntax for these literals it’s clear that we want to
>> use them in the show instances. 
>> 
>> 
>> There is no risk of breaking Show-Read-roundtripping, as Read instances
>> cannot be derived (at the moment).
>> 
>> This is a change in behavior of Show, so we should think for a moment
>> how this affects stability. But none of the libraries in libraries/, in
>> particularly not base, are affected by this change, according to
>> Krzysztof.
>> 
>> So I recommend to accept this.
>> 
>> Cheers,
>> Joachim
>> 
>> 
>> 
>> -- 
>> Joachim Breitner
>>   mail at joachim-breitner.de <mailto:mail at 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
> _______________________________________________
> 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/20230629/34b8e432/attachment.html>

From simon.peytonjones at gmail.com  Thu Jun 29 08:49:09 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Thu, 29 Jun 2023 09:49:09 +0100
Subject: [ghc-steering-committee] Base library organisation
In-Reply-To: <CANsrgPKhcaxa6Kd1_fPr3_jygvZf1SsrUE1xTmHQc7yZcKZCUg@mail.gmail.com>
References: <CAJKmMz-VCBsWarL-uDhS=vfNPOKecdnHfbxPTmwM9zP1cKYW1Q@mail.gmail.com>
 <CANsrgPKhcaxa6Kd1_fPr3_jygvZf1SsrUE1xTmHQc7yZcKZCUg@mail.gmail.com>
Message-ID: <CAJKmMz8pCy5fgYsgU1NvyC1mJm1Fjeaqc+ndKgYCs_yaa-EQYA@mail.gmail.com>

>
>   make the GHC proposal in conjunction with a CLC proposal and land them
> in GHC together. Streamlining this process would be good
>

That is absolutely an option, yes.

Simon

On Thu, 29 Jun 2023 at 08:27, Simon Marlow <marlowsd at gmail.com> wrote:

> The link in the email is broken BTW, is there any updated URL?
>
> Just based on the summary in the email, what immediately springs to mind
> is that adding functions to ghc-experimental and then moving them to base
> implies an extra migration that clients have to do in the future (would the
> APIs in ghc-experimental be deprecated first? For how long? etc.). It
> probably makes sense only to do this for additions of fairly large new
> APIs, and for smaller changes we should probably shortcut the process and
> make the GHC proposal in conjunction with a CLC proposal and land them in
> GHC together. Streamlining this process would be good. Maybe the actual
> proposal already says a lot of this?
>
> Cheers
> Simon
>
>
> On Thu, 15 Jun 2023 at 10:04, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
>> Dear GHC Steering Committee
>>
>> Over the last few weeks, Ben Gamari and I have been discussing with
>> Andrew and Julian from the Core Libraries Committee how to make the Core
>> Libraries Committee and the GHC developers work together more fluidly; and
>> that includes the GHC Steering Committee.
>>
>> We now have a fairly well fleshed out proposal here.
>> <https://github.com/Ericson2314/tech-proposals/blob/ghc-base-libraries/proposals/accepted/050-ghc-base-libraries.rst>
>>
>> I hope you like it.  As far as this committee is concerned there are two
>> particular points of note
>>
>>    1. We propose a new package, *ghc-experimental*, which depends on
>>    *base*.  Many GHC proposals involve defining new types and
>>    functions.  The idea is that these would initially be in
>>    *ghc-experimental*.  After they stabilise and become widely adopted,
>>    the author (or anyone else) can make a CLC proposal to move them to
>>    *base*, which has much stronger stability guarantees.
>>    2. Section 5.1 suggests a mechanism to involve CLC members in
>>    proposals that involve new functions and types, at an earlier stage.  Some
>>    involve *changing *existing types and functions.  It is clearly
>>    unproductive for us to debate such things at length, and only *then *to
>>    land it on the CLC.
>>
>>    Section 5.1 also suggests that proposals should explicitly (in a
>>    separate section) call out
>>
>>
>>    - What new types and functions it defines
>>    - What existing types and functions are changed.
>>
>> We should add that to our template.
>>
>> At the moment we are just sharing the proposal with relevant stakeholders
>> (yourselves, CLC, stack folk, cabal folk etc), so that we can polish any
>> rough edges before making it public.
>>
>> So, any views?  Personally I think this is a Big Step Forward.
>>
>> Simon
>>
>>
>>
>> _______________________________________________
>> 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/20230629/5a1b7efd/attachment-0001.html>