From adam at well-typed.com  Fri Oct  4 07:58:36 2024
From: adam at well-typed.com (Adam Gundry)
Date: Fri, 4 Oct 2024 08:58:36 +0100
Subject: [ghc-steering-committee] Please review #678: Amendment to
	ImportShadowing
Message-ID: <550aa370-8b7d-4fd4-91c5-4fecf530a277@well-typed.com>

Dear Committee,

Gergő Érdi proposes to amend his import shadowing proposal #652 to 
clarify the behaviour of module re-exports:

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

I'd like to nominate Erik de Castro Lopo as the shepherd, as he 
shepherded the original proposal.

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

Cheers,

Adam


-- 
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 erikd at mega-nerd.com  Wed Oct 16 23:38:19 2024
From: erikd at mega-nerd.com (Erik de Castro Lopo)
Date: Thu, 17 Oct 2024 10:38:19 +1100
Subject: [ghc-steering-committee] Please review #678: Amendment to
	ImportShadowing
In-Reply-To: <550aa370-8b7d-4fd4-91c5-4fecf530a277@well-typed.com>
References: <550aa370-8b7d-4fd4-91c5-4fecf530a277@well-typed.com>
Message-ID: <20241017103819.2c51f2011c99a6a5754706d8@mega-nerd.com>

Hi all,

I have recommended "accept" for this minor modification of this proposal.

I would appreciate it if everyone else on the committee would vote.

Thanks,
Erik


Adam Gundry wrote:

> Dear Committee,
> 
> Gergő Érdi proposes to amend his import shadowing proposal #652 to 
> clarify the behaviour of module re-exports:
> 
> https://github.com/ghc-proposals/ghc-proposals/pull/678
> 
> I'd like to nominate Erik de Castro Lopo as the shepherd, as he 
> shepherded the original proposal.
> 
> Please guide us to a conclusion as outlined in
> https://github.com/ghc-proposals/ghc-proposals#committee-process
> 
> Cheers,
> 
> Adam
> 
> 
> -- 
> 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
> 


-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

From sgraf1337 at gmail.com  Thu Oct 17 07:31:22 2024
From: sgraf1337 at gmail.com (Sebastian Graf)
Date: Thu, 17 Oct 2024 07:31:22 +0000
Subject: [ghc-steering-committee] Please review #678: Amendment to
 ImportShadowing
In-Reply-To: <20241017103819.2c51f2011c99a6a5754706d8@mega-nerd.com>
References: <550aa370-8b7d-4fd4-91c5-4fecf530a277@well-typed.com>
 <20241017103819.2c51f2011c99a6a5754706d8@mega-nerd.com>
Message-ID: <em8e18ba79-035d-4df5-af74-42610ab99ad7@bf41eb72.com>

Hi,

I vote "accept" as well. I'm a bit surprised by the subtlety, but the 
clarified semantics makes sense.

Cheers,
Sebastian


------ Originalnachricht ------
Von "Erik de Castro Lopo" <erikd at mega-nerd.com>
An ghc-steering-committee at haskell.org
Datum 17.10.2024 01:38:19
Betreff Re: [ghc-steering-committee] Please review #678: Amendment to 
ImportShadowing

>Hi all,
>
>I have recommended "accept" for this minor modification of this proposal.
>
>I would appreciate it if everyone else on the committee would vote.
>
>Thanks,
>Erik
>
>
>Adam Gundry wrote:
>
>>  Dear Committee,
>>
>>  Gergő Érdi proposes to amend his import shadowing proposal #652 to
>>  clarify the behaviour of module re-exports:
>>
>>  https://github.com/ghc-proposals/ghc-proposals/pull/678
>>
>>  I'd like to nominate Erik de Castro Lopo as the shepherd, as he
>>  shepherded the original proposal.
>>
>>  Please guide us to a conclusion as outlined in
>>  https://github.com/ghc-proposals/ghc-proposals#committee-process
>>
>>  Cheers,
>>
>>  Adam
>>
>>
>>  --
>>  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
>>
>
>
>--
>----------------------------------------------------------------------
>Erik de Castro Lopo
>http://www.mega-nerd.com/
>_______________________________________________
>ghc-steering-committee mailing list
>ghc-steering-committee at haskell.org
>https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

From moritz.angermann at gmail.com  Thu Oct 17 07:45:59 2024
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Thu, 17 Oct 2024 16:45:59 +0900
Subject: [ghc-steering-committee] Please review #678: Amendment to
	ImportShadowing
In-Reply-To: <em8e18ba79-035d-4df5-af74-42610ab99ad7@bf41eb72.com>
References: <550aa370-8b7d-4fd4-91c5-4fecf530a277@well-typed.com>
 <20241017103819.2c51f2011c99a6a5754706d8@mega-nerd.com>
 <em8e18ba79-035d-4df5-af74-42610ab99ad7@bf41eb72.com>
Message-ID: <CAKfdd-yCJ73mqiYZ2ATFioZ9uiyrFRkZTCLwiFMEmjK6WQQGsA@mail.gmail.com>

Hi,

I’m in support as well!

Best,
 Moritz

On Thu, Oct 17, 2024 at 4:31 PM Sebastian Graf <sgraf1337 at gmail.com> wrote:

> Hi,
>
> I vote "accept" as well. I'm a bit surprised by the subtlety, but the
> clarified semantics makes sense.
>
> Cheers,
> Sebastian
>
>
> ------ Originalnachricht ------
> Von "Erik de Castro Lopo" <erikd at mega-nerd.com>
> An ghc-steering-committee at haskell.org
> Datum 17.10.2024 01:38:19
> Betreff Re: [ghc-steering-committee] Please review #678: Amendment to
> ImportShadowing
>
> >Hi all,
> >
> >I have recommended "accept" for this minor modification of this proposal.
> >
> >I would appreciate it if everyone else on the committee would vote.
> >
> >Thanks,
> >Erik
> >
> >
> >Adam Gundry wrote:
> >
> >>  Dear Committee,
> >>
> >>  Gergő Érdi proposes to amend his import shadowing proposal #652 to
> >>  clarify the behaviour of module re-exports:
> >>
> >>  https://github.com/ghc-proposals/ghc-proposals/pull/678
> >>
> >>  I'd like to nominate Erik de Castro Lopo as the shepherd, as he
> >>  shepherded the original proposal.
> >>
> >>  Please guide us to a conclusion as outlined in
> >>  https://github.com/ghc-proposals/ghc-proposals#committee-process
> >>
> >>  Cheers,
> >>
> >>  Adam
> >>
> >>
> >>  --
> >>  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
> >>
> >
> >
> >--
> >----------------------------------------------------------------------
> >Erik de Castro Lopo
> >http://www.mega-nerd.com/
> >_______________________________________________
> >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/20241017/b438aae0/attachment.html>

From simon.peytonjones at gmail.com  Thu Oct 17 07:58:45 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Thu, 17 Oct 2024 08:58:45 +0100
Subject: [ghc-steering-committee] Please review #678: Amendment to
	ImportShadowing
In-Reply-To: <20241017103819.2c51f2011c99a6a5754706d8@mega-nerd.com>
References: <550aa370-8b7d-4fd4-91c5-4fecf530a277@well-typed.com>
 <20241017103819.2c51f2011c99a6a5754706d8@mega-nerd.com>
Message-ID: <CAJKmMz_SUdZQM3-CkOXQ2j=DmtK2hSckFdZsuuoDmwX23E4ptQ@mail.gmail.com>

I support, subject to a couple of typos I have identified.

Simon

On Thu, 17 Oct 2024 at 00:38, Erik de Castro Lopo <erikd at mega-nerd.com>
wrote:

> Hi all,
>
> I have recommended "accept" for this minor modification of this proposal.
>
> I would appreciate it if everyone else on the committee would vote.
>
> Thanks,
> Erik
>
>
> Adam Gundry wrote:
>
> > Dear Committee,
> >
> > Gergő Érdi proposes to amend his import shadowing proposal #652 to
> > clarify the behaviour of module re-exports:
> >
> > https://github.com/ghc-proposals/ghc-proposals/pull/678
> >
> > I'd like to nominate Erik de Castro Lopo as the shepherd, as he
> > shepherded the original proposal.
> >
> > Please guide us to a conclusion as outlined in
> > https://github.com/ghc-proposals/ghc-proposals#committee-process
> >
> > Cheers,
> >
> > Adam
> >
> >
> > --
> > 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
> >
>
>
> --
> ----------------------------------------------------------------------
> Erik de Castro Lopo
> http://www.mega-nerd.com/
> _______________________________________________
> 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/20241017/9e48a36a/attachment.html>

From malte.ott at maralorn.de  Fri Oct 18 08:33:07 2024
From: malte.ott at maralorn.de (Malte Ott)
Date: Fri, 18 Oct 2024 10:33:07 +0200
Subject: [ghc-steering-committee] Please review #678: Amendment to
 ImportShadowing
In-Reply-To: <CAJKmMz_SUdZQM3-CkOXQ2j=DmtK2hSckFdZsuuoDmwX23E4ptQ@mail.gmail.com>
References: <550aa370-8b7d-4fd4-91c5-4fecf530a277@well-typed.com>
 <20241017103819.2c51f2011c99a6a5754706d8@mega-nerd.com>
 <CAJKmMz_SUdZQM3-CkOXQ2j=DmtK2hSckFdZsuuoDmwX23E4ptQ@mail.gmail.com>
Message-ID: <uohrnxv5hhuexmt2tgwyyztt3bob4ihzc4yvlfwgqs5xnossv5@hera.m-0.eu>

I support as well.

On 2024-10-17 08:58, Simon Peyton Jones wrote:
> I support, subject to a couple of typos I have identified.
> 
> Simon
> 
> On Thu, 17 Oct 2024 at 00:38, Erik de Castro Lopo <erikd at mega-nerd.com>
> wrote:
> 
> > Hi all,
> >
> > I have recommended "accept" for this minor modification of this proposal.
> >
> > I would appreciate it if everyone else on the committee would vote.
> >
> > Thanks,
> > Erik
> >
> >
> > Adam Gundry wrote:
> >
> > > Dear Committee,
> > >
> > > Gergő Érdi proposes to amend his import shadowing proposal #652 to
> > > clarify the behaviour of module re-exports:
> > >
> > > https://github.com/ghc-proposals/ghc-proposals/pull/678
> > >
> > > I'd like to nominate Erik de Castro Lopo as the shepherd, as he
> > > shepherded the original proposal.
> > >
> > > Please guide us to a conclusion as outlined in
> > > https://github.com/ghc-proposals/ghc-proposals#committee-process
> > >
> > > Cheers,
> > >
> > > Adam
> > >
> > >
> > > --
> > > 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
> > >
> >
> >
> > --
> > ----------------------------------------------------------------------
> > Erik de Castro Lopo
> > http://www.mega-nerd.com/
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> >

> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


From jakob.bruenker at gmail.com  Fri Oct 18 08:42:37 2024
From: jakob.bruenker at gmail.com (=?UTF-8?Q?Jakob_Br=C3=BCnker?=)
Date: Fri, 18 Oct 2024 10:42:37 +0200
Subject: [ghc-steering-committee] Please review #678: Amendment to
	ImportShadowing
In-Reply-To: <uohrnxv5hhuexmt2tgwyyztt3bob4ihzc4yvlfwgqs5xnossv5@hera.m-0.eu>
References: <550aa370-8b7d-4fd4-91c5-4fecf530a277@well-typed.com>
 <20241017103819.2c51f2011c99a6a5754706d8@mega-nerd.com>
 <CAJKmMz_SUdZQM3-CkOXQ2j=DmtK2hSckFdZsuuoDmwX23E4ptQ@mail.gmail.com>
 <uohrnxv5hhuexmt2tgwyyztt3bob4ihzc4yvlfwgqs5xnossv5@hera.m-0.eu>
Message-ID: <CAJjQ6oPQneRm7ks+iPi88Qmzvt8H7cXo1z3maqursifvjwHS7A@mail.gmail.com>

Seems like a reasonable amendment, I'm in support.

On Fri, Oct 18, 2024 at 10:33 AM Malte Ott <malte.ott at maralorn.de> wrote:

> I support as well.
>
> On 2024-10-17 08:58, Simon Peyton Jones wrote:
> > I support, subject to a couple of typos I have identified.
> >
> > Simon
> >
> > On Thu, 17 Oct 2024 at 00:38, Erik de Castro Lopo <erikd at mega-nerd.com>
> > wrote:
> >
> > > Hi all,
> > >
> > > I have recommended "accept" for this minor modification of this
> proposal.
> > >
> > > I would appreciate it if everyone else on the committee would vote.
> > >
> > > Thanks,
> > > Erik
> > >
> > >
> > > Adam Gundry wrote:
> > >
> > > > Dear Committee,
> > > >
> > > > Gergő Érdi proposes to amend his import shadowing proposal #652 to
> > > > clarify the behaviour of module re-exports:
> > > >
> > > > https://github.com/ghc-proposals/ghc-proposals/pull/678
> > > >
> > > > I'd like to nominate Erik de Castro Lopo as the shepherd, as he
> > > > shepherded the original proposal.
> > > >
> > > > Please guide us to a conclusion as outlined in
> > > > https://github.com/ghc-proposals/ghc-proposals#committee-process
> > > >
> > > > Cheers,
> > > >
> > > > Adam
> > > >
> > > >
> > > > --
> > > > 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
> > > >
> > >
> > >
> > > --
> > > ----------------------------------------------------------------------
> > > Erik de Castro Lopo
> > > http://www.mega-nerd.com/
> > > _______________________________________________
> > > 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/20241018/c593f355/attachment.html>

From arnaud.spiwack at tweag.io  Mon Oct 21 02:50:08 2024
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Mon, 21 Oct 2024 11:50:08 +0900
Subject: [ghc-steering-committee] Please review #678: Amendment to
	ImportShadowing
In-Reply-To: <CAJjQ6oPQneRm7ks+iPi88Qmzvt8H7cXo1z3maqursifvjwHS7A@mail.gmail.com>
References: <550aa370-8b7d-4fd4-91c5-4fecf530a277@well-typed.com>
 <20241017103819.2c51f2011c99a6a5754706d8@mega-nerd.com>
 <CAJKmMz_SUdZQM3-CkOXQ2j=DmtK2hSckFdZsuuoDmwX23E4ptQ@mail.gmail.com>
 <uohrnxv5hhuexmt2tgwyyztt3bob4ihzc4yvlfwgqs5xnossv5@hera.m-0.eu>
 <CAJjQ6oPQneRm7ks+iPi88Qmzvt8H7cXo1z3maqursifvjwHS7A@mail.gmail.com>
Message-ID: <CAGwnsnkNtxnHWc6qusxVuRg4vpCGv-7WZ0Oin6dK5b0aUVVB2g@mail.gmail.com>

I find it a little annoying that this isn't backward compatible. But on the
other hand, it's a very obscure bit of Haskell semantics which is modified,
module re-export is something that most people frequently get wrong anyway.
At any rate, my feeling is that the proposed change is the right behaviour:
if a module defines a function `foo`, and exports a *different* function
`foo`, this is at least a smell, isn't it?

So, in favour.

On Fri, 18 Oct 2024 at 17:43, Jakob Brünker <jakob.bruenker at gmail.com>
wrote:

> Seems like a reasonable amendment, I'm in support.
>
> On Fri, Oct 18, 2024 at 10:33 AM Malte Ott <malte.ott at maralorn.de> wrote:
>
>> I support as well.
>>
>> On 2024-10-17 08:58, Simon Peyton Jones wrote:
>> > I support, subject to a couple of typos I have identified.
>> >
>> > Simon
>> >
>> > On Thu, 17 Oct 2024 at 00:38, Erik de Castro Lopo <erikd at mega-nerd.com>
>> > wrote:
>> >
>> > > Hi all,
>> > >
>> > > I have recommended "accept" for this minor modification of this
>> proposal.
>> > >
>> > > I would appreciate it if everyone else on the committee would vote.
>> > >
>> > > Thanks,
>> > > Erik
>> > >
>> > >
>> > > Adam Gundry wrote:
>> > >
>> > > > Dear Committee,
>> > > >
>> > > > Gergő Érdi proposes to amend his import shadowing proposal #652 to
>> > > > clarify the behaviour of module re-exports:
>> > > >
>> > > > https://github.com/ghc-proposals/ghc-proposals/pull/678
>> > > >
>> > > > I'd like to nominate Erik de Castro Lopo as the shepherd, as he
>> > > > shepherded the original proposal.
>> > > >
>> > > > Please guide us to a conclusion as outlined in
>> > > > https://github.com/ghc-proposals/ghc-proposals#committee-process
>> > > >
>> > > > Cheers,
>> > > >
>> > > > Adam
>> > > >
>> > > >
>> > > > --
>> > > > 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
>> > > >
>> > >
>> > >
>> > > --
>> > > ----------------------------------------------------------------------
>> > > Erik de Castro Lopo
>> > > http://www.mega-nerd.com/
>> > > _______________________________________________
>> > > ghc-steering-committee mailing list
>> > > ghc-steering-committee at haskell.org
>> > >
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> > >
>>
>> > _______________________________________________
>> > ghc-steering-committee mailing list
>> > ghc-steering-committee at haskell.org
>> >
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>


-- 
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/20241021/824210de/attachment.html>

From simon.peytonjones at gmail.com  Mon Oct 21 08:01:09 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Mon, 21 Oct 2024 09:01:09 +0100
Subject: [ghc-steering-committee] Please review #678: Amendment to
	ImportShadowing
In-Reply-To: <CAGwnsnkNtxnHWc6qusxVuRg4vpCGv-7WZ0Oin6dK5b0aUVVB2g@mail.gmail.com>
References: <550aa370-8b7d-4fd4-91c5-4fecf530a277@well-typed.com>
 <20241017103819.2c51f2011c99a6a5754706d8@mega-nerd.com>
 <CAJKmMz_SUdZQM3-CkOXQ2j=DmtK2hSckFdZsuuoDmwX23E4ptQ@mail.gmail.com>
 <uohrnxv5hhuexmt2tgwyyztt3bob4ihzc4yvlfwgqs5xnossv5@hera.m-0.eu>
 <CAJjQ6oPQneRm7ks+iPi88Qmzvt8H7cXo1z3maqursifvjwHS7A@mail.gmail.com>
 <CAGwnsnkNtxnHWc6qusxVuRg4vpCGv-7WZ0Oin6dK5b0aUVVB2g@mail.gmail.com>
Message-ID: <CAJKmMz9zpcO6L0WRrevC6F_SkWrKSG_s0asyJRjYeBQ6=Q6Yjg@mail.gmail.com>

I find it a little annoying that this isn't backward compatible


Me too. I outline on the Github a way to make it backward compatible.
*Everyone*: do express a view there.

Simon

On Mon, 21 Oct 2024 at 03:50, Arnaud Spiwack <arnaud.spiwack at tweag.io>
wrote:

> I find it a little annoying that this isn't backward compatible. But on
> the other hand, it's a very obscure bit of Haskell semantics which is
> modified, module re-export is something that most people frequently get
> wrong anyway. At any rate, my feeling is that the proposed change is the
> right behaviour: if a module defines a function `foo`, and exports a
> *different* function `foo`, this is at least a smell, isn't it?
>
> So, in favour.
>
> On Fri, 18 Oct 2024 at 17:43, Jakob Brünker <jakob.bruenker at gmail.com>
> wrote:
>
>> Seems like a reasonable amendment, I'm in support.
>>
>> On Fri, Oct 18, 2024 at 10:33 AM Malte Ott <malte.ott at maralorn.de> wrote:
>>
>>> I support as well.
>>>
>>> On 2024-10-17 08:58, Simon Peyton Jones wrote:
>>> > I support, subject to a couple of typos I have identified.
>>> >
>>> > Simon
>>> >
>>> > On Thu, 17 Oct 2024 at 00:38, Erik de Castro Lopo <erikd at mega-nerd.com
>>> >
>>> > wrote:
>>> >
>>> > > Hi all,
>>> > >
>>> > > I have recommended "accept" for this minor modification of this
>>> proposal.
>>> > >
>>> > > I would appreciate it if everyone else on the committee would vote.
>>> > >
>>> > > Thanks,
>>> > > Erik
>>> > >
>>> > >
>>> > > Adam Gundry wrote:
>>> > >
>>> > > > Dear Committee,
>>> > > >
>>> > > > Gergő Érdi proposes to amend his import shadowing proposal #652 to
>>> > > > clarify the behaviour of module re-exports:
>>> > > >
>>> > > > https://github.com/ghc-proposals/ghc-proposals/pull/678
>>> > > >
>>> > > > I'd like to nominate Erik de Castro Lopo as the shepherd, as he
>>> > > > shepherded the original proposal.
>>> > > >
>>> > > > Please guide us to a conclusion as outlined in
>>> > > > https://github.com/ghc-proposals/ghc-proposals#committee-process
>>> > > >
>>> > > > Cheers,
>>> > > >
>>> > > > Adam
>>> > > >
>>> > > >
>>> > > > --
>>> > > > 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
>>> > > >
>>> > >
>>> > >
>>> > > --
>>> > >
>>> ----------------------------------------------------------------------
>>> > > Erik de Castro Lopo
>>> > > http://www.mega-nerd.com/
>>> > > _______________________________________________
>>> > > ghc-steering-committee mailing list
>>> > > ghc-steering-committee at haskell.org
>>> > >
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>> > >
>>>
>>> > _______________________________________________
>>> > ghc-steering-committee mailing list
>>> > ghc-steering-committee at haskell.org
>>> >
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>
>
> --
> 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/20241021/e0574e47/attachment.html>

From mpg at mpg.is  Mon Oct 21 08:27:08 2024
From: mpg at mpg.is (=?UTF-8?Q?Matth=C3=ADas_P=C3=A1ll_Gissurarson?=)
Date: Mon, 21 Oct 2024 10:27:08 +0200
Subject: [ghc-steering-committee] Please review #678: Amendment to
	ImportShadowing
In-Reply-To: <CAGwnsnkNtxnHWc6qusxVuRg4vpCGv-7WZ0Oin6dK5b0aUVVB2g@mail.gmail.com>
References: <550aa370-8b7d-4fd4-91c5-4fecf530a277@well-typed.com>
 <20241017103819.2c51f2011c99a6a5754706d8@mega-nerd.com>
 <CAJKmMz_SUdZQM3-CkOXQ2j=DmtK2hSckFdZsuuoDmwX23E4ptQ@mail.gmail.com>
 <uohrnxv5hhuexmt2tgwyyztt3bob4ihzc4yvlfwgqs5xnossv5@hera.m-0.eu>
 <CAJjQ6oPQneRm7ks+iPi88Qmzvt8H7cXo1z3maqursifvjwHS7A@mail.gmail.com>
 <CAGwnsnkNtxnHWc6qusxVuRg4vpCGv-7WZ0Oin6dK5b0aUVVB2g@mail.gmail.com>
Message-ID: <CAPxmXQz+zVKFuWsd0kk0-BeHkuo68qsmSf1jJNidiJGwPJGsOg@mail.gmail.com>

I'm in support. I agree with Simon's comment, we'd be well served by a
better spec for what `module M` means in an export list, but this amendment
is closer to what we would want.

On Mon, 21 Oct 2024 at 04:50, Arnaud Spiwack <arnaud.spiwack at tweag.io>
wrote:

> I find it a little annoying that this isn't backward compatible. But on
> the other hand, it's a very obscure bit of Haskell semantics which is
> modified, module re-export is something that most people frequently get
> wrong anyway. At any rate, my feeling is that the proposed change is the
> right behaviour: if a module defines a function `foo`, and exports a
> *different* function `foo`, this is at least a smell, isn't it?
>
> So, in favour.
>
> On Fri, 18 Oct 2024 at 17:43, Jakob Brünker <jakob.bruenker at gmail.com>
> wrote:
>
>> Seems like a reasonable amendment, I'm in support.
>>
>> On Fri, Oct 18, 2024 at 10:33 AM Malte Ott <malte.ott at maralorn.de> wrote:
>>
>>> I support as well.
>>>
>>> On 2024-10-17 08:58, Simon Peyton Jones wrote:
>>> > I support, subject to a couple of typos I have identified.
>>> >
>>> > Simon
>>> >
>>> > On Thu, 17 Oct 2024 at 00:38, Erik de Castro Lopo <erikd at mega-nerd.com
>>> >
>>> > wrote:
>>> >
>>> > > Hi all,
>>> > >
>>> > > I have recommended "accept" for this minor modification of this
>>> proposal.
>>> > >
>>> > > I would appreciate it if everyone else on the committee would vote.
>>> > >
>>> > > Thanks,
>>> > > Erik
>>> > >
>>> > >
>>> > > Adam Gundry wrote:
>>> > >
>>> > > > Dear Committee,
>>> > > >
>>> > > > Gergő Érdi proposes to amend his import shadowing proposal #652 to
>>> > > > clarify the behaviour of module re-exports:
>>> > > >
>>> > > > https://github.com/ghc-proposals/ghc-proposals/pull/678
>>> > > >
>>> > > > I'd like to nominate Erik de Castro Lopo as the shepherd, as he
>>> > > > shepherded the original proposal.
>>> > > >
>>> > > > Please guide us to a conclusion as outlined in
>>> > > > https://github.com/ghc-proposals/ghc-proposals#committee-process
>>> > > >
>>> > > > Cheers,
>>> > > >
>>> > > > Adam
>>> > > >
>>> > > >
>>> > > > --
>>> > > > 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
>>> > > >
>>> > >
>>> > >
>>> > > --
>>> > >
>>> ----------------------------------------------------------------------
>>> > > Erik de Castro Lopo
>>> > > http://www.mega-nerd.com/
>>> > > _______________________________________________
>>> > > ghc-steering-committee mailing list
>>> > > ghc-steering-committee at haskell.org
>>> > >
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>> > >
>>>
>>> > _______________________________________________
>>> > ghc-steering-committee mailing list
>>> > ghc-steering-committee at haskell.org
>>> >
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>
>
> --
> 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
>


-- 
--  Matthías Páll Gissurarson <http://mpg.is/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20241021/3d266867/attachment-0001.html>

From simon.peytonjones at gmail.com  Mon Oct 21 08:48:35 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Mon, 21 Oct 2024 09:48:35 +0100
Subject: [ghc-steering-committee] Please review #678: Amendment to
	ImportShadowing
In-Reply-To: <CAPxmXQz+zVKFuWsd0kk0-BeHkuo68qsmSf1jJNidiJGwPJGsOg@mail.gmail.com>
References: <550aa370-8b7d-4fd4-91c5-4fecf530a277@well-typed.com>
 <20241017103819.2c51f2011c99a6a5754706d8@mega-nerd.com>
 <CAJKmMz_SUdZQM3-CkOXQ2j=DmtK2hSckFdZsuuoDmwX23E4ptQ@mail.gmail.com>
 <uohrnxv5hhuexmt2tgwyyztt3bob4ihzc4yvlfwgqs5xnossv5@hera.m-0.eu>
 <CAJjQ6oPQneRm7ks+iPi88Qmzvt8H7cXo1z3maqursifvjwHS7A@mail.gmail.com>
 <CAGwnsnkNtxnHWc6qusxVuRg4vpCGv-7WZ0Oin6dK5b0aUVVB2g@mail.gmail.com>
 <CAPxmXQz+zVKFuWsd0kk0-BeHkuo68qsmSf1jJNidiJGwPJGsOg@mail.gmail.com>
Message-ID: <CAJKmMz8gYXc1B-MMiiBLFkrSX44C98drLfViBfSJrB-8T13GDg@mail.gmail.com>

> we'd be well served by a better spec for what `module M` means in an
export list,

Well, that's the entire purpose of this amendment!

   - Do you think it now gives a clear spec?
   - Do you prefer the alternative (more complicated, but backward
   compatible) spec I suggested here
   <https://github.com/ghc-proposals/ghc-proposals/pull/678#issuecomment-2421884753>
   ?

Simon


On Mon, 21 Oct 2024 at 09:27, Matthías Páll Gissurarson <mpg at mpg.is> wrote:

> I'm in support. I agree with Simon's comment, we'd be well served by a
> better spec for what `module M` means in an export list, but this amendment
> is closer to what we would want.
>
> On Mon, 21 Oct 2024 at 04:50, Arnaud Spiwack <arnaud.spiwack at tweag.io>
> wrote:
>
>> I find it a little annoying that this isn't backward compatible. But on
>> the other hand, it's a very obscure bit of Haskell semantics which is
>> modified, module re-export is something that most people frequently get
>> wrong anyway. At any rate, my feeling is that the proposed change is the
>> right behaviour: if a module defines a function `foo`, and exports a
>> *different* function `foo`, this is at least a smell, isn't it?
>>
>> So, in favour.
>>
>> On Fri, 18 Oct 2024 at 17:43, Jakob Brünker <jakob.bruenker at gmail.com>
>> wrote:
>>
>>> Seems like a reasonable amendment, I'm in support.
>>>
>>> On Fri, Oct 18, 2024 at 10:33 AM Malte Ott <malte.ott at maralorn.de>
>>> wrote:
>>>
>>>> I support as well.
>>>>
>>>> On 2024-10-17 08:58, Simon Peyton Jones wrote:
>>>> > I support, subject to a couple of typos I have identified.
>>>> >
>>>> > Simon
>>>> >
>>>> > On Thu, 17 Oct 2024 at 00:38, Erik de Castro Lopo <
>>>> erikd at mega-nerd.com>
>>>> > wrote:
>>>> >
>>>> > > Hi all,
>>>> > >
>>>> > > I have recommended "accept" for this minor modification of this
>>>> proposal.
>>>> > >
>>>> > > I would appreciate it if everyone else on the committee would vote.
>>>> > >
>>>> > > Thanks,
>>>> > > Erik
>>>> > >
>>>> > >
>>>> > > Adam Gundry wrote:
>>>> > >
>>>> > > > Dear Committee,
>>>> > > >
>>>> > > > Gergő Érdi proposes to amend his import shadowing proposal #652 to
>>>> > > > clarify the behaviour of module re-exports:
>>>> > > >
>>>> > > > https://github.com/ghc-proposals/ghc-proposals/pull/678
>>>> > > >
>>>> > > > I'd like to nominate Erik de Castro Lopo as the shepherd, as he
>>>> > > > shepherded the original proposal.
>>>> > > >
>>>> > > > Please guide us to a conclusion as outlined in
>>>> > > > https://github.com/ghc-proposals/ghc-proposals#committee-process
>>>> > > >
>>>> > > > Cheers,
>>>> > > >
>>>> > > > Adam
>>>> > > >
>>>> > > >
>>>> > > > --
>>>> > > > 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
>>>> > > >
>>>> > >
>>>> > >
>>>> > > --
>>>> > >
>>>> ----------------------------------------------------------------------
>>>> > > Erik de Castro Lopo
>>>> > > http://www.mega-nerd.com/
>>>> > > _______________________________________________
>>>> > > ghc-steering-committee mailing list
>>>> > > ghc-steering-committee at haskell.org
>>>> > >
>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>> > >
>>>>
>>>> > _______________________________________________
>>>> > ghc-steering-committee mailing list
>>>> > ghc-steering-committee at haskell.org
>>>> >
>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>
>>>> _______________________________________________
>>>> ghc-steering-committee mailing list
>>>> ghc-steering-committee at haskell.org
>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>>
>>
>> --
>> 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
>>
>
>
> --
> --  Matthías Páll Gissurarson <http://mpg.is/>
> _______________________________________________
> 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/20241021/09b001e7/attachment.html>

From mpg at mpg.is  Mon Oct 21 09:40:07 2024
From: mpg at mpg.is (=?UTF-8?Q?Matth=C3=ADas_P=C3=A1ll_Gissurarson?=)
Date: Mon, 21 Oct 2024 11:40:07 +0200
Subject: [ghc-steering-committee] Please review #678: Amendment to
	ImportShadowing
In-Reply-To: <CAJKmMz8gYXc1B-MMiiBLFkrSX44C98drLfViBfSJrB-8T13GDg@mail.gmail.com>
References: <550aa370-8b7d-4fd4-91c5-4fecf530a277@well-typed.com>
 <20241017103819.2c51f2011c99a6a5754706d8@mega-nerd.com>
 <CAJKmMz_SUdZQM3-CkOXQ2j=DmtK2hSckFdZsuuoDmwX23E4ptQ@mail.gmail.com>
 <uohrnxv5hhuexmt2tgwyyztt3bob4ihzc4yvlfwgqs5xnossv5@hera.m-0.eu>
 <CAJjQ6oPQneRm7ks+iPi88Qmzvt8H7cXo1z3maqursifvjwHS7A@mail.gmail.com>
 <CAGwnsnkNtxnHWc6qusxVuRg4vpCGv-7WZ0Oin6dK5b0aUVVB2g@mail.gmail.com>
 <CAPxmXQz+zVKFuWsd0kk0-BeHkuo68qsmSf1jJNidiJGwPJGsOg@mail.gmail.com>
 <CAJKmMz8gYXc1B-MMiiBLFkrSX44C98drLfViBfSJrB-8T13GDg@mail.gmail.com>
Message-ID: <CAPxmXQzFc7wQt8SX5eS0jWf53cASQzc2=WrXFjf1BvC5eXB95Q@mail.gmail.com>

I’m in favor of the backward compatible one, it’s a bit more complicated
but (I think) clearer. I’ve left some comments on the PR itself.

/Matti Palli


On Mon, Oct 21, 2024 at 10:48 Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> > we'd be well served by a better spec for what `module M` means in an
> export list,
>
> Well, that's the entire purpose of this amendment!
>
>    - Do you think it now gives a clear spec?
>    - Do you prefer the alternative (more complicated, but backward
>    compatible) spec I suggested here
>    <https://github.com/ghc-proposals/ghc-proposals/pull/678#issuecomment-2421884753>
>    ?
>
> Simon
>
>
> On Mon, 21 Oct 2024 at 09:27, Matthías Páll Gissurarson <mpg at mpg.is>
> wrote:
>
>> I'm in support. I agree with Simon's comment, we'd be well served by a
>> better spec for what `module M` means in an export list, but this amendment
>> is closer to what we would want.
>>
>> On Mon, 21 Oct 2024 at 04:50, Arnaud Spiwack <arnaud.spiwack at tweag.io>
>> wrote:
>>
>>> I find it a little annoying that this isn't backward compatible. But on
>>> the other hand, it's a very obscure bit of Haskell semantics which is
>>> modified, module re-export is something that most people frequently get
>>> wrong anyway. At any rate, my feeling is that the proposed change is the
>>> right behaviour: if a module defines a function `foo`, and exports a
>>> *different* function `foo`, this is at least a smell, isn't it?
>>>
>>> So, in favour.
>>>
>>> On Fri, 18 Oct 2024 at 17:43, Jakob Brünker <jakob.bruenker at gmail.com>
>>> wrote:
>>>
>>>> Seems like a reasonable amendment, I'm in support.
>>>>
>>>> On Fri, Oct 18, 2024 at 10:33 AM Malte Ott <malte.ott at maralorn.de>
>>>> wrote:
>>>>
>>>>> I support as well.
>>>>>
>>>>> On 2024-10-17 08:58, Simon Peyton Jones wrote:
>>>>> > I support, subject to a couple of typos I have identified.
>>>>> >
>>>>> > Simon
>>>>> >
>>>>> > On Thu, 17 Oct 2024 at 00:38, Erik de Castro Lopo <
>>>>> erikd at mega-nerd.com>
>>>>> > wrote:
>>>>> >
>>>>> > > Hi all,
>>>>> > >
>>>>> > > I have recommended "accept" for this minor modification of this
>>>>> proposal.
>>>>> > >
>>>>> > > I would appreciate it if everyone else on the committee would vote.
>>>>> > >
>>>>> > > Thanks,
>>>>> > > Erik
>>>>> > >
>>>>> > >
>>>>> > > Adam Gundry wrote:
>>>>> > >
>>>>> > > > Dear Committee,
>>>>> > > >
>>>>> > > > Gergő Érdi proposes to amend his import shadowing proposal #652
>>>>> to
>>>>> > > > clarify the behaviour of module re-exports:
>>>>> > > >
>>>>> > > > https://github.com/ghc-proposals/ghc-proposals/pull/678
>>>>> > > >
>>>>> > > > I'd like to nominate Erik de Castro Lopo as the shepherd, as he
>>>>> > > > shepherded the original proposal.
>>>>> > > >
>>>>> > > > Please guide us to a conclusion as outlined in
>>>>> > > > https://github.com/ghc-proposals/ghc-proposals#committee-process
>>>>> > > >
>>>>> > > > Cheers,
>>>>> > > >
>>>>> > > > Adam
>>>>> > > >
>>>>> > > >
>>>>> > > > --
>>>>> > > > 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
>>>>> <https://www.google.com/maps/search/27+Old+Gloucester+Street,+London+WC1N+3AX,+England?entry=gmail&source=g>
>>>>> > > >
>>>>> > >
>>>>> > >
>>>>> > > --
>>>>> > >
>>>>> ----------------------------------------------------------------------
>>>>> > > Erik de Castro Lopo
>>>>> > > http://www.mega-nerd.com/
>>>>> > > _______________________________________________
>>>>> > > ghc-steering-committee mailing list
>>>>> > > ghc-steering-committee at haskell.org
>>>>> > >
>>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>> > >
>>>>>
>>>>> > _______________________________________________
>>>>> > ghc-steering-committee mailing list
>>>>> > ghc-steering-committee at haskell.org
>>>>> >
>>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>>
>>>>> _______________________________________________
>>>>> ghc-steering-committee mailing list
>>>>> ghc-steering-committee at haskell.org
>>>>>
>>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>>
>>>> _______________________________________________
>>>> ghc-steering-committee mailing list
>>>> ghc-steering-committee at haskell.org
>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>
>>>
>>>
>>> --
>>> 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
>>>
>>
>>
>> --
>> --  Matthías Páll Gissurarson <http://mpg.is/>
>> _______________________________________________
>> 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/20241021/0187fb20/attachment-0001.html>

From sgraf1337 at gmail.com  Mon Oct 21 10:20:31 2024
From: sgraf1337 at gmail.com (Sebastian Graf)
Date: Mon, 21 Oct 2024 12:20:31 +0200
Subject: [ghc-steering-committee] Please review #678: Amendment to
	ImportShadowing
In-Reply-To: <CAPxmXQzFc7wQt8SX5eS0jWf53cASQzc2=WrXFjf1BvC5eXB95Q@mail.gmail.com>
References: <550aa370-8b7d-4fd4-91c5-4fecf530a277@well-typed.com>
 <20241017103819.2c51f2011c99a6a5754706d8@mega-nerd.com>
 <CAJKmMz_SUdZQM3-CkOXQ2j=DmtK2hSckFdZsuuoDmwX23E4ptQ@mail.gmail.com>
 <uohrnxv5hhuexmt2tgwyyztt3bob4ihzc4yvlfwgqs5xnossv5@hera.m-0.eu>
 <CAJjQ6oPQneRm7ks+iPi88Qmzvt8H7cXo1z3maqursifvjwHS7A@mail.gmail.com>
 <CAGwnsnkNtxnHWc6qusxVuRg4vpCGv-7WZ0Oin6dK5b0aUVVB2g@mail.gmail.com>
 <CAPxmXQz+zVKFuWsd0kk0-BeHkuo68qsmSf1jJNidiJGwPJGsOg@mail.gmail.com>
 <CAJKmMz8gYXc1B-MMiiBLFkrSX44C98drLfViBfSJrB-8T13GDg@mail.gmail.com>
 <CAPxmXQzFc7wQt8SX5eS0jWf53cASQzc2=WrXFjf1BvC5eXB95Q@mail.gmail.com>
Message-ID: <CAAS+=P_xfB5-SNU=ZEJGvsV7iWGZq10zVx1jP-39Qpp9rMe6mA@mail.gmail.com>

I would like to hear back from the proposal author. If he's willing to
incorporate Simon's spec, I would be very happy.
I still accept the proposal as-is in the interest of making progress.

Am Mo., 21. Okt. 2024 um 11:40 Uhr schrieb Matthías Páll Gissurarson <
mpg at mpg.is>:

> I’m in favor of the backward compatible one, it’s a bit more complicated
> but (I think) clearer. I’ve left some comments on the PR itself.
>
> /Matti Palli
>
>
> On Mon, Oct 21, 2024 at 10:48 Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
>> > we'd be well served by a better spec for what `module M` means in an
>> export list,
>>
>> Well, that's the entire purpose of this amendment!
>>
>>    - Do you think it now gives a clear spec?
>>    - Do you prefer the alternative (more complicated, but backward
>>    compatible) spec I suggested here
>>    <https://github.com/ghc-proposals/ghc-proposals/pull/678#issuecomment-2421884753>
>>    ?
>>
>> Simon
>>
>>
>> On Mon, 21 Oct 2024 at 09:27, Matthías Páll Gissurarson <mpg at mpg.is>
>> wrote:
>>
>>> I'm in support. I agree with Simon's comment, we'd be well served by a
>>> better spec for what `module M` means in an export list, but this amendment
>>> is closer to what we would want.
>>>
>>> On Mon, 21 Oct 2024 at 04:50, Arnaud Spiwack <arnaud.spiwack at tweag.io>
>>> wrote:
>>>
>>>> I find it a little annoying that this isn't backward compatible. But on
>>>> the other hand, it's a very obscure bit of Haskell semantics which is
>>>> modified, module re-export is something that most people frequently get
>>>> wrong anyway. At any rate, my feeling is that the proposed change is the
>>>> right behaviour: if a module defines a function `foo`, and exports a
>>>> *different* function `foo`, this is at least a smell, isn't it?
>>>>
>>>> So, in favour.
>>>>
>>>> On Fri, 18 Oct 2024 at 17:43, Jakob Brünker <jakob.bruenker at gmail.com>
>>>> wrote:
>>>>
>>>>> Seems like a reasonable amendment, I'm in support.
>>>>>
>>>>> On Fri, Oct 18, 2024 at 10:33 AM Malte Ott <malte.ott at maralorn.de>
>>>>> wrote:
>>>>>
>>>>>> I support as well.
>>>>>>
>>>>>> On 2024-10-17 08:58, Simon Peyton Jones wrote:
>>>>>> > I support, subject to a couple of typos I have identified.
>>>>>> >
>>>>>> > Simon
>>>>>> >
>>>>>> > On Thu, 17 Oct 2024 at 00:38, Erik de Castro Lopo <
>>>>>> erikd at mega-nerd.com>
>>>>>> > wrote:
>>>>>> >
>>>>>> > > Hi all,
>>>>>> > >
>>>>>> > > I have recommended "accept" for this minor modification of this
>>>>>> proposal.
>>>>>> > >
>>>>>> > > I would appreciate it if everyone else on the committee would
>>>>>> vote.
>>>>>> > >
>>>>>> > > Thanks,
>>>>>> > > Erik
>>>>>> > >
>>>>>> > >
>>>>>> > > Adam Gundry wrote:
>>>>>> > >
>>>>>> > > > Dear Committee,
>>>>>> > > >
>>>>>> > > > Gergő Érdi proposes to amend his import shadowing proposal #652
>>>>>> to
>>>>>> > > > clarify the behaviour of module re-exports:
>>>>>> > > >
>>>>>> > > > https://github.com/ghc-proposals/ghc-proposals/pull/678
>>>>>> > > >
>>>>>> > > > I'd like to nominate Erik de Castro Lopo as the shepherd, as he
>>>>>> > > > shepherded the original proposal.
>>>>>> > > >
>>>>>> > > > Please guide us to a conclusion as outlined in
>>>>>> > > >
>>>>>> https://github.com/ghc-proposals/ghc-proposals#committee-process
>>>>>> > > >
>>>>>> > > > Cheers,
>>>>>> > > >
>>>>>> > > > Adam
>>>>>> > > >
>>>>>> > > >
>>>>>> > > > --
>>>>>> > > > 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
>>>>>> <https://www.google.com/maps/search/27+Old+Gloucester+Street,+London+WC1N+3AX,+England?entry=gmail&source=g>
>>>>>> > > >
>>>>>> > >
>>>>>> > >
>>>>>> > > --
>>>>>> > >
>>>>>> ----------------------------------------------------------------------
>>>>>> > > Erik de Castro Lopo
>>>>>> > > http://www.mega-nerd.com/
>>>>>> > > _______________________________________________
>>>>>> > > ghc-steering-committee mailing list
>>>>>> > > ghc-steering-committee at haskell.org
>>>>>> > >
>>>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>>> > >
>>>>>>
>>>>>> > _______________________________________________
>>>>>> > ghc-steering-committee mailing list
>>>>>> > ghc-steering-committee at haskell.org
>>>>>> >
>>>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>>>
>>>>>> _______________________________________________
>>>>>> ghc-steering-committee mailing list
>>>>>> ghc-steering-committee at haskell.org
>>>>>>
>>>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>>>
>>>>> _______________________________________________
>>>>> ghc-steering-committee mailing list
>>>>> ghc-steering-committee at haskell.org
>>>>>
>>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>>
>>>>
>>>>
>>>> --
>>>> 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
>>>>
>>>
>>>
>>> --
>>> --  Matthías Páll Gissurarson <http://mpg.is/>
>>> _______________________________________________
>>> 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/20241021/e8c11c18/attachment.html>

From simon.peytonjones at gmail.com  Mon Oct 28 08:13:26 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Mon, 28 Oct 2024 08:13:26 +0000
Subject: [ghc-steering-committee] Statistical analysis of GHC proposals
In-Reply-To: <E780AF43-0E6F-424C-80EE-7BF0198BA146@gmail.com>
References: <E780AF43-0E6F-424C-80EE-7BF0198BA146@gmail.com>
Message-ID: <CAJKmMz87j11ju6Cycf6Gdh3_suL0o5+3SC1YoBHGEcORNOrbHg@mail.gmail.com>

Dear Andrew

Thank you -- that's very interesting.

GHC SC: do look below!

I'm not quite sure what, if anything, we should do in the light of this
information.

Simon

On Sun, 27 Oct 2024 at 23:06, Andrew Lelechenko <andrew.lelechenko at gmail.com>
wrote:

> Hi Simon,
>
> I’ve been exploring GitHub API capabilities by gathering data on GHC
> proposals. I wonder if any of the numbers below might be interesting to
> reflect on for GHC SC.
>
> Total number of GHC proposals: 441
> Rate of proposals:  5 per month
> Approved proposals: 149
> Need revision:      30
> Declined proposals: 16
>
> Median  time from creation to decision: 101 days
> Average time from creation to decision: 181 days
> Median  time from creation to approval: 100 days
> Average time from creation to approval: 165 days
> Fastest approval:
>         8 days for "Adjust warning category syntax"
> 2nd fastest approval:
>         11 days for "Remove dot from characters allowed in overloaded
> labels"
> 2nd slowest approval:
>         980 days for "Fine-grained unused warnings"
> Slowest approval:
>         1112 days for "Decorate exceptions with backtrace information"
>
> Total activity: 15999 comments
> Median  activity per proposal:          23 comments
> Average activity per proposal:          36 comments
> Median  activity per approved proposal: 31 comments
> Average activity per approved proposal: 51 comments
> Least active approved proposal:
>         1 comment for "Amend the Higher Order Patterns proposal"
> 2nd least active approved proposal:
>         2 comments for "Amend 281 visible forall to work without
> ScopedTypeVariables"
> 2nd most active:
>         313 comments for "Lambda expressions with guards and multiple
> clauses (was: `\\ of`, -XMultiWayLambda)"
> Most active:
>         519 comments for "RecordDotSyntax language extension proposal"
>
> Open proposals: 117
> Median  age for open proposals: 1105 days
> Average age for open proposals: 1215 days
> Newest open proposal:
>         12 days for "Clarify CRLF behavior in multiline strings"
> Oldest open proposal:
>         2960 days for "Mutable constructor fields"
>
> Best regards,
> Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20241028/93b2c430/attachment.html>

From adam at well-typed.com  Tue Oct 29 19:37:05 2024
From: adam at well-typed.com (Adam Gundry)
Date: Tue, 29 Oct 2024 19:37:05 +0000
Subject: [ghc-steering-committee] Please review #673: Amendment to -jsem
 proposal #540
In-Reply-To: <em63aabb01-6ad6-43e5-b597-afad17fe0a94@ad1f818c.com>
References: <cafec484-0ca7-4f0c-8949-992e9c115537@well-typed.com>
 <20240920100038.f2cc7a353c4b4ce02da189f2@mega-nerd.com>
 <86d15bf6-a4e1-4b5f-bf49-de7f88496f32@app.fastmail.com>
 <i46tbqu3ptd36vlc4sgsckpycry6uzispkp7ksi6i34nfiwoo5@hera.m-0.eu>
 <CAJKmMz8K8twpXOC2uZD8xH006Oi-nt+28q=j+BZkCGW8Ds9zuw@mail.gmail.com>
 <CAGwnsn=nNKX+bh+CWD_dd4N0HTGzBTBnB5oTTKTyp_TNS7_vnA@mail.gmail.com>
 <em63aabb01-6ad6-43e5-b597-afad17fe0a94@ad1f818c.com>
Message-ID: <c27ff99d-02ab-43ff-b503-4ef3151b8fe5@well-typed.com>

It seems Zubin updated the proposal to take account of Sebastian's 
concerns, but then discussion has tailed off. Are we now in a position 
to accept this proposal, or are there any remaining concerns?

Cheers,

Adam



On 24/09/2024 07:44, Sebastian Graf wrote:
> I think changes to the communication protocol *are* user-facing, in that 
> any change to the protocol could implies a breaking change between all 
> cabal releases in the future and all GHC releases in the past.
> It appears that is the case for the planned release of 
> `semaphore-compat-2`, but I'm not 100% sure.
> 
> In that light, I think it's good to discuss in a proposal to ensure we 
> do not sign off lightly on such breaking changes, in particular for 
> future versions of `semaphore-compat`.
> 
> I will express support once compatibility and breaking changes are 
> properly addressed.
> 
> Sebastian
> 
> ------ Originalnachricht ------
> Von "Arnaud Spiwack" <arnaud.spiwack at tweag.io 
> <mailto:arnaud.spiwack at tweag.io>>
> An "Simon Peyton Jones" <simon.peytonjones at gmail.com 
> <mailto:simon.peytonjones at gmail.com>>
> Cc ghc-steering-committee at haskell.org 
> <mailto:ghc-steering-committee at haskell.org>
> Datum 24.09.2024 04:17:17
> Betreff Re: [ghc-steering-committee] Please review #673: Amendment to 
> -jsem proposal #540
> 
>> Quite frankly, this is barely any user-facing change at all. 
>> Technically the semaphore could previously be shared by non-Haskell 
>> processes in ways the updated proposal doesn't allow. But it's not 
>> really something people do. So it all sounds reasonable.
>>
>> On Mon, 23 Sept 2024 at 19:10, Simon Peyton Jones 
>> <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>> wrote:
>>
>>     I'm happy to support too, but I would like to see presentational
>>     changes, so the final proposal makes sense when read in 5 yrs time.
>>
>>     Simon
>>
>>     On Sat, 21 Sept 2024 at 20:45, Malte Ott <malte.ott at maralorn.de
>>     <mailto:malte.ott at maralorn.de>> wrote:
>>
>>         I agree.
>>
>>         On 2024-09-21 09:16, Eric Seidel wrote:
>>         > Hi all,
>>         >
>>         > This seems like a sensible update to an accepted proposal.
>>         >
>>         > I recommend we accept the amendment.
>>         >
>>         > Eric
>>         >
>>         > On Thu, Sep 19, 2024, at 19:00, Erik de Castro Lopo wrote:
>>         > > Hi all,
>>         > >
>>         > > This is minor updates to correct an existing approved
>>         proposal.
>>         > >
>>         > > I approve of these changes.
>>         > >
>>         > > Erik
>>         > >
>>         > > Adam Gundry wrote:
>>         > >
>>         > >> Dear Committee,
>>         > >>
>>         > >> Zubin Duggal proposes to amend proposal #540, which
>>         introduced the -jsem
>>         > >> parallelism control mechanism, so that it can avoid
>>         incompatibilities
>>         > >> arising from different system C library implementations:
>>         > >>
>>         > >> https://github.com/ghc-proposals/ghc-proposals/pull/673
>>         <https://github.com/ghc-proposals/ghc-proposals/pull/673>
>>         > >>
>>         > >>
>>         https://github.com/wz1000/ghc-proposals/blob/new-jsem/proposals/0540-jsem.rst <https://github.com/wz1000/ghc-proposals/blob/new-jsem/proposals/0540-jsem.rst>
>>         > >>
>>         > >> I'd like to nominate Eric Seidel as the shepherd, since
>>         he was the
>>         > >> shepherd of the original proposal.
>>         > >>
>>         > >> Please guide us to a conclusion as outlined in
>>         > >>
>>         https://github.com/ghc-proposals/ghc-proposals#committee-process <https://github.com/ghc-proposals/ghc-proposals#committee-process>
>>         > >>
>>         > >> Cheers,
>>         > >>
>>         > >> Adam

	
-- 
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  Tue Oct 29 19:45:23 2024
From: adam at well-typed.com (Adam Gundry)
Date: Tue, 29 Oct 2024 19:45:23 +0000
Subject: [ghc-steering-committee] Please review #669: Initial categorization
	of language extensions
Message-ID: <6581139a-1784-4ecd-81e4-13a7848d9d27@well-typed.com>

Dear Committee,

Trevis Elser proposes a classification of (some) language extensions 
based on previous work in proposal #601 establishing categories:

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

https://github.com/telser/ghc-proposals/blob/initial-extension-categorization/proposals/0000-initial-extension-categorization.md

I'd like to nominate Malte Ott as the shepherd.

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

Cheers,

Adam

-- 
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  Tue Oct 29 20:12:03 2024
From: adam at well-typed.com (Adam Gundry)
Date: Tue, 29 Oct 2024 20:12:03 +0000
Subject: [ghc-steering-committee] #668: Allow reserved identifiers as fields
 in OverloadedRecordDot, recommendation: accept
Message-ID: <414a9ae5-6602-4cc7-9c04-97fd79c90681@well-typed.com>

Dear Committee,

In the interests of getting things moving on proposal #668 from Matt 
Parsons, I'll shepherd it myself, and recommend we accept it.

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

This is a small amendment to the OverloadedRecordDot extension to allow 
reserved identifiers as field names. For example, this program is 
currently rejected with a parse error, but would be accepted:

   import GHC.Records

   x = foo.type -- parse error, "type" is a reserved identifier

   data T = MkT Int
   foo = MkT 42
   instance HasField "type" T Int where
      getField (MkT x) = x

While "type" is not a valid field name in a traditional Haskell record 
data type, there is nothing stopping a user defining their own instance 
for `HasField "type" r a`, and some users would like to do so (e.g. when 
using HasField to interface with a database). Attempting to use such an 
instance with OverloadedRecordDot runs into this parse error. However 
the presence of the dot syntax means there is no ambiguity in what the 
user means. Even if a user wrote `x.type` by accident, they are likely 
to get better diagnostic information if the parser accepts the program. 
The only issue I see is that some syntax highlighters unaware of this 
change may incorrectly highlight such record projections as keywords.

Please indicate whether you are happy to accept this proposal.

Cheers,

Adam


-- 
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  Tue Oct 29 20:35:17 2024
From: adam at well-typed.com (Adam Gundry)
Date: Tue, 29 Oct 2024 20:35:17 +0000
Subject: [ghc-steering-committee] Statistical analysis of GHC proposals
In-Reply-To: <CAJKmMz87j11ju6Cycf6Gdh3_suL0o5+3SC1YoBHGEcORNOrbHg@mail.gmail.com>
References: <E780AF43-0E6F-424C-80EE-7BF0198BA146@gmail.com>
 <CAJKmMz87j11ju6Cycf6Gdh3_suL0o5+3SC1YoBHGEcORNOrbHg@mail.gmail.com>
Message-ID: <6225fd22-483d-4798-982e-d79cda656b7a@well-typed.com>

This is indeed interesting, thanks Andrew. We have some impressively 
mature proposals!

Something I've been mulling over for a while is that our process tends 
not to explicitly reject many proposals, but it is not unusual for 
proposals to stall in one of two states:

1. There is some initial discussion, but no final decision, and the 
original author stops actively driving the proposal forward (e.g. 
because they no longer have time or enthusiasm). In some cases the 
discussion may have been leaning towards rejection, but in others there 
are good ideas lingering that need someone to pick them up.

2. The proposal is accepted, but then lingers awaiting implementation. 
This is difficult to address in a world of limited resources for GHC 
development (both volunteer effort and paid maintainer time).

At the moment I usually wait until a proposal author explicitly submits 
the proposal for committee consideration before assigning a shepherd. It 
is then the shepherd's responsibility to make progress in a reasonable time.

One change I've been wondering about is that we might try to identify 
shepherds from the committee at an earlier stage, and/or encourage 
shepherds to volunteer when they see an interesting proposal. The 
shepherd could then help the original author respond to the discussion 
and move through the process (perhaps including taking over the proposal 
if the original author is no longer engaging). For example I'm 
effectively trying to do this on #668. This might result in fewer 
proposals getting blocked indefinitely, at the cost of more shepherding 
work for the committee. What do you all think?

Adam



On 28/10/2024 08:13, Simon Peyton Jones wrote:
> Dear Andrew
> 
> Thank you -- that's very interesting.
> 
> GHC SC: do look below!
> 
> I'm not quite sure what, if anything, we should do in the light of this 
> information.
> 
> Simon
> 
> On Sun, 27 Oct 2024 at 23:06, Andrew Lelechenko 
> <andrew.lelechenko at gmail.com <mailto:andrew.lelechenko at gmail.com>> wrote:
> 
>     Hi Simon,
> 
>     I’ve been exploring GitHub API capabilities by gathering data on GHC
>     proposals. I wonder if any of the numbers below might be interesting
>     to reflect on for GHC SC.
> 
>     Total number of GHC proposals: 441
>     Rate of proposals:  5 per month
>     Approved proposals: 149
>     Need revision:      30
>     Declined proposals: 16
> 
>     Median  time from creation to decision: 101 days
>     Average time from creation to decision: 181 days
>     Median  time from creation to approval: 100 days
>     Average time from creation to approval: 165 days
>     Fastest approval:
>              8 days for "Adjust warning category syntax"
>     2nd fastest approval:
>              11 days for "Remove dot from characters allowed in
>     overloaded labels"
>     2nd slowest approval:
>              980 days for "Fine-grained unused warnings"
>     Slowest approval:
>              1112 days for "Decorate exceptions with backtrace information"
> 
>     Total activity: 15999 comments
>     Median  activity per proposal:          23 comments
>     Average activity per proposal:          36 comments
>     Median  activity per approved proposal: 31 comments
>     Average activity per approved proposal: 51 comments
>     Least active approved proposal:
>              1 comment for "Amend the Higher Order Patterns proposal"
>     2nd least active approved proposal:
>              2 comments for "Amend 281 visible forall to work without
>     ScopedTypeVariables"
>     2nd most active:
>              313 comments for "Lambda expressions with guards and
>     multiple clauses (was: `\\ of`, -XMultiWayLambda)"
>     Most active:
>              519 comments for "RecordDotSyntax language extension proposal"
> 
>     Open proposals: 117
>     Median  age for open proposals: 1105 days
>     Average age for open proposals: 1215 days
>     Newest open proposal:
>              12 days for "Clarify CRLF behavior in multiline strings"
>     Oldest open proposal:
>              2960 days for "Mutable constructor fields"
> 
>     Best regards,
>     Andrew
> 


-- 
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 malte.ott at maralorn.de  Tue Oct 29 22:11:17 2024
From: malte.ott at maralorn.de (Malte Ott)
Date: Tue, 29 Oct 2024 23:11:17 +0100
Subject: [ghc-steering-committee] Statistical analysis of GHC proposals
In-Reply-To: <6225fd22-483d-4798-982e-d79cda656b7a@well-typed.com>
References: <E780AF43-0E6F-424C-80EE-7BF0198BA146@gmail.com>
 <CAJKmMz87j11ju6Cycf6Gdh3_suL0o5+3SC1YoBHGEcORNOrbHg@mail.gmail.com>
 <6225fd22-483d-4798-982e-d79cda656b7a@well-typed.com>
Message-ID: <yqig6qq4vh4bopbuwtxqlqbmqqnq6mecoi4em4ljtakracaafa@hera.m-0.eu>

On 2024-10-29 20:35, Adam Gundry wrote:
> At the moment I usually wait until a proposal author explicitly submits the
> proposal for committee consideration before assigning a shepherd. It is then
> the shepherd's responsibility to make progress in a reasonable time.
> 
> One change I've been wondering about is that we might try to identify
> shepherds from the committee at an earlier stage, and/or encourage shepherds
> to volunteer when they see an interesting proposal. The shepherd could then
> help the original author respond to the discussion and move through the
> process (perhaps including taking over the proposal if the original author
> is no longer engaging). For example I'm effectively trying to do this on
> #668. This might result in fewer proposals getting blocked indefinitely, at
> the cost of more shepherding work for the committee. What do you all think?
> 
> Adam

Thank you Adam. I think this is a great idea. The proposal process is
perceived daunting by many so we should try to be excellent and welcoming hosts.
(Which does not mean compromising in rigor.)

Main argument in favor is in my opinion, that in the last year the (felt)
proposal throughput has decreased will the backlog of work for the committee is
mostly empty. That is actually partially an accomplishment of the committee, but
it also shows that we can probably do more to foster progress in GHC.

The only problem I see - and it is the obvious one - is that we have
historically had sheperds on the committee which were very unresponsive, for
various (probably quite understandable reasons). With more responsibilities the
gap between expectation and delivery would likely increase.

So we should probably only do this if a clear majority of the committee is in
favor. (Or more generally if we can still find enough volunteers to commit to
doing this.) Otherwise we would promise something we can’t deliver.

Now that I am thinking about it we would then need a hopefully clear description
of the responsibilities of the sheperd before submission.
I think it is sometimes kind of problematic, that there is supposed to be a
community discussion during preparation of the proposal, but then the committee
is only formally asked to look at it after that discussion happened.
We should be part of the discussion. Simon has at times pointed us at proposals
in the discussion phase, but maybe there is a slightly more structured way to
do this.

Best
Malte

From simon.peytonjones at gmail.com  Tue Oct 29 22:16:20 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Tue, 29 Oct 2024 22:16:20 +0000
Subject: [ghc-steering-committee] Please review #673: Amendment to -jsem
 proposal #540
In-Reply-To: <c27ff99d-02ab-43ff-b503-4ef3151b8fe5@well-typed.com>
References: <cafec484-0ca7-4f0c-8949-992e9c115537@well-typed.com>
 <20240920100038.f2cc7a353c4b4ce02da189f2@mega-nerd.com>
 <86d15bf6-a4e1-4b5f-bf49-de7f88496f32@app.fastmail.com>
 <i46tbqu3ptd36vlc4sgsckpycry6uzispkp7ksi6i34nfiwoo5@hera.m-0.eu>
 <CAJKmMz8K8twpXOC2uZD8xH006Oi-nt+28q=j+BZkCGW8Ds9zuw@mail.gmail.com>
 <CAGwnsn=nNKX+bh+CWD_dd4N0HTGzBTBnB5oTTKTyp_TNS7_vnA@mail.gmail.com>
 <em63aabb01-6ad6-43e5-b597-afad17fe0a94@ad1f818c.com>
 <c27ff99d-02ab-43ff-b503-4ef3151b8fe5@well-typed.com>
Message-ID: <CAJKmMz-T=7m=ypVsvXOOjnaBanUfdA2YeknLTZZQTha2d1hFWg@mail.gmail.com>

I'm supportive.   I do not have a well-informed view, but the amendment is
born from practical experience, so I am pretty sure it's an improvement.

I'd love a bit more detail in the proposal (I have commented in one place)
but I might be off-target and would yield to others' advice, including that
of the author.

Simon

On Tue, 29 Oct 2024 at 19:37, Adam Gundry <adam at well-typed.com> wrote:

> It seems Zubin updated the proposal to take account of Sebastian's
> concerns, but then discussion has tailed off. Are we now in a position
> to accept this proposal, or are there any remaining concerns?
>
> Cheers,
>
> Adam
>
>
>
> On 24/09/2024 07:44, Sebastian Graf wrote:
> > I think changes to the communication protocol *are* user-facing, in that
> > any change to the protocol could implies a breaking change between all
> > cabal releases in the future and all GHC releases in the past.
> > It appears that is the case for the planned release of
> > `semaphore-compat-2`, but I'm not 100% sure.
> >
> > In that light, I think it's good to discuss in a proposal to ensure we
> > do not sign off lightly on such breaking changes, in particular for
> > future versions of `semaphore-compat`.
> >
> > I will express support once compatibility and breaking changes are
> > properly addressed.
> >
> > Sebastian
> >
> > ------ Originalnachricht ------
> > Von "Arnaud Spiwack" <arnaud.spiwack at tweag.io
> > <mailto:arnaud.spiwack at tweag.io>>
> > An "Simon Peyton Jones" <simon.peytonjones at gmail.com
> > <mailto:simon.peytonjones at gmail.com>>
> > Cc ghc-steering-committee at haskell.org
> > <mailto:ghc-steering-committee at haskell.org>
> > Datum 24.09.2024 04:17:17
> > Betreff Re: [ghc-steering-committee] Please review #673: Amendment to
> > -jsem proposal #540
> >
> >> Quite frankly, this is barely any user-facing change at all.
> >> Technically the semaphore could previously be shared by non-Haskell
> >> processes in ways the updated proposal doesn't allow. But it's not
> >> really something people do. So it all sounds reasonable.
> >>
> >> On Mon, 23 Sept 2024 at 19:10, Simon Peyton Jones
> >> <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>>
> wrote:
> >>
> >>     I'm happy to support too, but I would like to see presentational
> >>     changes, so the final proposal makes sense when read in 5 yrs time.
> >>
> >>     Simon
> >>
> >>     On Sat, 21 Sept 2024 at 20:45, Malte Ott <malte.ott at maralorn.de
> >>     <mailto:malte.ott at maralorn.de>> wrote:
> >>
> >>         I agree.
> >>
> >>         On 2024-09-21 09:16, Eric Seidel wrote:
> >>         > Hi all,
> >>         >
> >>         > This seems like a sensible update to an accepted proposal.
> >>         >
> >>         > I recommend we accept the amendment.
> >>         >
> >>         > Eric
> >>         >
> >>         > On Thu, Sep 19, 2024, at 19:00, Erik de Castro Lopo wrote:
> >>         > > Hi all,
> >>         > >
> >>         > > This is minor updates to correct an existing approved
> >>         proposal.
> >>         > >
> >>         > > I approve of these changes.
> >>         > >
> >>         > > Erik
> >>         > >
> >>         > > Adam Gundry wrote:
> >>         > >
> >>         > >> Dear Committee,
> >>         > >>
> >>         > >> Zubin Duggal proposes to amend proposal #540, which
> >>         introduced the -jsem
> >>         > >> parallelism control mechanism, so that it can avoid
> >>         incompatibilities
> >>         > >> arising from different system C library implementations:
> >>         > >>
> >>         > >> https://github.com/ghc-proposals/ghc-proposals/pull/673
> >>         <https://github.com/ghc-proposals/ghc-proposals/pull/673>
> >>         > >>
> >>         > >>
> >>
> https://github.com/wz1000/ghc-proposals/blob/new-jsem/proposals/0540-jsem.rst
> <
> https://github.com/wz1000/ghc-proposals/blob/new-jsem/proposals/0540-jsem.rst
> >
> >>         > >>
> >>         > >> I'd like to nominate Eric Seidel as the shepherd, since
> >>         he was the
> >>         > >> shepherd of the original proposal.
> >>         > >>
> >>         > >> Please guide us to a conclusion as outlined in
> >>         > >>
> >>
> https://github.com/ghc-proposals/ghc-proposals#committee-process <
> https://github.com/ghc-proposals/ghc-proposals#committee-process>
> >>         > >>
> >>         > >> Cheers,
> >>         > >>
> >>         > >> Adam
>
>
> --
> Adam Gundry, Haskell Consultant
> Well-Typed LLP, https://www.well-typed.com/
>
> Registered in England & Wales, OC335890
> 27 Old Gloucester Street, London WC1N 3AX, England
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20241029/8396afe6/attachment.html>

From simon.peytonjones at gmail.com  Wed Oct 30 22:38:02 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Wed, 30 Oct 2024 22:38:02 +0000
Subject: [ghc-steering-committee] Statistical analysis of GHC proposals
In-Reply-To: <yqig6qq4vh4bopbuwtxqlqbmqqnq6mecoi4em4ljtakracaafa@hera.m-0.eu>
References: <E780AF43-0E6F-424C-80EE-7BF0198BA146@gmail.com>
 <CAJKmMz87j11ju6Cycf6Gdh3_suL0o5+3SC1YoBHGEcORNOrbHg@mail.gmail.com>
 <6225fd22-483d-4798-982e-d79cda656b7a@well-typed.com>
 <yqig6qq4vh4bopbuwtxqlqbmqqnq6mecoi4em4ljtakracaafa@hera.m-0.eu>
Message-ID: <CAJKmMz-=+zG7C6-n9VHdjuijK9ZSfq9DRkaR3pMKpJCi_vExPw@mail.gmail.com>

>
> Now that I am thinking about it we would then need a hopefully clear
> description

of the responsibilities of the sheperd before submission


Our current statement of those responsibilities is here:
https://github.com/ghc-proposals/ghc-proposals#committee-process-for-responding-to-a-proposal

I wonder if we should make it clearer or more prominent.  It says:

   - Shepherd should make a recommendation within weeks.
   - Committee should decide within a month after that

I think it is helpful to have a clear moment at which the proposal is
submitted to the committee.  I agree that the involvement of a shepherd
prior to that point would be helpful.   But ideally the community at large
engages in discussion with the author to develop and refine their proposal.
I'm cautious about adding an obligation to proactively engage with all
proposals.  But *perhaps an author can request a shepherd to consult*, in
advance of submitting the proposal.  That puts the initiative on the
author, to which we can (and should) be responsive.  Would that work?

Simon

On Tue, 29 Oct 2024 at 22:11, Malte Ott <malte.ott at maralorn.de> wrote:

> On 2024-10-29 20:35, Adam Gundry wrote:
> > At the moment I usually wait until a proposal author explicitly submits
> the
> > proposal for committee consideration before assigning a shepherd. It is
> then
> > the shepherd's responsibility to make progress in a reasonable time.
> >
> > One change I've been wondering about is that we might try to identify
> > shepherds from the committee at an earlier stage, and/or encourage
> shepherds
> > to volunteer when they see an interesting proposal. The shepherd could
> then
> > help the original author respond to the discussion and move through the
> > process (perhaps including taking over the proposal if the original
> author
> > is no longer engaging). For example I'm effectively trying to do this on
> > #668. This might result in fewer proposals getting blocked indefinitely,
> at
> > the cost of more shepherding work for the committee. What do you all
> think?
> >
> > Adam
>
> Thank you Adam. I think this is a great idea. The proposal process is
> perceived daunting by many so we should try to be excellent and welcoming
> hosts.
> (Which does not mean compromising in rigor.)
>
> Main argument in favor is in my opinion, that in the last year the (felt)
> proposal throughput has decreased will the backlog of work for the
> committee is
> mostly empty. That is actually partially an accomplishment of the
> committee, but
> it also shows that we can probably do more to foster progress in GHC.
>
> The only problem I see - and it is the obvious one - is that we have
> historically had sheperds on the committee which were very unresponsive,
> for
> various (probably quite understandable reasons). With more
> responsibilities the
> gap between expectation and delivery would likely increase.
>
> So we should probably only do this if a clear majority of the committee is
> in
> favor. (Or more generally if we can still find enough volunteers to commit
> to
> doing this.) Otherwise we would promise something we can’t deliver.
>
> Now that I am thinking about it we would then need a hopefully clear
> description
> of the responsibilities of the sheperd before submission.
> I think it is sometimes kind of problematic, that there is supposed to be a
> community discussion during preparation of the proposal, but then the
> committee
> is only formally asked to look at it after that discussion happened.
> We should be part of the discussion. Simon has at times pointed us at
> proposals
> in the discussion phase, but maybe there is a slightly more structured way
> to
> do this.
>
> Best
> Malte
> _______________________________________________
> 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/20241030/90366e07/attachment.html>