From zubin at well-typed.com  Tue Mar  5 09:52:03 2024
From: zubin at well-typed.com (Zubin Duggal)
Date: Tue, 5 Mar 2024 15:22:03 +0530
Subject: Upcoming GHC 9.6.5 release
Message-ID: <45etmmvwoh6otfkjgnr6ytnrgvojngshutbdkwu62txs4pfyet@l2whnbzvbbu4>

Hello all,

We are currently in the process of preparing the 9.6.5 release, which
we plan to release before the end of the month.

If you would like any patches to be considered for inclusion into this
release, please ensure that the corresponding MRs are marked with the
~"backport needed:9.6" label.

Requests for any submodule updates should be made on the release
tracking ticket: https://gitlab.haskell.org/ghc/ghc/-/issues/24501

Cheers,
Zubin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20240305/373a5f9a/attachment.sig>

From moritz.angermann at gmail.com  Tue Mar  5 22:46:04 2024
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Wed, 6 Mar 2024 06:46:04 +0800
Subject: Upcoming GHC 9.6.5 release
In-Reply-To: <45etmmvwoh6otfkjgnr6ytnrgvojngshutbdkwu62txs4pfyet@l2whnbzvbbu4>
References: <45etmmvwoh6otfkjgnr6ytnrgvojngshutbdkwu62txs4pfyet@l2whnbzvbbu4>
Message-ID: <CAKfdd-wc2Ty5d=2cgeEPHVpLiZS0JJ90VXgdf6h1ULtcmXQyMA@mail.gmail.com>

Is there a list of tickets that are already going into 9.6.5 that were not
in 9.6.4?

On Tue, 5 Mar 2024 at 5:52 PM, Zubin Duggal <zubin at well-typed.com> wrote:

> Hello all,
>
> We are currently in the process of preparing the 9.6.5 release, which
> we plan to release before the end of the month.
>
> If you would like any patches to be considered for inclusion into this
> release, please ensure that the corresponding MRs are marked with the
> ~"backport needed:9.6" label.
>
> Requests for any submodule updates should be made on the release
> tracking ticket: https://gitlab.haskell.org/ghc/ghc/-/issues/24501
>
> Cheers,
> Zubin
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20240306/3b6e65ef/attachment.html>

From zubin at well-typed.com  Wed Mar  6 14:15:27 2024
From: zubin at well-typed.com (Zubin Duggal)
Date: Wed, 6 Mar 2024 19:45:27 +0530
Subject: Upcoming GHC 9.6.5 release
In-Reply-To: <CAKfdd-wc2Ty5d=2cgeEPHVpLiZS0JJ90VXgdf6h1ULtcmXQyMA@mail.gmail.com>
References: <45etmmvwoh6otfkjgnr6ytnrgvojngshutbdkwu62txs4pfyet@l2whnbzvbbu4>
 <CAKfdd-wc2Ty5d=2cgeEPHVpLiZS0JJ90VXgdf6h1ULtcmXQyMA@mail.gmail.com>
Message-ID: <x3ls55pm4m5icfkp2p3vtp63qxmvfuecmarfhxwkrkpnhrjuc6@jg6mjc5r4cx5>

All the closed merge requests with the label will be backported: https://gitlab.haskell.org/ghc/ghc/-/merge_requests?scope=all&state=closed&label_name[]=backport%20needed%3A9.6

The main motiviation for this release is to fix https://gitlab.haskell.org/ghc/ghc/-/issues/24050
so that the hsc2hs wrapper bundled with bindists is compatible with
more darwin environments.

On 24/03/06 06:46, Moritz Angermann wrote:
>Is there a list of tickets that are already going into 9.6.5 that were not
>in 9.6.4?
>
>On Tue, 5 Mar 2024 at 5:52 PM, Zubin Duggal <zubin at well-typed.com> wrote:
>
>> Hello all,
>>
>> We are currently in the process of preparing the 9.6.5 release, which
>> we plan to release before the end of the month.
>>
>> If you would like any patches to be considered for inclusion into this
>> release, please ensure that the corresponding MRs are marked with the
>> ~"backport needed:9.6" label.
>>
>> Requests for any submodule updates should be made on the release
>> tracking ticket: https://gitlab.haskell.org/ghc/ghc/-/issues/24501
>>
>> Cheers,
>> Zubin
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>

From iavor.diatchki at gmail.com  Sun Mar 10 16:56:20 2024
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Sun, 10 Mar 2024 09:56:20 -0700
Subject: Template Haskell stability
Message-ID: <CAGK9nuqsomUzpcrYQT3zbLrNDi9=F4gUaPKvoicQvm2yT_c7kg@mail.gmail.com>

Hello,

I am not sure if this is the right list to post to, but I suspect
template-haskell is mostly modified by GHC folk, which is why I chose to
post here, and there is no maintainer listed, based just the `libraries`
list.

Template Haskell is a very useful tool, but I am always quite wary of using
it, because it is so unstable.   I understand the need to change the
syntax, as the language evolves, but I feel that changes are made without
any consideration for backward compatibility, which is very unfortunate.

To give you an example, I am currently using GHC 9.6.4, and I am working on
a small TH utility.  I need to make a tuple expression, but of a dynamic
size, so I can't use the special syntax, and need to use a function to do
so.  So I am using the function, `tupE`, which has the following type:

    tupE :: Quote m => [m Exp] -> m Exp

This is quite nice and unsurprising.   When I look oh `hackage`, however,
the type of this function has changed, now it is:

   tupE :: Quote m => [m (Maybe Exp)] -> m Expr

So what do I do?  Basically I should not use this function, because as soon
as I upgrade the compiler everything will break!  Furthermore there is no
documentation at all to explain what this function is supposed to do (I
can't fathom why it is taking `Maybe` as arguments), or when it changed,
etc.

So my plea would be---change the syntax at will, but let's try to keep the
convenience functions that build the syntax stable: instead of changing
functions, it is just as easy to add a new function.  I understand that
sometimes things need to change, but then we should describe what changed,
and in which versions.   I don't think these are hard things to do, and I
really think it will have great benefit to everyone using TH.

Cheers,
-Iavor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20240310/6c6ecc81/attachment.html>

From oleg.grenrus at iki.fi  Sun Mar 10 17:02:01 2024
From: oleg.grenrus at iki.fi (Oleg Grenrus)
Date: Sun, 10 Mar 2024 19:02:01 +0200
Subject: Template Haskell stability
In-Reply-To: <CAGK9nuqsomUzpcrYQT3zbLrNDi9=F4gUaPKvoicQvm2yT_c7kg@mail.gmail.com>
References: <CAGK9nuqsomUzpcrYQT3zbLrNDi9=F4gUaPKvoicQvm2yT_c7kg@mail.gmail.com>
Message-ID: <043033b7-0a6e-4112-c428-f5ecae9240d0@iki.fi>

 > So what do I do?

There are two tupE functions.

In Language.Haskell.TH.Lib.Internal module the type has changed. That's 
the module used by GHC itself, to represent quotations. As the module 
documentation says

 > Language.Haskell.TH.Lib.Internal exposes some additional 
functionality that is used internally in GHC's integration with Template 
Haskell. This is not a part of the public API, and as such, there are no 
API guarantees for this module from version to version.

In the Language.Haskell.TH.Lib module which is documented as

 > Language.Haskell.TH.Lib contains lots of useful helper functions for 
generating and manipulating Template Haskell terms

the type of tupE [1] has been left unchanged, and it's still

    tupE :: Quote m => [m Exp] -> m Exp

[1] 
https://hackage.haskell.org/package/template-haskell-2.21.0.0/docs/Language-Haskell-TH-Lib.html#v:tupE

---

Oleg


On 10.3.2024 18.56, Iavor Diatchki wrote:
> Hello,
>
> I am not sure if this is the right list to post to, but I suspect 
> template-haskell is mostly modified by GHC folk, which is why I chose 
> to post here, and there is no maintainer listed, based just the 
> `libraries` list.
>
> Template Haskell is a very useful tool, but I am always quite wary of 
> using it, because it is so unstable.   I understand the need to change 
> the syntax, as the language evolves, but I feel that changes are made 
> without any consideration for backward compatibility, which is very 
> unfortunate.
>
> To give you an example, I am currently using GHC 9.6.4, and I am 
> working on a small TH utility.  I need to make a tuple expression, but 
> of a dynamic size, so I can't use the special syntax, and need to use 
> a function to do so.  So I am using the function, `tupE`, which has 
> the following type:
>
>     tupE :: Quote m => [m Exp] -> m Exp
>
> This is quite nice and unsurprising.   When I look oh `hackage`, 
> however, the type of this function has changed, now it is:
>
>    tupE :: Quote m => [m (Maybe Exp)] -> m Expr
>
> So what do I do?  Basically I should not use this function, because as 
> soon as I upgrade the compiler everything will break!  Furthermore 
> there is no documentation at all to explain what this function is 
> supposed to do (I can't fathom why it is taking `Maybe` as arguments), 
> or when it changed, etc.
>
> So my plea would be---change the syntax at will, but let's try to keep 
> the convenience functions that build the syntax stable: instead of 
> changing functions, it is just as easy to add a new function.  I 
> understand that sometimes things need to change, but then we should 
> describe what changed, and in which versions.   I don't think these 
> are hard things to do, and I really think it will have great benefit 
> to everyone using TH.
>
> Cheers,
> -Iavor
>
>
>
>
>
>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From iavor.diatchki at gmail.com  Sun Mar 10 17:11:29 2024
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Sun, 10 Mar 2024 10:11:29 -0700
Subject: Template Haskell stability
In-Reply-To: <043033b7-0a6e-4112-c428-f5ecae9240d0@iki.fi>
References: <CAGK9nuqsomUzpcrYQT3zbLrNDi9=F4gUaPKvoicQvm2yT_c7kg@mail.gmail.com>
 <043033b7-0a6e-4112-c428-f5ecae9240d0@iki.fi>
Message-ID: <CAGK9nupw=qu6=yz0DOQEOv34Qmzz1qKJ7AobZv2H7fhvT5pP8g@mail.gmail.com>

Oh, that's really confusing, especially since the internal one is what
shows up first when you search for stuff!

Another example of similar breakage was the changes to binders a little
while ago.

On Sun, Mar 10, 2024 at 10:02 AM Oleg Grenrus <oleg.grenrus at iki.fi> wrote:

>  > So what do I do?
>
> There are two tupE functions.
>
> In Language.Haskell.TH.Lib.Internal module the type has changed. That's
> the module used by GHC itself, to represent quotations. As the module
> documentation says
>
>  > Language.Haskell.TH.Lib.Internal exposes some additional
> functionality that is used internally in GHC's integration with Template
> Haskell. This is not a part of the public API, and as such, there are no
> API guarantees for this module from version to version.
>
> In the Language.Haskell.TH.Lib module which is documented as
>
>  > Language.Haskell.TH.Lib contains lots of useful helper functions for
> generating and manipulating Template Haskell terms
>
> the type of tupE [1] has been left unchanged, and it's still
>
>     tupE :: Quote m => [m Exp] -> m Exp
>
> [1]
>
> https://hackage.haskell.org/package/template-haskell-2.21.0.0/docs/Language-Haskell-TH-Lib.html#v:tupE
>
> ---
>
> Oleg
>
>
> On 10.3.2024 18.56, Iavor Diatchki wrote:
> > Hello,
> >
> > I am not sure if this is the right list to post to, but I suspect
> > template-haskell is mostly modified by GHC folk, which is why I chose
> > to post here, and there is no maintainer listed, based just the
> > `libraries` list.
> >
> > Template Haskell is a very useful tool, but I am always quite wary of
> > using it, because it is so unstable.   I understand the need to change
> > the syntax, as the language evolves, but I feel that changes are made
> > without any consideration for backward compatibility, which is very
> > unfortunate.
> >
> > To give you an example, I am currently using GHC 9.6.4, and I am
> > working on a small TH utility.  I need to make a tuple expression, but
> > of a dynamic size, so I can't use the special syntax, and need to use
> > a function to do so.  So I am using the function, `tupE`, which has
> > the following type:
> >
> >     tupE :: Quote m => [m Exp] -> m Exp
> >
> > This is quite nice and unsurprising.   When I look oh `hackage`,
> > however, the type of this function has changed, now it is:
> >
> >    tupE :: Quote m => [m (Maybe Exp)] -> m Expr
> >
> > So what do I do?  Basically I should not use this function, because as
> > soon as I upgrade the compiler everything will break!  Furthermore
> > there is no documentation at all to explain what this function is
> > supposed to do (I can't fathom why it is taking `Maybe` as arguments),
> > or when it changed, etc.
> >
> > So my plea would be---change the syntax at will, but let's try to keep
> > the convenience functions that build the syntax stable: instead of
> > changing functions, it is just as easy to add a new function.  I
> > understand that sometimes things need to change, but then we should
> > describe what changed, and in which versions.   I don't think these
> > are hard things to do, and I really think it will have great benefit
> > to everyone using TH.
> >
> > Cheers,
> > -Iavor
> >
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20240310/d593f14a/attachment.html>

From teofilcamarasu at gmail.com  Sun Mar 10 17:54:02 2024
From: teofilcamarasu at gmail.com (Teofil Camarasu)
Date: Sun, 10 Mar 2024 17:54:02 +0000
Subject: Template Haskell stability
In-Reply-To: <CAGK9nupw=qu6=yz0DOQEOv34Qmzz1qKJ7AobZv2H7fhvT5pP8g@mail.gmail.com>
References: <CAGK9nuqsomUzpcrYQT3zbLrNDi9=F4gUaPKvoicQvm2yT_c7kg@mail.gmail.com>
 <043033b7-0a6e-4112-c428-f5ecae9240d0@iki.fi>
 <CAGK9nupw=qu6=yz0DOQEOv34Qmzz1qKJ7AobZv2H7fhvT5pP8g@mail.gmail.com>
Message-ID: <CAPBO51H6dSU5CfRPnacAdPUXy81RDSDhZeb7F25Tg51NoNATAw@mail.gmail.com>

There's been a bit of discussion about template haskell stability on this
issue that you might find interesting:
https://gitlab.haskell.org/ghc/ghc/-/issues/24021

Cheers,
Teo

On Sun, Mar 10, 2024 at 5:11 PM Iavor Diatchki <iavor.diatchki at gmail.com>
wrote:

> Oh, that's really confusing, especially since the internal one is what
> shows up first when you search for stuff!
>
> Another example of similar breakage was the changes to binders a little
> while ago.
>
> On Sun, Mar 10, 2024 at 10:02 AM Oleg Grenrus <oleg.grenrus at iki.fi> wrote:
>
>>  > So what do I do?
>>
>> There are two tupE functions.
>>
>> In Language.Haskell.TH.Lib.Internal module the type has changed. That's
>> the module used by GHC itself, to represent quotations. As the module
>> documentation says
>>
>>  > Language.Haskell.TH.Lib.Internal exposes some additional
>> functionality that is used internally in GHC's integration with Template
>> Haskell. This is not a part of the public API, and as such, there are no
>> API guarantees for this module from version to version.
>>
>> In the Language.Haskell.TH.Lib module which is documented as
>>
>>  > Language.Haskell.TH.Lib contains lots of useful helper functions for
>> generating and manipulating Template Haskell terms
>>
>> the type of tupE [1] has been left unchanged, and it's still
>>
>>     tupE :: Quote m => [m Exp] -> m Exp
>>
>> [1]
>>
>> https://hackage.haskell.org/package/template-haskell-2.21.0.0/docs/Language-Haskell-TH-Lib.html#v:tupE
>>
>> ---
>>
>> Oleg
>>
>>
>> On 10.3.2024 18.56, Iavor Diatchki wrote:
>> > Hello,
>> >
>> > I am not sure if this is the right list to post to, but I suspect
>> > template-haskell is mostly modified by GHC folk, which is why I chose
>> > to post here, and there is no maintainer listed, based just the
>> > `libraries` list.
>> >
>> > Template Haskell is a very useful tool, but I am always quite wary of
>> > using it, because it is so unstable.   I understand the need to change
>> > the syntax, as the language evolves, but I feel that changes are made
>> > without any consideration for backward compatibility, which is very
>> > unfortunate.
>> >
>> > To give you an example, I am currently using GHC 9.6.4, and I am
>> > working on a small TH utility.  I need to make a tuple expression, but
>> > of a dynamic size, so I can't use the special syntax, and need to use
>> > a function to do so.  So I am using the function, `tupE`, which has
>> > the following type:
>> >
>> >     tupE :: Quote m => [m Exp] -> m Exp
>> >
>> > This is quite nice and unsurprising.   When I look oh `hackage`,
>> > however, the type of this function has changed, now it is:
>> >
>> >    tupE :: Quote m => [m (Maybe Exp)] -> m Expr
>> >
>> > So what do I do?  Basically I should not use this function, because as
>> > soon as I upgrade the compiler everything will break!  Furthermore
>> > there is no documentation at all to explain what this function is
>> > supposed to do (I can't fathom why it is taking `Maybe` as arguments),
>> > or when it changed, etc.
>> >
>> > So my plea would be---change the syntax at will, but let's try to keep
>> > the convenience functions that build the syntax stable: instead of
>> > changing functions, it is just as easy to add a new function.  I
>> > understand that sometimes things need to change, but then we should
>> > describe what changed, and in which versions.   I don't think these
>> > are hard things to do, and I really think it will have great benefit
>> > to everyone using TH.
>> >
>> > Cheers,
>> > -Iavor
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > ghc-devs mailing list
>> > ghc-devs at haskell.org
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20240310/3c3dcbb7/attachment.html>

From oleg.grenrus at iki.fi  Sun Mar 10 17:59:11 2024
From: oleg.grenrus at iki.fi (Oleg Grenrus)
Date: Sun, 10 Mar 2024 19:59:11 +0200
Subject: Template Haskell stability
In-Reply-To: <CAGK9nupw=qu6=yz0DOQEOv34Qmzz1qKJ7AobZv2H7fhvT5pP8g@mail.gmail.com>
References: <CAGK9nuqsomUzpcrYQT3zbLrNDi9=F4gUaPKvoicQvm2yT_c7kg@mail.gmail.com>
 <043033b7-0a6e-4112-c428-f5ecae9240d0@iki.fi>
 <CAGK9nupw=qu6=yz0DOQEOv34Qmzz1qKJ7AobZv2H7fhvT5pP8g@mail.gmail.com>
Message-ID: <a8c56374-8e6b-a074-efb5-8e92830a59d3@iki.fi>

 > Another example of similar breakage was the changes to binders a 
little while ago.

If you read GHC migration guide for 9.8 [1] (migration guides have been 
great resources, thanks to all their writers), it says

 > It is possible that Template Haskell code which compiled prior to GHC 
9.8 will no longer compile after these changes. Here are some possible 
ways to make it compile with 9.8 in a backwards-compatible way, inspired 
by head.hackage!302 (merged):

 > * Construct TyVarBndrs using plainTV or kindedTV from 
Language.Haskell.TH.Lib, which is polymorphic over both TyVarBndr () and 
TyVarBndr BndrVis. These functions will default to using BndrReq on GHC 9.8.
 > * The th-abstraction [2] library provides a compatibility layer in 
the Language.Haskell.TH.Datatype.TyVarBndr module.

[1] 
https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/9.8#invisible-binders-in-type-level-declarations
[2] https://hackage.haskell.org/package/th-abstraction

In my personal opinion, the development of `template-haskell` hits the 
sweet spot of evolving (i.e. keeping up with GHC changes, and not 
stagnating), but being very reasonable in their breakages and also 
guiding how to migrate.

Of course, the template-haskell library documentation could always be 
better, e.g. `TyVarBndr` docs could mention that things have changed and 
provide a link to migration guide;  tupE docs could mention existence of 
another variant and so on. However given that `template-haskell` doesn't 
really have an owner, and changes are mostly forced by changes in GHC, 
i'm very happy with what we have now. (In particular I hate the 
`template-haskell-internal` idea mentioned in 
https://gitlab.haskell.org/ghc/ghc/-/issues/24021; it won't help me with 
e.g. aeson but complicate contributing to GHC, lose-lose).

That said, is it possible to setup the similar API change test for 
`template-haskell` as we have for `base`? I think it won't hurt, and may 
nudge contributors to document the changes.

Cheers, Oleg


On 10.3.2024 19.11, Iavor Diatchki wrote:
> Oh, that's really confusing, especially since the internal one is what 
> shows up first when you search for stuff!
>
> Another example of similar breakage was the changes to binders a 
> little while ago.
>
> On Sun, Mar 10, 2024 at 10:02 AM Oleg Grenrus <oleg.grenrus at iki.fi> wrote:
>
>      > So what do I do?
>
>     There are two tupE functions.
>
>     In Language.Haskell.TH.Lib.Internal module the type has changed.
>     That's
>     the module used by GHC itself, to represent quotations. As the module
>     documentation says
>
>      > Language.Haskell.TH.Lib.Internal exposes some additional
>     functionality that is used internally in GHC's integration with
>     Template
>     Haskell. This is not a part of the public API, and as such, there
>     are no
>     API guarantees for this module from version to version.
>
>     In the Language.Haskell.TH.Lib module which is documented as
>
>      > Language.Haskell.TH.Lib contains lots of useful helper
>     functions for
>     generating and manipulating Template Haskell terms
>
>     the type of tupE [1] has been left unchanged, and it's still
>
>         tupE :: Quote m => [m Exp] -> m Exp
>
>     [1]
>     https://hackage.haskell.org/package/template-haskell-2.21.0.0/docs/Language-Haskell-TH-Lib.html#v:tupE
>
>     ---
>
>     Oleg
>
>
>     On 10.3.2024 18.56, Iavor Diatchki wrote:
>     > Hello,
>     >
>     > I am not sure if this is the right list to post to, but I suspect
>     > template-haskell is mostly modified by GHC folk, which is why I
>     chose
>     > to post here, and there is no maintainer listed, based just the
>     > `libraries` list.
>     >
>     > Template Haskell is a very useful tool, but I am always quite
>     wary of
>     > using it, because it is so unstable.   I understand the need to
>     change
>     > the syntax, as the language evolves, but I feel that changes are
>     made
>     > without any consideration for backward compatibility, which is very
>     > unfortunate.
>     >
>     > To give you an example, I am currently using GHC 9.6.4, and I am
>     > working on a small TH utility.  I need to make a tuple
>     expression, but
>     > of a dynamic size, so I can't use the special syntax, and need
>     to use
>     > a function to do so.  So I am using the function, `tupE`, which has
>     > the following type:
>     >
>     >     tupE :: Quote m => [m Exp] -> m Exp
>     >
>     > This is quite nice and unsurprising.   When I look oh `hackage`,
>     > however, the type of this function has changed, now it is:
>     >
>     >    tupE :: Quote m => [m (Maybe Exp)] -> m Expr
>     >
>     > So what do I do?  Basically I should not use this function,
>     because as
>     > soon as I upgrade the compiler everything will break! Furthermore
>     > there is no documentation at all to explain what this function is
>     > supposed to do (I can't fathom why it is taking `Maybe` as
>     arguments),
>     > or when it changed, etc.
>     >
>     > So my plea would be---change the syntax at will, but let's try
>     to keep
>     > the convenience functions that build the syntax stable: instead of
>     > changing functions, it is just as easy to add a new function.  I
>     > understand that sometimes things need to change, but then we should
>     > describe what changed, and in which versions.   I don't think these
>     > are hard things to do, and I really think it will have great
>     benefit
>     > to everyone using TH.
>     >
>     > Cheers,
>     > -Iavor
>     >
>     >
>     >
>     >
>     >
>     >
>     >
>     >
>     > _______________________________________________
>     > ghc-devs mailing list
>     > ghc-devs at haskell.org
>     > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>     _______________________________________________
>     ghc-devs mailing list
>     ghc-devs at haskell.org
>     http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20240310/ec223cdb/attachment.html>

From iavor.diatchki at gmail.com  Sun Mar 10 20:40:47 2024
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Sun, 10 Mar 2024 13:40:47 -0700
Subject: Template Haskell stability
In-Reply-To: <a8c56374-8e6b-a074-efb5-8e92830a59d3@iki.fi>
References: <CAGK9nuqsomUzpcrYQT3zbLrNDi9=F4gUaPKvoicQvm2yT_c7kg@mail.gmail.com>
 <043033b7-0a6e-4112-c428-f5ecae9240d0@iki.fi>
 <CAGK9nupw=qu6=yz0DOQEOv34Qmzz1qKJ7AobZv2H7fhvT5pP8g@mail.gmail.com>
 <a8c56374-8e6b-a074-efb5-8e92830a59d3@iki.fi>
Message-ID: <CAGK9nurXwHF9CTkp6BPi4r_2sPm_wTMmr_QopA-0Y_KEtj7Rpg@mail.gmail.com>

While having migration instructions is useful, not having to do anything is
even better.  I am already using `th-abstraction`, but I wish I didn't have
to use 2 libraries, that kind of do that same thing.  For the sake of
concreteness, consider how the type of `dataD` has evolved:

(2.3) dataD :: CxtQ -> Name -> [Name] -> [ConQ] -> [Name] -> DecQ
(2.4) dataD :: CxtQ -> Name -> [TyVarBndr] -> [ConQ] -> [Name] -> DecQ
(2.17) dataD :: Quote m => m Cxt -> Name -> [TyVarBndr ()] -> Maybe Kind ->
[m Con] -> [m DerivClause] -> m Dec

To find these changes I had to perform binary search on the versions on
`hackage`.

My suggestion would be to:

  1) Avoid such changes whenever possible.  For example:
    *  in 2.4 we could have kept the type signature of `dataD` as (it would
make a plain type binder), and added a new function `dataDTyVarBnd` for the
new behavior
    * In 2.17 We could have made a new type `TyVarBndrVis`, and made a type
synonym for `type TyVarBndr = TyVarBndrVis ()` to have the default
visibility that was there before the change.
  2) When we do need to make changes, we should annotate clearly when the
change happened in the haddocks, so that when we need to fix something in
the future, we minimize the amount of archeology that needs to be done.










On Sun, Mar 10, 2024 at 10:59 AM Oleg Grenrus <oleg.grenrus at iki.fi> wrote:

> > Another example of similar breakage was the changes to binders a little
> while ago.
>
> If you read GHC migration guide for 9.8 [1] (migration guides have been
> great resources, thanks to all their writers), it says
>
> > It is possible that Template Haskell code which compiled prior to GHC
> 9.8 will no longer compile after these changes. Here are some possible ways
> to make it compile with 9.8 in a backwards-compatible way, inspired by
> head.hackage!302 (merged):
>
> > * Construct TyVarBndrs using plainTV or kindedTV from
> Language.Haskell.TH.Lib, which is polymorphic over both TyVarBndr () and
> TyVarBndr BndrVis. These functions will default to using BndrReq on GHC 9.8.
> > * The th-abstraction [2] library provides a compatibility layer in the
> Language.Haskell.TH.Datatype.TyVarBndr module.
>
> [1]
> https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/9.8#invisible-binders-in-type-level-declarations
> [2] https://hackage.haskell.org/package/th-abstraction
> In my personal opinion, the development of `template-haskell` hits the
> sweet spot of evolving (i.e. keeping up with GHC changes, and not
> stagnating), but being very reasonable in their breakages and also guiding
> how to migrate.
>
> Of course, the template-haskell library documentation could always be
> better, e.g. `TyVarBndr` docs could mention that things have changed and
> provide a link to migration guide;  tupE docs could mention existence of
> another variant and so on. However given that `template-haskell` doesn't
> really have an owner, and changes are mostly forced by changes in GHC, i'm
> very happy with what we have now. (In particular I hate the
> `template-haskell-internal` idea mentioned in
> https://gitlab.haskell.org/ghc/ghc/-/issues/24021; it won't help me with
> e.g. aeson but complicate contributing to GHC, lose-lose).
>
> That said, is it possible to setup the similar API change test for
> `template-haskell` as we have for `base`? I think it won't hurt, and may
> nudge contributors to document the changes.
>
> Cheers, Oleg
>
>
> On 10.3.2024 19.11, Iavor Diatchki wrote:
>
> Oh, that's really confusing, especially since the internal one is what
> shows up first when you search for stuff!
>
> Another example of similar breakage was the changes to binders a little
> while ago.
>
> On Sun, Mar 10, 2024 at 10:02 AM Oleg Grenrus <oleg.grenrus at iki.fi> wrote:
>
>>  > So what do I do?
>>
>> There are two tupE functions.
>>
>> In Language.Haskell.TH.Lib.Internal module the type has changed. That's
>> the module used by GHC itself, to represent quotations. As the module
>> documentation says
>>
>>  > Language.Haskell.TH.Lib.Internal exposes some additional
>> functionality that is used internally in GHC's integration with Template
>> Haskell. This is not a part of the public API, and as such, there are no
>> API guarantees for this module from version to version.
>>
>> In the Language.Haskell.TH.Lib module which is documented as
>>
>>  > Language.Haskell.TH.Lib contains lots of useful helper functions for
>> generating and manipulating Template Haskell terms
>>
>> the type of tupE [1] has been left unchanged, and it's still
>>
>>     tupE :: Quote m => [m Exp] -> m Exp
>>
>> [1]
>>
>> https://hackage.haskell.org/package/template-haskell-2.21.0.0/docs/Language-Haskell-TH-Lib.html#v:tupE
>>
>> ---
>>
>> Oleg
>>
>>
>> On 10.3.2024 18.56, Iavor Diatchki wrote:
>> > Hello,
>> >
>> > I am not sure if this is the right list to post to, but I suspect
>> > template-haskell is mostly modified by GHC folk, which is why I chose
>> > to post here, and there is no maintainer listed, based just the
>> > `libraries` list.
>> >
>> > Template Haskell is a very useful tool, but I am always quite wary of
>> > using it, because it is so unstable.   I understand the need to change
>> > the syntax, as the language evolves, but I feel that changes are made
>> > without any consideration for backward compatibility, which is very
>> > unfortunate.
>> >
>> > To give you an example, I am currently using GHC 9.6.4, and I am
>> > working on a small TH utility.  I need to make a tuple expression, but
>> > of a dynamic size, so I can't use the special syntax, and need to use
>> > a function to do so.  So I am using the function, `tupE`, which has
>> > the following type:
>> >
>> >     tupE :: Quote m => [m Exp] -> m Exp
>> >
>> > This is quite nice and unsurprising.   When I look oh `hackage`,
>> > however, the type of this function has changed, now it is:
>> >
>> >    tupE :: Quote m => [m (Maybe Exp)] -> m Expr
>> >
>> > So what do I do?  Basically I should not use this function, because as
>> > soon as I upgrade the compiler everything will break!  Furthermore
>> > there is no documentation at all to explain what this function is
>> > supposed to do (I can't fathom why it is taking `Maybe` as arguments),
>> > or when it changed, etc.
>> >
>> > So my plea would be---change the syntax at will, but let's try to keep
>> > the convenience functions that build the syntax stable: instead of
>> > changing functions, it is just as easy to add a new function.  I
>> > understand that sometimes things need to change, but then we should
>> > describe what changed, and in which versions.   I don't think these
>> > are hard things to do, and I really think it will have great benefit
>> > to everyone using TH.
>> >
>> > Cheers,
>> > -Iavor
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > ghc-devs mailing list
>> > ghc-devs at haskell.org
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20240310/9f7f73d2/attachment.html>

From simon.peytonjones at gmail.com  Mon Mar 11 08:43:26 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Mon, 11 Mar 2024 08:43:26 +0000
Subject: Template Haskell stability
In-Reply-To: <CAGK9nurXwHF9CTkp6BPi4r_2sPm_wTMmr_QopA-0Y_KEtj7Rpg@mail.gmail.com>
References: <CAGK9nuqsomUzpcrYQT3zbLrNDi9=F4gUaPKvoicQvm2yT_c7kg@mail.gmail.com>
 <043033b7-0a6e-4112-c428-f5ecae9240d0@iki.fi>
 <CAGK9nupw=qu6=yz0DOQEOv34Qmzz1qKJ7AobZv2H7fhvT5pP8g@mail.gmail.com>
 <a8c56374-8e6b-a074-efb5-8e92830a59d3@iki.fi>
 <CAGK9nurXwHF9CTkp6BPi4r_2sPm_wTMmr_QopA-0Y_KEtj7Rpg@mail.gmail.com>
Message-ID: <CAJKmMz_Esd1-81mHzLozwjojTaR+7ZYsBkE_SScBO7js8XPiKQ@mail.gmail.com>

>
>     *  in 2.4 we could have kept the type signature of `dataD` as (it
> would make a plain type binder), and added a new function `dataDTyVarBnd`
> for the new behavior


Iavor, what about *pattern matching *on DataD?   Or don't you do that?

If we exclude pattern matching on TH syntax, it becomes much more feasible
to make a stable API.  Is that a goal worth seeking?  Would it help a few
people?  A lot of people?

Simon

On Sun, 10 Mar 2024 at 20:41, Iavor Diatchki <iavor.diatchki at gmail.com>
wrote:

> While having migration instructions is useful, not having to do anything
> is even better.  I am already using `th-abstraction`, but I wish I didn't
> have to use 2 libraries, that kind of do that same thing.  For the sake of
> concreteness, consider how the type of `dataD` has evolved:
>
> (2.3) dataD :: CxtQ -> Name -> [Name] -> [ConQ] -> [Name] -> DecQ
> (2.4) dataD :: CxtQ -> Name -> [TyVarBndr] -> [ConQ] -> [Name] -> DecQ
> (2.17) dataD :: Quote m => m Cxt -> Name -> [TyVarBndr ()] -> Maybe Kind
> -> [m Con] -> [m DerivClause] -> m Dec
>
> To find these changes I had to perform binary search on the versions on
> `hackage`.
>
> My suggestion would be to:
>
>   1) Avoid such changes whenever possible.  For example:
>     *  in 2.4 we could have kept the type signature of `dataD` as (it
> would make a plain type binder), and added a new function `dataDTyVarBnd`
> for the new behavior
>     * In 2.17 We could have made a new type `TyVarBndrVis`, and made a
> type synonym for `type TyVarBndr = TyVarBndrVis ()` to have the default
> visibility that was there before the change.
>   2) When we do need to make changes, we should annotate clearly when the
> change happened in the haddocks, so that when we need to fix something in
> the future, we minimize the amount of archeology that needs to be done.
>
>
>
>
>
>
>
>
>
>
> On Sun, Mar 10, 2024 at 10:59 AM Oleg Grenrus <oleg.grenrus at iki.fi> wrote:
>
>> > Another example of similar breakage was the changes to binders a little
>> while ago.
>>
>> If you read GHC migration guide for 9.8 [1] (migration guides have been
>> great resources, thanks to all their writers), it says
>>
>> > It is possible that Template Haskell code which compiled prior to GHC
>> 9.8 will no longer compile after these changes. Here are some possible ways
>> to make it compile with 9.8 in a backwards-compatible way, inspired by
>> head.hackage!302 (merged):
>>
>> > * Construct TyVarBndrs using plainTV or kindedTV from
>> Language.Haskell.TH.Lib, which is polymorphic over both TyVarBndr () and
>> TyVarBndr BndrVis. These functions will default to using BndrReq on GHC 9.8.
>> > * The th-abstraction [2] library provides a compatibility layer in the
>> Language.Haskell.TH.Datatype.TyVarBndr module.
>>
>> [1]
>> https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/9.8#invisible-binders-in-type-level-declarations
>> [2] https://hackage.haskell.org/package/th-abstraction
>> In my personal opinion, the development of `template-haskell` hits the
>> sweet spot of evolving (i.e. keeping up with GHC changes, and not
>> stagnating), but being very reasonable in their breakages and also guiding
>> how to migrate.
>>
>> Of course, the template-haskell library documentation could always be
>> better, e.g. `TyVarBndr` docs could mention that things have changed and
>> provide a link to migration guide;  tupE docs could mention existence of
>> another variant and so on. However given that `template-haskell` doesn't
>> really have an owner, and changes are mostly forced by changes in GHC, i'm
>> very happy with what we have now. (In particular I hate the
>> `template-haskell-internal` idea mentioned in
>> https://gitlab.haskell.org/ghc/ghc/-/issues/24021; it won't help me with
>> e.g. aeson but complicate contributing to GHC, lose-lose).
>>
>> That said, is it possible to setup the similar API change test for
>> `template-haskell` as we have for `base`? I think it won't hurt, and may
>> nudge contributors to document the changes.
>>
>> Cheers, Oleg
>>
>>
>> On 10.3.2024 19.11, Iavor Diatchki wrote:
>>
>> Oh, that's really confusing, especially since the internal one is what
>> shows up first when you search for stuff!
>>
>> Another example of similar breakage was the changes to binders a little
>> while ago.
>>
>> On Sun, Mar 10, 2024 at 10:02 AM Oleg Grenrus <oleg.grenrus at iki.fi>
>> wrote:
>>
>>>  > So what do I do?
>>>
>>> There are two tupE functions.
>>>
>>> In Language.Haskell.TH.Lib.Internal module the type has changed. That's
>>> the module used by GHC itself, to represent quotations. As the module
>>> documentation says
>>>
>>>  > Language.Haskell.TH.Lib.Internal exposes some additional
>>> functionality that is used internally in GHC's integration with Template
>>> Haskell. This is not a part of the public API, and as such, there are no
>>> API guarantees for this module from version to version.
>>>
>>> In the Language.Haskell.TH.Lib module which is documented as
>>>
>>>  > Language.Haskell.TH.Lib contains lots of useful helper functions for
>>> generating and manipulating Template Haskell terms
>>>
>>> the type of tupE [1] has been left unchanged, and it's still
>>>
>>>     tupE :: Quote m => [m Exp] -> m Exp
>>>
>>> [1]
>>>
>>> https://hackage.haskell.org/package/template-haskell-2.21.0.0/docs/Language-Haskell-TH-Lib.html#v:tupE
>>>
>>> ---
>>>
>>> Oleg
>>>
>>>
>>> On 10.3.2024 18.56, Iavor Diatchki wrote:
>>> > Hello,
>>> >
>>> > I am not sure if this is the right list to post to, but I suspect
>>> > template-haskell is mostly modified by GHC folk, which is why I chose
>>> > to post here, and there is no maintainer listed, based just the
>>> > `libraries` list.
>>> >
>>> > Template Haskell is a very useful tool, but I am always quite wary of
>>> > using it, because it is so unstable.   I understand the need to change
>>> > the syntax, as the language evolves, but I feel that changes are made
>>> > without any consideration for backward compatibility, which is very
>>> > unfortunate.
>>> >
>>> > To give you an example, I am currently using GHC 9.6.4, and I am
>>> > working on a small TH utility.  I need to make a tuple expression, but
>>> > of a dynamic size, so I can't use the special syntax, and need to use
>>> > a function to do so.  So I am using the function, `tupE`, which has
>>> > the following type:
>>> >
>>> >     tupE :: Quote m => [m Exp] -> m Exp
>>> >
>>> > This is quite nice and unsurprising.   When I look oh `hackage`,
>>> > however, the type of this function has changed, now it is:
>>> >
>>> >    tupE :: Quote m => [m (Maybe Exp)] -> m Expr
>>> >
>>> > So what do I do?  Basically I should not use this function, because as
>>> > soon as I upgrade the compiler everything will break!  Furthermore
>>> > there is no documentation at all to explain what this function is
>>> > supposed to do (I can't fathom why it is taking `Maybe` as arguments),
>>> > or when it changed, etc.
>>> >
>>> > So my plea would be---change the syntax at will, but let's try to keep
>>> > the convenience functions that build the syntax stable: instead of
>>> > changing functions, it is just as easy to add a new function.  I
>>> > understand that sometimes things need to change, but then we should
>>> > describe what changed, and in which versions.   I don't think these
>>> > are hard things to do, and I really think it will have great benefit
>>> > to everyone using TH.
>>> >
>>> > Cheers,
>>> > -Iavor
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > ghc-devs mailing list
>>> > ghc-devs at haskell.org
>>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>
>> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20240311/20e3c690/attachment-0001.html>

From ietf-dane at dukhovni.org  Mon Mar 11 09:27:23 2024
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Mon, 11 Mar 2024 05:27:23 -0400
Subject: Template Haskell stability
In-Reply-To: <CAJKmMz_Esd1-81mHzLozwjojTaR+7ZYsBkE_SScBO7js8XPiKQ@mail.gmail.com>
References: <CAGK9nuqsomUzpcrYQT3zbLrNDi9=F4gUaPKvoicQvm2yT_c7kg@mail.gmail.com>
 <043033b7-0a6e-4112-c428-f5ecae9240d0@iki.fi>
 <CAGK9nupw=qu6=yz0DOQEOv34Qmzz1qKJ7AobZv2H7fhvT5pP8g@mail.gmail.com>
 <a8c56374-8e6b-a074-efb5-8e92830a59d3@iki.fi>
 <CAGK9nurXwHF9CTkp6BPi4r_2sPm_wTMmr_QopA-0Y_KEtj7Rpg@mail.gmail.com>
 <CAJKmMz_Esd1-81mHzLozwjojTaR+7ZYsBkE_SScBO7js8XPiKQ@mail.gmail.com>
Message-ID: <Ze7Oe6st2ABEVHGL@chardros.imrryr.org>

On Mon, Mar 11, 2024 at 08:43:26AM +0000, Simon Peyton Jones wrote:

> >     *  in 2.4 we could have kept the type signature of `dataD` as (it
> > would make a plain type binder), and added a new function `dataDTyVarBnd`
> > for the new behavior
> 
> 
> Iavor, what about *pattern matching *on DataD?   Or don't you do that?
> 
> If we exclude pattern matching on TH syntax, it becomes much more feasible
> to make a stable API.  Is that a goal worth seeking?  Would it help a few
> people?  A lot of people?

Can't speak for anyone else, but I would find stable API combinators
quite helpful.  Pattern matching the constructors falls outside my
modest needs.

Can't say Whether that materially changes barriers to adopting new GHC
releases across the ecosystem, since this would have to also simplify
migration for various widely used libraries, and I hope their
maintainers will contribute to the thread.

-- 
    Viktor.

From sgraf1337 at gmail.com  Mon Mar 11 10:19:27 2024
From: sgraf1337 at gmail.com (Sebastian Graf)
Date: Mon, 11 Mar 2024 10:19:27 +0000
Subject: Template Haskell stability
In-Reply-To: <Ze7Oe6st2ABEVHGL@chardros.imrryr.org>
References: <CAGK9nuqsomUzpcrYQT3zbLrNDi9=F4gUaPKvoicQvm2yT_c7kg@mail.gmail.com>
 <043033b7-0a6e-4112-c428-f5ecae9240d0@iki.fi>
 <CAGK9nupw=qu6=yz0DOQEOv34Qmzz1qKJ7AobZv2H7fhvT5pP8g@mail.gmail.com>
 <a8c56374-8e6b-a074-efb5-8e92830a59d3@iki.fi>
 <CAGK9nurXwHF9CTkp6BPi4r_2sPm_wTMmr_QopA-0Y_KEtj7Rpg@mail.gmail.com>
 <CAJKmMz_Esd1-81mHzLozwjojTaR+7ZYsBkE_SScBO7js8XPiKQ@mail.gmail.com>
 <Ze7Oe6st2ABEVHGL@chardros.imrryr.org>
Message-ID: <em559604a2-53ba-4fd4-ba07-95561a324f29@sebastian-pc>

Hi,

I submitted my reply in 
https://gitlab.haskell.org/ghc/ghc/-/issues/24021#note_552390.
TLDR; we should focus on pattern quotes in order to improve stability of 
the TH interface; once we reach parity with the pattern quotes of Lean, 
Iavor can easily and stably manipulate tuples of arbitrary arity as 
well.

Cheers,
Sebastian

------ Originalnachricht ------
Von: "Viktor Dukhovni" <ietf-dane at dukhovni.org>
An: ghc-devs at haskell.org
Gesendet: 11.03.2024 10:27:23
Betreff: Re: Template Haskell stability

>On Mon, Mar 11, 2024 at 08:43:26AM +0000, Simon Peyton Jones wrote:
>
>>  >     *  in 2.4 we could have kept the type signature of `dataD` as (it
>>  > would make a plain type binder), and added a new function `dataDTyVarBnd`
>>  > for the new behavior
>>
>>
>>  Iavor, what about *pattern matching *on DataD?   Or don't you do that?
>>
>>  If we exclude pattern matching on TH syntax, it becomes much more feasible
>>  to make a stable API.  Is that a goal worth seeking?  Would it help a few
>>  people?  A lot of people?
>
>Can't speak for anyone else, but I would find stable API combinators
>quite helpful.  Pattern matching the constructors falls outside my
>modest needs.
>
>Can't say Whether that materially changes barriers to adopting new GHC
>releases across the ecosystem, since this would have to also simplify
>migration for various widely used libraries, and I hope their
>maintainers will contribute to the thread.
>
>--
>     Viktor.
>_______________________________________________
>ghc-devs mailing list
>ghc-devs at haskell.org
>http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


From ben at well-typed.com  Wed Mar 13 23:11:02 2024
From: ben at well-typed.com (Ben Gamari)
Date: Wed, 13 Mar 2024 19:11:02 -0400
Subject: [ANNOUNCE] GHC 9.10.1-alpha1 is now available
Message-ID: <871q8dd8xo.fsf@smart-cactus.org>


The GHC developers are very pleased to announce the availability
of the first alpha release of GHC 9.10.1. Binary distributions, source
distributions, and documentation are available at

            https://downloads.haskell.org/ghc/9.10.1-alpha1

We hope to have this release available via ghcup shortly.

GHC 9.10 will bring a number of new features and improvements, including:

 * The introduction of the GHC2024 language edition, building upon
   GHC2021 with the addition of a number of widely-used extensions.

 * Partial implementation of the [GHC Proposal #281], allowing visible
   quantification to be used in the types of terms.

 * Extension of LinearTypes to allow linear `let` and `where` bindings
   ([linear-let])

 * The implementation of the exception backtrace proposal, allowing
   the annotation of exceptions with backtraces, as well as other
   user-defined context [exception backtrace]

 * Further improvements in the info table provenance mechanism, reducing
   code size to allow IPE information to be enabled more widely

 * Javascript FFI support in the WebAssembly backend

 * Improvements in the fragmentation characteristics of the low-latency
   non-moving garbage collector.

 * ... and many more

A full accounting of changes can be found in the [release notes].
As always, GHC's release status, including planned future releases, can
be found on the GHC Wiki [status].

Many will notice that this release comes a fair bit later than the
previously-announced schedule. While this delay has been attributable to
a variety factors, the most recent cause is a set of issues with GHC
9.10's binary distributions on Windows (#24542). Instead of continuing
to hold up the release process while we sort out this situation, we have
instead provided this alpha without the usual assortment of Windows
binary distributions. We expect to have this resolved by alpha 2;
apologies to eager Windows testers for this delay.

We would like to thank GitHub, IOG, the Zw3rk stake pool,
Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell
Foundation, and other anonymous contributors whose on-going financial
and in-kind support has facilitated GHC maintenance and release
management over the years. Finally, this release would not have been
possible without the hundreds of open-source contributors whose work
comprise this release.

As always, do give this release a try and open a [ticket] if you see
anything amiss.

Happy compiling,

~ Ben


[release notes]: https://downloads.haskell.org/ghc/9.10.1-alpha1/docs/users_guide/9.10.1-notes.html
[status]: https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status
[exception backtrace]: https://github.com/ghc-proposals/ghc-proposals/pull/330
[GHC Proposal #281]: https://github.com/ghc-proposals/ghc-proposals/pull/281
[linear let]: https://github.com/ghc-proposals/ghc-proposals/pull/624
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20240313/473afe7c/attachment.sig>

From juhpetersen at gmail.com  Thu Mar 14 09:17:56 2024
From: juhpetersen at gmail.com (Jens Petersen)
Date: Thu, 14 Mar 2024 17:17:56 +0800
Subject: [ANNOUNCE] GHC 9.10.1-alpha1 is now available
In-Reply-To: <871q8dd8xo.fsf@smart-cactus.org>
References: <871q8dd8xo.fsf@smart-cactus.org>
Message-ID: <CAEDGBqKdU62byC5ocr=R2vCNc8sACYeBWJA_1hNjYp5eHgaP+g@mail.gmail.com>

Thanks for the release!

Two smaller points:

   - I noticed the version of parsec seems downgraded wrt to 9.8(.2):
   perhaps I should check gitlab and open a ticket
   - The release should mention the minimum boot version is 9.6? (hadrian
   also requires Cabal-3.10)
   (because of this I can't build yet for Fedora, until I update to ghc-9.6)

Cheers, Jens
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20240314/34b14154/attachment.html>

From juhpetersen at gmail.com  Fri Mar 15 07:09:52 2024
From: juhpetersen at gmail.com (Jens Petersen)
Date: Fri, 15 Mar 2024 15:09:52 +0800
Subject: [ANNOUNCE] GHC 9.10.1-alpha1 is now available
In-Reply-To: <CAEDGBqKdU62byC5ocr=R2vCNc8sACYeBWJA_1hNjYp5eHgaP+g@mail.gmail.com>
References: <871q8dd8xo.fsf@smart-cactus.org>
 <CAEDGBqKdU62byC5ocr=R2vCNc8sACYeBWJA_1hNjYp5eHgaP+g@mail.gmail.com>
Message-ID: <CAEDGBqKen9uX4Fn36ZB9asX5tjx_wqEq+c7FQj-EyaunApA=ng@mail.gmail.com>

On Thu, 14 Mar 2024 at 17:17, Jens Petersen <juhpetersen at gmail.com> wrote:

> Two smaller points:
>

Well I think I downplayed the second bullet too much

>
>    - The release should mention the minimum boot version is 9.6? (hadrian
>    also requires Cabal-3.10)
>    (because of this I can't build yet for Fedora, until I update to
>    ghc-9.6)
>
> It is actually kind of a big deal in the sense I can build ghc9.8 for all
current Fedora releases and EPEL 9 (ie for RHEL 9)
but 9.10 will only be buildable for Fedora 41 (which should be released
late 2024) ie the next next release of Fedora and on.
Well the only way would be to maybe backport Cabal-3.10 to current releases
but that is rather messy,
or find a simple workaround for setting CABAL_FLAG envvar's.

If this is the state of affairs it starts to feel more appropriate to call
this release 10.0...

Jens
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20240315/06bc0b22/attachment.html>

From ben at well-typed.com  Fri Mar 15 23:12:04 2024
From: ben at well-typed.com (Ben Gamari)
Date: Fri, 15 Mar 2024 19:12:04 -0400
Subject: AArch64/Darwin CI troubles
Message-ID: <87wmq3ay4g.fsf@smart-cactus.org>

Hi all,

It has come to my attention that all of our AArch64/Darwin CI runners
are currently inexplicably unavailable. I have made some inqueries but
until this is resolved I'm afraid CI will be rather stuck. I'll keep the
list updated as I learn more.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20240315/e5c2531d/attachment.sig>

From davean at xkcd.com  Sat Mar 16 00:35:47 2024
From: davean at xkcd.com (davean)
Date: Fri, 15 Mar 2024 20:35:47 -0400
Subject: AArch64/Darwin CI troubles
In-Reply-To: <87wmq3ay4g.fsf@smart-cactus.org>
References: <87wmq3ay4g.fsf@smart-cactus.org>
Message-ID: <CABFs2VjXZCGry9s81hdrFAVnuY=CCehOJgE-eX84Co7woHQBaA@mail.gmail.com>

I just looked at the simspace ones and while they were offline it was only
due to the known router loop problem and I believe the fix I found for
chreekat has restored them.
It began occurring with a wireguard-tools upgrade and while should track
down the cause of the bad route it only shows up on restarts.


On Fri, Mar 15, 2024 at 7:12 PM Ben Gamari <ben at well-typed.com> wrote:

> Hi all,
>
> It has come to my attention that all of our AArch64/Darwin CI runners
> are currently inexplicably unavailable. I have made some inqueries but
> until this is resolved I'm afraid CI will be rather stuck. I'll keep the
> list updated as I learn more.
>
> Cheers,
>
> - Ben
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20240315/a0c7901a/attachment.html>

From moritz.angermann at gmail.com  Sat Mar 16 01:53:41 2024
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Sat, 16 Mar 2024 09:53:41 +0800
Subject: AArch64/Darwin CI troubles
In-Reply-To: <CABFs2VjXZCGry9s81hdrFAVnuY=CCehOJgE-eX84Co7woHQBaA@mail.gmail.com>
References: <87wmq3ay4g.fsf@smart-cactus.org>
 <CABFs2VjXZCGry9s81hdrFAVnuY=CCehOJgE-eX84Co7woHQBaA@mail.gmail.com>
Message-ID: <CAKfdd-xQc7rqKGCG1yKvgLmkVywn_JZVVX8hUd2-bJjTVM7unQ@mail.gmail.com>

I've brought one runner back. I"ll check on the others in a few hours, and
also check if the runner misbehaves.

On Sat, 16 Mar 2024 at 08:36, davean <davean at xkcd.com> wrote:

> I just looked at the simspace ones and while they were offline it was only
> due to the known router loop problem and I believe the fix I found for
> chreekat has restored them.
> It began occurring with a wireguard-tools upgrade and while should track
> down the cause of the bad route it only shows up on restarts.
>
>
> On Fri, Mar 15, 2024 at 7:12 PM Ben Gamari <ben at well-typed.com> wrote:
>
>> Hi all,
>>
>> It has come to my attention that all of our AArch64/Darwin CI runners
>> are currently inexplicably unavailable. I have made some inqueries but
>> until this is resolved I'm afraid CI will be rather stuck. I'll keep the
>> list updated as I learn more.
>>
>> Cheers,
>>
>> - Ben
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20240316/d9abfe58/attachment.html>

From moritz.angermann at gmail.com  Sat Mar 16 04:16:54 2024
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Sat, 16 Mar 2024 12:16:54 +0800
Subject: AArch64/Darwin CI troubles
In-Reply-To: <CAKfdd-xQc7rqKGCG1yKvgLmkVywn_JZVVX8hUd2-bJjTVM7unQ@mail.gmail.com>
References: <87wmq3ay4g.fsf@smart-cactus.org>
 <CABFs2VjXZCGry9s81hdrFAVnuY=CCehOJgE-eX84Co7woHQBaA@mail.gmail.com>
 <CAKfdd-xQc7rqKGCG1yKvgLmkVywn_JZVVX8hUd2-bJjTVM7unQ@mail.gmail.com>
Message-ID: <CAKfdd-zFw-Fo2EewTG=gtyV1erUg2NwF-a_9L5y5W2j8zRqzUg@mail.gmail.com>

Created fresh repository.
12 <https://gitlab.haskell.org/tbidne/ghc/-/jobs/1809168#L12>remote: You
are not allowed to download code from this project.
13 <https://gitlab.haskell.org/tbidne/ghc/-/jobs/1809168#L13>fatal: unable
to access 'https://gitlab.haskell.org/tbidne/ghc.git/': The requested URL
returned error: 403

This is a problem. I guess we should lock the runners to the ghc project
only.

On Sat, 16 Mar 2024 at 09:53, Moritz Angermann <moritz.angermann at gmail.com>
wrote:

> I've brought one runner back. I"ll check on the others in a few hours, and
> also check if the runner misbehaves.
>
> On Sat, 16 Mar 2024 at 08:36, davean <davean at xkcd.com> wrote:
>
>> I just looked at the simspace ones and while they were offline it was
>> only due to the known router loop problem and I believe the fix I found for
>> chreekat has restored them.
>> It began occurring with a wireguard-tools upgrade and while should track
>> down the cause of the bad route it only shows up on restarts.
>>
>>
>> On Fri, Mar 15, 2024 at 7:12 PM Ben Gamari <ben at well-typed.com> wrote:
>>
>>> Hi all,
>>>
>>> It has come to my attention that all of our AArch64/Darwin CI runners
>>> are currently inexplicably unavailable. I have made some inqueries but
>>> until this is resolved I'm afraid CI will be rather stuck. I'll keep the
>>> list updated as I learn more.
>>>
>>> Cheers,
>>>
>>> - Ben
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20240316/25576228/attachment.html>

From bryan at haskell.foundation  Sat Mar 16 07:51:17 2024
From: bryan at haskell.foundation (Bryan Richter)
Date: Sat, 16 Mar 2024 09:51:17 +0200
Subject: AArch64/Darwin CI troubles
In-Reply-To: <CAKfdd-zFw-Fo2EewTG=gtyV1erUg2NwF-a_9L5y5W2j8zRqzUg@mail.gmail.com>
References: <87wmq3ay4g.fsf@smart-cactus.org>
 <CABFs2VjXZCGry9s81hdrFAVnuY=CCehOJgE-eX84Co7woHQBaA@mail.gmail.com>
 <CAKfdd-xQc7rqKGCG1yKvgLmkVywn_JZVVX8hUd2-bJjTVM7unQ@mail.gmail.com>
 <CAKfdd-zFw-Fo2EewTG=gtyV1erUg2NwF-a_9L5y5W2j8zRqzUg@mail.gmail.com>
Message-ID: <CACUTo6zu6BD+bWYYaX5RzvWhGyDs1MANFB6YvTmEpog7sB3Dug@mail.gmail.com>

I've been unavailable for the last week, which means I haven't been on hand
to babysit the runners. My first priority is to finish the Stackage
migration, which is why I haven't taken more decisive action with the
runners already. I haven't had the bandwidth.

I'll be back on Monday, and the acute stage of the Stackage migration now
only involves waiting passively for a huge data transfer to complete.
Making a more robust CI platform is probably the most important thing I can
do next.

On Sat, 16 Mar 2024, 6.17 Moritz Angermann, <moritz.angermann at gmail.com>
wrote:

> Created fresh repository.
> 12 <https://gitlab.haskell.org/tbidne/ghc/-/jobs/1809168#L12>remote: You
> are not allowed to download code from this project.
> 13 <https://gitlab.haskell.org/tbidne/ghc/-/jobs/1809168#L13>fatal:
> unable to access 'https://gitlab.haskell.org/tbidne/ghc.git/': The
> requested URL returned error: 403
>
> This is a problem. I guess we should lock the runners to the ghc project
> only.
>
> On Sat, 16 Mar 2024 at 09:53, Moritz Angermann <moritz.angermann at gmail.com>
> wrote:
>
>> I've brought one runner back. I"ll check on the others in a few hours,
>> and also check if the runner misbehaves.
>>
>> On Sat, 16 Mar 2024 at 08:36, davean <davean at xkcd.com> wrote:
>>
>>> I just looked at the simspace ones and while they were offline it was
>>> only due to the known router loop problem and I believe the fix I found for
>>> chreekat has restored them.
>>> It began occurring with a wireguard-tools upgrade and while should track
>>> down the cause of the bad route it only shows up on restarts.
>>>
>>>
>>> On Fri, Mar 15, 2024 at 7:12 PM Ben Gamari <ben at well-typed.com> wrote:
>>>
>>>> Hi all,
>>>>
>>>> It has come to my attention that all of our AArch64/Darwin CI runners
>>>> are currently inexplicably unavailable. I have made some inqueries but
>>>> until this is resolved I'm afraid CI will be rather stuck. I'll keep the
>>>> list updated as I learn more.
>>>>
>>>> Cheers,
>>>>
>>>> - Ben
>>>> _______________________________________________
>>>> ghc-devs mailing list
>>>> ghc-devs at haskell.org
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>>
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>
>> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20240316/0ec308b8/attachment.html>

From adi.obilisetty at gmail.com  Mon Mar 18 07:47:26 2024
From: adi.obilisetty at gmail.com (Adithya Kumar)
Date: Mon, 18 Mar 2024 13:17:26 +0530
Subject: Follow up: Modifying the "StgHeader" struct
Message-ID: <CAMh=VikE4y4FmapaVJJbGU-1rkmE59KqAfXrJzw15ChzP8cPJg@mail.gmail.com>

Hey folks,

I'm adding a field to "StgHeader" under a flag.

```
typedef struct {
    const StgInfoTable* info;
#if defined(NEW_WAY)
    StgWord             new_field;
#endif
#if defined(PROFILING)
    StgProfHeader         prof;
#endif
} StgHeader;

typedef struct {
    const StgInfoTable* info;
#if defined(NEW_WAY)
    StgWord             new_field;
#endif
#if defined(PROFILING)
    StgProfHeader         prof;
#endif
    StgSMPThunkHeader     smp;
} StgThunkHeader;
```

Follow-up changes:
==================

The following are the additional changes I've made following the `PROFILING`
flag:

Similar to `PROF_HDR_FIELDS` macro, I've added `NEW_HDR_FIELDS` macro:

```
#if defined(NEW_WAY)
#define NEW_HDR_FIELDS(w_,hdr) w_ hdr,
#else
#define NEW_HDR_FIELDS(w_,hdr) /* Nothing */
#endif
```
and updated the required stg code accordingly following the changes from
`PROF_HDR_FIELDS`.

I've also updated `GHC.Exts.Heap.ClosureTypes.closureTypeHeaderSize`
accordingly.

Error:
======

I'm greeted with the following error,
```
ASSERTION FAILED: file rts/StgStartup.cmm, line 100
```

Basically, the following assert fails
```
#define CHECK_SENSIBLE_REGS()                           \
    ASSERT(Hp != 0);                                    \
    ASSERT(HpAlloc == 0);                               \
    ASSERT(Sp != 0);                                    \
    ASSERT(SpLim != 0);                                 \
    ASSERT(SpLim - WDS(RESERVED_STACK_WORDS) <= Sp);
```

More context for the error:
===========================

Values for the correct version:
```
Hp      283468906488
HpAlloc 0
Sp      283468911440
SpLim   283468910784
SpLim - WDS(RESERVED_STACK_WORDS) 1069080
```

Values with the changes:
```
Hp      283468906488
HpAlloc 0
Sp      7532120
SpLim   9301536
SpLim - WDS(RESERVED_STACK_WORDS) 9301368
```

I recorded these values by calling a C print from the Cmm code.

Clearly, my changes messed up a lot of things. How do I go about this now?
The
past 2 weeks I've only been looking at a lot of ghc code. If any more
additional
context is required I can provide it.

Best,
Adithya
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20240318/b7fbc00b/attachment.html>

From sylvain at haskus.fr  Mon Mar 18 10:31:42 2024
From: sylvain at haskus.fr (Sylvain Henry)
Date: Mon, 18 Mar 2024 11:31:42 +0100
Subject: Follow up: Modifying the "StgHeader" struct
In-Reply-To: <CAMh=VikE4y4FmapaVJJbGU-1rkmE59KqAfXrJzw15ChzP8cPJg@mail.gmail.com>
References: <CAMh=VikE4y4FmapaVJJbGU-1rkmE59KqAfXrJzw15ChzP8cPJg@mail.gmail.com>
Message-ID: <bcc18004-8714-4980-acf5-8a3558c2309f@haskus.fr>

Hi,

Adding a new way that changes heap closure representation won't be 
trivial. Handling of the profiling way is very ad-hoc.

Did you update the `deriveConstants` utils and 
`ghc:GHC.Runtime.Heap.Layout.*HdrSize` to take into account your new 
optional field?

Sylvain


On 18/03/2024 08:47, Adithya Kumar wrote:
> Hey folks,
>
> I'm adding a field to "StgHeader" under a flag.
>
> ```
> typedef struct {
>     const StgInfoTable* info;
> #if defined(NEW_WAY)
>     StgWord             new_field;
> #endif
> #if defined(PROFILING)
>     StgProfHeader         prof;
> #endif
> } StgHeader;
>
> typedef struct {
>     const StgInfoTable* info;
> #if defined(NEW_WAY)
>     StgWord             new_field;
> #endif
> #if defined(PROFILING)
>     StgProfHeader         prof;
> #endif
>     StgSMPThunkHeader     smp;
> } StgThunkHeader;
> ```
>
> Follow-up changes:
> ==================
>
> The following are the additional changes I've made following the 
> `PROFILING`
> flag:
>
> Similar to `PROF_HDR_FIELDS` macro, I've added `NEW_HDR_FIELDS` macro:
>
> ```
> #if defined(NEW_WAY)
> #define NEW_HDR_FIELDS(w_,hdr) w_ hdr,
> #else
> #define NEW_HDR_FIELDS(w_,hdr) /* Nothing */
> #endif
> ```
> and updated the required stg code accordingly following the changes from
> `PROF_HDR_FIELDS`.
>
> I've also updated `GHC.Exts.Heap.ClosureTypes.closureTypeHeaderSize`
> accordingly.
>
> Error:
> ======
>
> I'm greeted with the following error,
> ```
> ASSERTION FAILED: file rts/StgStartup.cmm, line 100
> ```
>
> Basically, the following assert fails
> ```
> #define CHECK_SENSIBLE_REGS()                           \
>     ASSERT(Hp != 0);                                    \
>     ASSERT(HpAlloc == 0);                               \
>     ASSERT(Sp != 0);                                    \
>     ASSERT(SpLim != 0);                                 \
>     ASSERT(SpLim - WDS(RESERVED_STACK_WORDS) <= Sp);
> ```
>
> More context for the error:
> ===========================
>
> Values for the correct version:
> ```
> Hp      283468906488
> HpAlloc 0
> Sp      283468911440
> SpLim   283468910784
> SpLim - WDS(RESERVED_STACK_WORDS) 1069080
> ```
>
> Values with the changes:
> ```
> Hp      283468906488
> HpAlloc 0
> Sp      7532120
> SpLim   9301536
> SpLim - WDS(RESERVED_STACK_WORDS) 9301368
> ```
>
> I recorded these values by calling a C print from the Cmm code.
>
> Clearly, my changes messed up a lot of things. How do I go about this 
> now? The
> past 2 weeks I've only been looking at a lot of ghc code. If any more 
> additional
> context is required I can provide it.
>
> Best,
> Adithya
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From noteed at gmail.com  Fri Mar 22 11:39:47 2024
From: noteed at gmail.com (Vo Minh Thu)
Date: Fri, 22 Mar 2024 12:39:47 +0100
Subject: GitLab account approval
Message-ID: <CAOHoMsn0bES-BcwoGcrcm3Nd4QJUP2WhW6-MKY96UDwuzYrr0g@mail.gmail.com>

Hi,

I've signed up with the username "noteed" on gitlab.haskell.org and would
like to be approved.

To give you an idea of what changes I'd like to see, and possibly already
hear some feedback, here are some notes I had (all about GHCi):

- Add a `:version` command. This would show either the same as `ghc
--version`, or the (beginning of the) first output line of GHCi, which is
"GHCi, version 9.11.20240322: https://www.haskell.org/ghc/  :? for help".
This seems like a very simple addition, and could help me learn to hack
GHC, and would make sense for the next point.

- Have a flag to make GHCi not output the string "Loaded GHCi configuration
from path/to/ghci.conf". This would let the `ghci.conf` file be in complete
charge of what is displayed, instead of being necessarily followed by that
string. I guess it would make sense to also hide the version string (see
above).

- Make it possible to start/stop and observe running threads. So maybe a
`:threads` (or `:set threads`, `:show threads` ?) command. Those could be
user-defined, or provided by GHCi.

- Have GHCi watch files for changes (or be easily notified of changes) so
it reloads them automatically (à la ghcid). I guess the main difference
with ghcid is that after reloading the files, there is still an interactive
prompt available (and running threads should be restarted (when using
`:reload` too)).

- One of the running thread, instead of being user-supplied, could be a
builtin feature of GHCi: the ability to listen for commands, just like the
regular interactive prompt.

- Have GHCi be running as a background daemon, with no text interface
beside a listening thread (or more than one). (This is related to
https://gitlab.haskell.org/ghc/ghc/-/issues/15461.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20240322/5e8da51f/attachment.html>

From bryan at haskell.foundation  Fri Mar 22 11:45:14 2024
From: bryan at haskell.foundation (Bryan Richter)
Date: Fri, 22 Mar 2024 13:45:14 +0200
Subject: GitLab account approval
In-Reply-To: <CAOHoMsn0bES-BcwoGcrcm3Nd4QJUP2WhW6-MKY96UDwuzYrr0g@mail.gmail.com>
References: <CAOHoMsn0bES-BcwoGcrcm3Nd4QJUP2WhW6-MKY96UDwuzYrr0g@mail.gmail.com>
Message-ID: <CACUTo6wTkUizjHX9AHkpe=N8j3XvTL0vYYfYHhvQCh2NszXB1g@mail.gmail.com>

Approval sent!

On Fri, 22 Mar 2024 at 13:40, Vo Minh Thu <noteed at gmail.com> wrote:

> Hi,
>
> I've signed up with the username "noteed" on gitlab.haskell.org and would
> like to be approved.
>
> To give you an idea of what changes I'd like to see, and possibly already
> hear some feedback, here are some notes I had (all about GHCi):
>
> - Add a `:version` command. This would show either the same as `ghc
> --version`, or the (beginning of the) first output line of GHCi, which is
> "GHCi, version 9.11.20240322: https://www.haskell.org/ghc/  :? for
> help".  This seems like a very simple addition, and could help me learn to
> hack GHC, and would make sense for the next point.
>
> - Have a flag to make GHCi not output the string "Loaded GHCi
> configuration from path/to/ghci.conf". This would let the `ghci.conf` file
> be in complete charge of what is displayed, instead of being necessarily
> followed by that string. I guess it would make sense to also hide the
> version string (see above).
>
> - Make it possible to start/stop and observe running threads. So maybe a
> `:threads` (or `:set threads`, `:show threads` ?) command. Those could be
> user-defined, or provided by GHCi.
>
> - Have GHCi watch files for changes (or be easily notified of changes) so
> it reloads them automatically (à la ghcid). I guess the main difference
> with ghcid is that after reloading the files, there is still an interactive
> prompt available (and running threads should be restarted (when using
> `:reload` too)).
>
> - One of the running thread, instead of being user-supplied, could be a
> builtin feature of GHCi: the ability to listen for commands, just like the
> regular interactive prompt.
>
> - Have GHCi be running as a background daemon, with no text interface
> beside a listening thread (or more than one). (This is related to
> https://gitlab.haskell.org/ghc/ghc/-/issues/15461.)
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20240322/f44c16b8/attachment.html>

From noteed at gmail.com  Fri Mar 22 11:44:05 2024
From: noteed at gmail.com (Vo Minh Thu)
Date: Fri, 22 Mar 2024 12:44:05 +0100
Subject: GitLab account approval
In-Reply-To: <CAOHoMsn0bES-BcwoGcrcm3Nd4QJUP2WhW6-MKY96UDwuzYrr0g@mail.gmail.com>
References: <CAOHoMsn0bES-BcwoGcrcm3Nd4QJUP2WhW6-MKY96UDwuzYrr0g@mail.gmail.com>
Message-ID: <CAOHoMskHLyWwBZubscO35qvs84n3qH5A643WXcZTvW+qCdFm4A@mail.gmail.com>

I've forgot to sign before hitting enter...

Cheers,
Võ Minh Thu

Le ven. 22 mars 2024 à 12:39, Vo Minh Thu <noteed at gmail.com> a écrit :

> Hi,
>
> I've signed up with the username "noteed" on gitlab.haskell.org and would
> like to be approved.
>
> To give you an idea of what changes I'd like to see, and possibly already
> hear some feedback, here are some notes I had (all about GHCi):
>
> - Add a `:version` command. This would show either the same as `ghc
> --version`, or the (beginning of the) first output line of GHCi, which is
> "GHCi, version 9.11.20240322: https://www.haskell.org/ghc/  :? for
> help".  This seems like a very simple addition, and could help me learn to
> hack GHC, and would make sense for the next point.
>
> - Have a flag to make GHCi not output the string "Loaded GHCi
> configuration from path/to/ghci.conf". This would let the `ghci.conf` file
> be in complete charge of what is displayed, instead of being necessarily
> followed by that string. I guess it would make sense to also hide the
> version string (see above).
>
> - Make it possible to start/stop and observe running threads. So maybe a
> `:threads` (or `:set threads`, `:show threads` ?) command. Those could be
> user-defined, or provided by GHCi.
>
> - Have GHCi watch files for changes (or be easily notified of changes) so
> it reloads them automatically (à la ghcid). I guess the main difference
> with ghcid is that after reloading the files, there is still an interactive
> prompt available (and running threads should be restarted (when using
> `:reload` too)).
>
> - One of the running thread, instead of being user-supplied, could be a
> builtin feature of GHCi: the ability to listen for commands, just like the
> regular interactive prompt.
>
> - Have GHCi be running as a background daemon, with no text interface
> beside a listening thread (or more than one). (This is related to
> https://gitlab.haskell.org/ghc/ghc/-/issues/15461.)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20240322/aafd74dd/attachment.html>

From ganesh at earth.li  Sat Mar 23 00:53:35 2024
From: ganesh at earth.li (Ganesh Sittampalam)
Date: Sat, 23 Mar 2024 00:53:35 +0000
Subject: GHC proposals not rendering
In-Reply-To: <CAJKmMz8yt=OJ_HGLmsWbm0gn2_nZy-=s=xuFc=kf6Px2mBw02g@mail.gmail.com>
References: <CAJKmMz8yt=OJ_HGLmsWbm0gn2_nZy-=s=xuFc=kf6Px2mBw02g@mail.gmail.com>
Message-ID: <73b964fa-5cb8-43fe-be9b-e33ad058aa0f@earth.li>

I believe the problem is fixed now - at the very least, the one in 
Simon's original report is now working.

On 11/01/2024 15:28, Simon Peyton Jones wrote:
> If you go to https://github.com/ghc-proposals/ghc-proposals/pull/448, 
> and click on the "rendered" link, namely 
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0448-type-variable-scoping.rst, 
> Github is now displaying the .rst source, not the rendered proposal.
>
> This has started happening (consistently across other proposals) today.
>
> Does anyone know why?  How can I fix this?
>
> Simon
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20240323/8acc5808/attachment.html>

From ben at well-typed.com  Mon Mar 25 17:18:34 2024
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 25 Mar 2024 13:18:34 -0400
Subject: GitLab planned outage
Message-ID: <87bk72b57f.fsf@smart-cactus.org>

Hi all,

On Wednesday evening EST I will bring down gitlab.haskell.org for some
scheduled maintenance. I expect that the outage will likely start at
19:00 EST and last for up to two hours.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20240325/d946196b/attachment.sig>

From ben at well-typed.com  Fri Mar 29 21:30:16 2024
From: ben at well-typed.com (Ben Gamari)
Date: Fri, 29 Mar 2024 17:30:16 -0400
Subject: [ANNOUNCE] GHC 9.10.1-alpha2 is now available
Message-ID: <87v854afq2.fsf@smart-cactus.org>

The GHC developers are very pleased to announce the availability of the
second alpha release of GHC 9.10.1. Binary distributions, source
distributions, and documentation are available at

         https://downloads.haskell.org/ghc/9.10.1-alpha2

We hope to have this release available via ghcup shortly.

GHC 9.10 will bring a number of new features and improvements, including:

 * The introduction of the `GHC2024` language edition, building upon
   `GHC2021` with the addition of a number of widely-used extensions.

 * Partial implementation of the [GHC Proposal #281], allowing visible
   quantification to be used in the types of terms.

 * [Extension] of LinearTypes to allow linear `let` and `where`
   bindings ([linear let])

 * The implementation of the [exception backtrace proposal], allowing
   the annotation of exceptions with backtraces, as well as other
   user-defined context

 * Further improvements in the info table provenance mechanism, reducing
   code size to allow IPE information to be enabled more widely

 * Javascript FFI support in the WebAssembly backend

 * Improvements in the fragmentation characteristics of the low-latency
   non-moving garbage collector.

 * ... and many more

A full accounting of changes can be found in the [release notes].
As always, GHC's release status, including planned future releases, can
be found on the GHC Wiki [status].

We would like to thank GitHub, IOG, the Zw3rk stake pool,
Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell
Foundation, and other anonymous contributors whose on-going financial
and in-kind support has facilitated GHC maintenance and release
management over the years. Finally, this release would not have been
possible without the hundreds of open-source contributors whose work
comprise this release.

As always, do give this release a try and open a [ticket] if you see
anything amiss.


[release notes]: https://downloads.haskell.org/ghc/9.10.1-alpha2/docs/users_guide/9.10.1-notes.html
[status]: https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status
[exception backtrace]: https://github.com/ghc-proposals/ghc-proposals/pull/330
[GHC Proposal #281]: https://github.com/ghc-proposals/ghc-proposals/pull/281
[linear let]: https://github.com/ghc-proposals/ghc-proposals/pull/624
[ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20240329/2a0ddf08/attachment.sig>

From wraithm at gmail.com  Sun Mar 31 08:47:36 2024
From: wraithm at gmail.com (Matthew Wraith)
Date: Sun, 31 Mar 2024 01:47:36 -0700
Subject: GitLab Account Approval
Message-ID: <CANT3vfze6zjud=_rpW0McqMFwhx60wowYKtg6os42A1E8PYp_w@mail.gmail.com>

Hi everyone,

I’ve requested to join the gitlab instance with username wraithm

Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20240331/1f0dfea6/attachment.html>

From rodrigo.m.mesquita at gmail.com  Sun Mar 31 08:51:02 2024
From: rodrigo.m.mesquita at gmail.com (Rodrigo Mesquita)
Date: Sun, 31 Mar 2024 09:51:02 +0100
Subject: GitLab Account Approval
In-Reply-To: <CANT3vfze6zjud=_rpW0McqMFwhx60wowYKtg6os42A1E8PYp_w@mail.gmail.com>
References: <CANT3vfze6zjud=_rpW0McqMFwhx60wowYKtg6os42A1E8PYp_w@mail.gmail.com>
Message-ID: <4747C7E7-61C7-4C26-9919-74D2B20A7D78@gmail.com>

Hello Matthew,

Thanks for letting us know. I’ve approved it.

Cheers,
Rodrigo

> On 31 Mar 2024, at 09:47, Matthew Wraith <wraithm at gmail.com> wrote:
> 
> 
> Hi everyone,
> 
> I’ve requested to join the gitlab instance with username wraithm
> 
> Thanks!
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs