From sperber at deinprogramm.de  Wed Aug  4 15:24:38 2021
From: sperber at deinprogramm.de (Michael Sperber)
Date: Wed, 04 Aug 2021 17:24:38 +0200
Subject: -dinline-check for symbolic names?
Message-ID: <y9lmtpxi66h.fsf@valmont.fritz.box>


I'm trying to figure out why this function from ConCat.AltCat is not
getting inlined:

(&&&) :: forall k a c d. (MProductCat k, Ok3 k a c d)
      => (a `k` c) -> (a `k` d) -> (a `k` Prod k c d)
f &&& g = (f *** g) . dup
  <+ okProd @k @a @a
  <+ okProd @k @c @d
{-# INLINE (&&&) #-}

So I put

{-# OPTIONS_GHC -dinline-check ConCat.AltCat.&&& #-}

in the importing module.  Alas, I'm getting no output on &&&.  I can get
output from lots of other functions - I'm guessing it might be because
of the name.

Could somebody help me enable the inline check?  Would be much
appreciated!

-- 
Regards,
Mike


From carter.schonwald at gmail.com  Wed Aug  4 15:51:24 2021
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Wed, 4 Aug 2021 11:51:24 -0400
Subject: -dinline-check for symbolic names?
In-Reply-To: <y9lmtpxi66h.fsf@valmont.fritz.box>
References: <y9lmtpxi66h.fsf@valmont.fritz.box>
Message-ID: <CAHYVw0zrkVaFF2yFs_pX9Tdvtzs+C3JFW5Ev_DPd8vYWeY=EcA@mail.gmail.com>

I’m not sure about the pragma debugging, but are you using it in point free
style? Cause I’m that case it may not be inclined because it’s not being
fully applied on the left hand side?

On Wed, Aug 4, 2021 at 11:36 AM Michael Sperber <sperber at deinprogramm.de>
wrote:

>
> I'm trying to figure out why this function from ConCat.AltCat is not
> getting inlined:
>
> (&&&) :: forall k a c d. (MProductCat k, Ok3 k a c d)
>       => (a `k` c) -> (a `k` d) -> (a `k` Prod k c d)
> f &&& g = (f *** g) . dup
>   <+ okProd @k @a @a
>   <+ okProd @k @c @d
> {-# INLINE (&&&) #-}
>
> So I put
>
> {-# OPTIONS_GHC -dinline-check ConCat.AltCat.&&& #-}
>
> in the importing module.  Alas, I'm getting no output on &&&.  I can get
> output from lots of other functions - I'm guessing it might be because
> of the name.
>
> Could somebody help me enable the inline check?  Would be much
> appreciated!
>
> --
> Regards,
> Mike
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20210804/3eba820a/attachment.html>

From emilypi at cohomolo.gy  Thu Aug  5 21:27:47 2021
From: emilypi at cohomolo.gy (Emily Pillmore)
Date: Thu, 05 Aug 2021 21:27:47 +0000
Subject: [ANN] Cabal-3.6.0.0
Message-ID: <krzfk5jw.134ee92c-06ec-4363-8ff0-27c0012a409a@we.are.superhuman.com>

Hello All,

The Cabal team is excited to announce the release of Cabal-3.6.0.0!

This is the fourth release of the 3.0 release series, and highlights include support for GHC 9.2, as well as many new code quality improvements + organization work on the repo itself.

For future plans, we've announced a State of the Cabal post which describes where we want to take the library and executable over the next year or two here: https://discourse.haskell.org/t/state-of-the-cabal-q1-q2-2021/2548.

If you'd like to get involved, feel free to contact anyone from the maintainer team directly, or drop by #hackage on libera.chat ( http://libera.chat/ ) to speak with us. Additionally, as we continue to modernize Cabal, I'd like to highlight and show appreciation for all of the help we've gotten from the community, including the developer hours coming from Well-Typed, Haskell Foundation/Haskell.org ( http://foundation/Haskell.org ) , Obsidian Systems, and the Haskell Language Server folks. I'm glad we could work together!

For a full set of release notes, see https://github.com/haskell/cabal/blob/master/release-notes/Cabal-3.6.0.0.md. If you have issues, we'd love to hear about there here: https://github.com/haskell/cabal/issues.

Happy hacking!

Emily
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20210805/0133d237/attachment.html>

From thomas.dubuisson at gmail.com  Thu Aug  5 22:00:23 2021
From: thomas.dubuisson at gmail.com (Thomas DuBuisson)
Date: Thu, 5 Aug 2021 18:00:23 -0400
Subject: [ANN] Cabal-3.6.0.0
In-Reply-To: <krzfk5jw.134ee92c-06ec-4363-8ff0-27c0012a409a@we.are.superhuman.com>
References: <krzfk5jw.134ee92c-06ec-4363-8ff0-27c0012a409a@we.are.superhuman.com>
Message-ID: <CAOk36Jiwy=1OzZr6YXTTNiTyFD03GA=otYLeHjRvyFXSosCTrw@mail.gmail.com>

Great news!

The changelog (and the 3.6 branch) does not include
https://github.com/haskell/cabal/pull/7493.  This is just as well since
HEAD (with this merge) doesn't fix the related issue in my testing, but I'm
curious if such a fix can be part of a point release or if it must be 3.8?

-Tom

On Thu, Aug 5, 2021 at 5:30 PM Emily Pillmore <emilypi at cohomolo.gy> wrote:

> Hello All,
>
> The Cabal team is excited to announce the release of Cabal-3.6.0.0!
>
>
> This is the fourth release of the 3.0 release series, and highlights
> include support for GHC 9.2, as well as many new code quality improvements
> + organization work on the repo itself.
>
> For future plans, we've announced a State of the Cabal post which
> describes where we want to take the library and executable over the next
> year or two here:
> https://discourse.haskell.org/t/state-of-the-cabal-q1-q2-2021/2548.
>
> If you'd like to get involved, feel free to contact anyone from the
> maintainer team directly, or drop by #hackage on libera.chat to speak
> with us. Additionally, as we continue to modernize Cabal, I'd like to
> highlight and show appreciation for all of the help we've gotten from the
> community, including the developer hours coming from Well-Typed, Haskell
> Foundation/Haskell.org <http://foundation/Haskell.org>, Obsidian Systems,
> and the Haskell Language Server folks. I'm glad we could work together!
>
> For a full set of release notes, see
> https://github.com/haskell/cabal/blob/master/release-notes/Cabal-3.6.0.0.md.
> If you have issues, we'd love to hear about there here:
> https://github.com/haskell/cabal/issues.
>
> Happy hacking!
>
> Emily
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20210805/ff4c3b2b/attachment.html>

From emilypi at cohomolo.gy  Fri Aug  6 03:03:05 2021
From: emilypi at cohomolo.gy (Emily Pillmore)
Date: Fri, 06 Aug 2021 03:03:05 +0000
Subject: [ANN] Cabal-3.6.0.0
In-Reply-To: <CAOk36Jiwy=1OzZr6YXTTNiTyFD03GA=otYLeHjRvyFXSosCTrw@mail.gmail.com>
References: <krzfk5jw.134ee92c-06ec-4363-8ff0-27c0012a409a@we.are.superhuman.com>
 <CAOk36Jiwy=1OzZr6YXTTNiTyFD03GA=otYLeHjRvyFXSosCTrw@mail.gmail.com>
Message-ID: <krzrgr5m.f285b118-fbd1-4596-82f4-f04a461c4687@we.are.superhuman.com>

Hey Tom,

The 3.6 branch was feature frozen by early Summer, so 7493 didn't go in to it afaict. However, if there's a reasonable fix, I see no reason why we can't backport it to a point release for the 3.6 series. I'll discuss with Mikolaj and we'll see what we can do :)

Cheers,

Emily

On Thu, Aug 05, 2021 at 4:00 PM, Thomas DuBuisson < thomas.dubuisson at gmail.com > wrote:

> 
> Great news!
> 
> 
> The changelog (and the 3.6 branch) does not include https:/ / github. com/
> haskell/ cabal/ pull/ 7493 ( https://github.com/haskell/cabal/pull/7493 ).
> This is just as well since HEAD (with this merge) doesn't fix the related
> issue in my testing, but I'm curious if such a fix can be part of a point
> release or if it must be 3.8?
> 
> 
> -Tom
> 
> On Thu, Aug 5, 2021 at 5:30 PM Emily Pillmore < emilypi@ cohomolo. gy (
> emilypi at cohomolo.gy ) > wrote:
> 
> 
>> Hello All,
>> 
>> 
>> 
>> The Cabal team is excited to announce the release of Cabal-3.6.0.0!
>> 
>> 
>> 
>> 
>> 
>> This is the fourth release of the 3.0 release series, and highlights
>> include support for GHC 9.2, as well as many new code quality improvements
>> + organization work on the repo itself.
>> 
>> 
>> 
>> For future plans, we've announced a State of the Cabal post which
>> describes where we want to take the library and executable over the next
>> year or two here: https:/ / discourse. haskell. org/ t/ state-of-the-cabal-q1-q2-2021/
>> 2548 ( https://discourse.haskell.org/t/state-of-the-cabal-q1-q2-2021/2548 )
>> .
>> 
>> 
>> 
>> If you'd like to get involved, feel free to contact anyone from the
>> maintainer team directly, or drop by #hackage on libera. chat (
>> http://libera.chat/ ) to speak with us. Additionally, as we continue to
>> modernize Cabal, I'd like to highlight and show appreciation for all of
>> the help we've gotten from the community, including the developer hours
>> coming from Well-Typed, Haskell Foundation/ Haskell. org (
>> http://foundation/Haskell.org ) , Obsidian Systems, and the Haskell
>> Language Server folks. I'm glad we could work together!
>> 
>> 
>> 
>> For a full set of release notes, see https:/ / github. com/ haskell/ cabal/
>> blob/ master/ release-notes/ Cabal-3. 6. 0. 0. md (
>> https://github.com/haskell/cabal/blob/master/release-notes/Cabal-3.6.0.0.md
>> ). If you have issues, we'd love to hear about there here: https:/ / github.
>> com/ haskell/ cabal/ issues ( https://github.com/haskell/cabal/issues ).
>> 
>> 
>> 
>> Happy hacking!
>> 
>> 
>> 
>> Emily
>> 
>> 
>> 
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users@ haskell. org ( Glasgow-haskell-users at haskell.org )
>> http:/ / mail. haskell. org/ cgi-bin/ mailman/ listinfo/ glasgow-haskell-users
>> ( http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users )
> 
> 
> 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20210806/6e672bb4/attachment.html>

From mikolaj at well-typed.com  Fri Aug  6 07:48:07 2021
From: mikolaj at well-typed.com (Mikolaj Konarski)
Date: Fri, 6 Aug 2021 09:48:07 +0200
Subject: [ANN] Cabal-3.6.0.0
In-Reply-To: <CAOk36Jiwy=1OzZr6YXTTNiTyFD03GA=otYLeHjRvyFXSosCTrw@mail.gmail.com>
References: <krzfk5jw.134ee92c-06ec-4363-8ff0-27c0012a409a@we.are.superhuman.com>
 <CAOk36Jiwy=1OzZr6YXTTNiTyFD03GA=otYLeHjRvyFXSosCTrw@mail.gmail.com>
Message-ID: <CAHFo2ur4eKHuHb5WVV8+Nb8_7bd8s_9HRSgFr0w+vVq_55Aj5Q@mail.gmail.com>

Hi Thomas,

> The changelog (and the 3.6 branch) does not include https://github.com/haskell/cabal/pull/7493.  This is just as well since HEAD (with this merge) doesn't fix the related issue in my testing, but I'm curious if such a fix can be part of a point release or if it must be 3.8?

Please do share, as a comment on the PR or the main issue, the results
of your testing, whether negative or positive. We are deferring the
merge to a point release, in particular, because only a few people
tested the hack.

Kind regards,
Mikolaj

From sperber at deinprogramm.de  Fri Aug  6 12:29:50 2021
From: sperber at deinprogramm.de (Michael Sperber)
Date: Fri, 06 Aug 2021 14:29:50 +0200
Subject: -dinline-check for symbolic names?
References: <y9lmtpxi66h.fsf@valmont.fritz.box>
 <CAHYVw0zrkVaFF2yFs_pX9Tdvtzs+C3JFW5Ev_DPd8vYWeY=EcA@mail.gmail.com>
Message-ID: <y9lwnoyg3i9.fsf@valmont.fritz.box>


On Wed, Aug 04 2021, Carter Schonwald <carter.schonwald at gmail.com> wrote:

> I’m not sure about the pragma debugging, but are you using it in point free
> style? Cause I’m that case it may not be inclined because it’s not being
> fully applied on the left hand side?

Good point, but I checked, and it's fully applied. :-(

I should also note that, with the inline check, I've also tried:

{-# OPTIONS_GHC -dinline-check &&& #-}
{-# OPTIONS_GHC -dinline-check (&&&) #-}

... to no avail.

-- 
Regards,
Mike


From sperber at deinprogramm.de  Fri Aug  6 12:43:43 2021
From: sperber at deinprogramm.de (Michael Sperber)
Date: Fri, 06 Aug 2021 14:43:43 +0200
Subject: -dinline-check for symbolic names?
References: <y9lmtpxi66h.fsf@valmont.fritz.box>
 <CAHYVw0zrkVaFF2yFs_pX9Tdvtzs+C3JFW5Ev_DPd8vYWeY=EcA@mail.gmail.com>
 <y9lwnoyg3i9.fsf@valmont.fritz.box>
Message-ID: <y9lsfzmg2v4.fsf@valmont.fritz.box>


On Fri, Aug 06 2021, Michael Sperber <sperber at deinprogramm.de> wrote:

> On Wed, Aug 04 2021, Carter Schonwald <carter.schonwald at gmail.com> wrote:
>
>> I’m not sure about the pragma debugging, but are you using it in point free
>> style? Cause I’m that case it may not be inclined because it’s not being
>> fully applied on the left hand side?
>
> Good point, but I checked, and it's fully applied. :-(

Another note: Once I change the INLINE to INLINE [0], everything works:
(&&&) gets inlined, and -dinline-check works.  Explanation welcome ...

-- 
Regards,
Mike


From sperber at deinprogramm.de  Fri Aug  6 13:06:15 2021
From: sperber at deinprogramm.de (Michael Sperber)
Date: Fri, 06 Aug 2021 15:06:15 +0200
Subject: Avoiding construction of dead dictionaries
Message-ID: <y9lo8aag1tk.fsf@valmont.fritz.box>


I have another optimization problem.  ConCat includes this definition:

(<+) :: Con a => (Con b => r) -> (a |- b) -> r
r <+ Entail (Sub Dict) = r

The right-hand argument of <+ leads to a dictionary construction that is
a proof of a certain property, but the dictionary itself ends up being
dead, like so:

      case $w$dOpCon_r2kGJ ...
      of
      { (# ww1_s27L3 #) -> ... }
           ^^^^^^^^^
           never used

Yet, ghc (8.10.4) never elides this code.  (I'm naively assuming because
of the unboxed tuple, but actually have no clue.)

Is there any chance of convincing ghc of erasing the dictionary
construction?

Help would be much appreciated!

-- 
Regards,
Mike


From x at tomsmeding.com  Fri Aug  6 14:55:08 2021
From: x at tomsmeding.com (Tom Smeding)
Date: Fri, 06 Aug 2021 14:55:08 +0000
Subject: Avoiding construction of dead dictionaries
In-Reply-To: <y9lo8aag1tk.fsf@valmont.fritz.box>
References: <y9lo8aag1tk.fsf@valmont.fritz.box>
Message-ID: <4uoPp42nVX4i5JRZO9XxsODOF2QZMyRoCYlrJhd6rnk0Y1AfWCQImFe7-K03IyBu0e0vy5T0-ksSRCNs9lojy9KMGI6mFPj5oQhHCvplbEA=@tomsmeding.com>

Would it not be unsound for ghc to elide dictionary construction here? After all, the right-hand side might actually be a bottom (e.g. undefined) at run-time, in which case the pattern match cannot succeed according to the semantics of Haskell. I suspect that if you make the pattern match lazy (i.e. ~(Entail (Sub Dict))) or ignore the argument altogether (i.e. _), dictionary construction will be elided.

- Tom

-------- Original Message --------
On 6 Aug 2021, 15:06, Michael Sperber wrote:

> I have another optimization problem. ConCat includes this definition:
>
> (<+) :: Con a => (Con b => r) -> (a |- b) -> r
> r <+ Entail (Sub Dict) = r
>
> The right-hand argument of <+ leads to a dictionary construction that is
> a proof of a certain property, but the dictionary itself ends up being
> dead, like so:
>
> case $w$dOpCon_r2kGJ ...
> of
> { (# ww1_s27L3 #) -> ... }
> ^^^^^^^^^
> never used
>
> Yet, ghc (8.10.4) never elides this code. (I'm naively assuming because
> of the unboxed tuple, but actually have no clue.)
>
> Is there any chance of convincing ghc of erasing the dictionary
> construction?
>
> Help would be much appreciated!
>
> --
> Regards,
> Mike
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20210806/41a5b63b/attachment.html>

From anthony.d.clayden at gmail.com  Sun Aug  8 07:04:11 2021
From: anthony.d.clayden at gmail.com (Anthony Clayden)
Date: Sun, 8 Aug 2021 19:04:11 +1200
Subject: InstanceSigs -- rationale for the "must be more polymorphic than"
Message-ID: <CABU_mxgQKzksVgVTZ7tDhLps1k6zJwqZ4e3+PPE1YtwN05M0dg@mail.gmail.com>

I can't help but feel InstanceSigs are either superfluous or upside-down.
It's this bit in the User Guide:

> The type signature in the instance declaration must be
> more polymorphic than (or the same as) the one in the class declaration,
> instantiated with the instance type.

Usually if you give a signature, it must be _less_ polymorphic (or the same
as) the type inferred from the term:

>    lessPolyPlus :: Integral a => a -> a -> a
>    lessPolyPlus x y = x + y

Or

>    lessPolyPlus (x :: a) y = x + y :: Integral a => a

The examples in the User Guide aren't helping: you could just drop the
InstanceSigs, and all is well-typed. (Even the example alleging to use
-XScopedTypeVariables in a where sub-decl: you could just put random `xs ::
[b]` without scoping `b`.)

Dropping the Sigs altogether works because the type from the class decl,
suitably instantiated, is less polymorphic than inferred from the term. IOW
the suitably instantiated type restricts what would otherwise be inferred.
Situation normal.

I suppose it might be helpful to give an explicit InstanceSig as 'belt and
braces' for the instantiated -- possibly because the instantiation is hard
to figure out; possibly because you want to use -XScopedTypeVariables
within a where-bound sub-decl, as an extra piece of string.

I can see you mustn't make the InstanceSig _less_ polymorphic than the
suitably instantiated.

But the docos don't give any example where it's essential to provide an
InstanceSig _and_  make it strictly more polymorphic. Here all the sigs and
annotations are just superfluous:

>    maxPolyPlus :: Num a => a -> a -> a
>    maxPolyPlus = (+)
>
>    class C a  where foo :: a -> T a
>    instance Integral a => C a  where
>      foo :: Num a => a -> T a
>      foo (x :: a) = MkT (maxPolyPlus x x :: Num a => a)

Is there a persuasive example (to put in the User Guide)?

AntC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20210808/9d4709ba/attachment.html>

From david.feuer at gmail.com  Sun Aug  8 08:36:34 2021
From: david.feuer at gmail.com (David Feuer)
Date: Sun, 8 Aug 2021 04:36:34 -0400
Subject: InstanceSigs -- rationale for the "must be more polymorphic than"
In-Reply-To: <CABU_mxgQKzksVgVTZ7tDhLps1k6zJwqZ4e3+PPE1YtwN05M0dg@mail.gmail.com>
References: <CABU_mxgQKzksVgVTZ7tDhLps1k6zJwqZ4e3+PPE1YtwN05M0dg@mail.gmail.com>
Message-ID: <CAMgWh9vD7KZWG_TRkjUwxH6psyfAyNhqOTF4GvfteY_WFYDzKA@mail.gmail.com>

To the best of my knowledge, `InstanceSigs` are never strictly necessary.
They can, however, be useful for at least four purposes:

1. To provide a compiler-checked reminder of the type.
2. To bind type variables with `ScopedTypeVariables`.
3. To generalize the type so you can use polymorphic recursion.
4. To enhance parametricitry/polymorphism for internal documentation
purposes.

The third reason is probably the main technical one to allow a more general
signature, but the fourth is likely helpful too.

On Sun, Aug 8, 2021, 3:04 AM Anthony Clayden <anthony.d.clayden at gmail.com>
wrote:

> I can't help but feel InstanceSigs are either superfluous or upside-down.
> It's this bit in the User Guide:
>
> > The type signature in the instance declaration must be
> > more polymorphic than (or the same as) the one in the class declaration,
> > instantiated with the instance type.
>
> Usually if you give a signature, it must be _less_ polymorphic (or the
> same as) the type inferred from the term:
>
> >    lessPolyPlus :: Integral a => a -> a -> a
> >    lessPolyPlus x y = x + y
>
> Or
>
> >    lessPolyPlus (x :: a) y = x + y :: Integral a => a
>
> The examples in the User Guide aren't helping: you could just drop the
> InstanceSigs, and all is well-typed. (Even the example alleging to use
> -XScopedTypeVariables in a where sub-decl: you could just put random `xs ::
> [b]` without scoping `b`.)
>
> Dropping the Sigs altogether works because the type from the class decl,
> suitably instantiated, is less polymorphic than inferred from the term. IOW
> the suitably instantiated type restricts what would otherwise be inferred.
> Situation normal.
>
> I suppose it might be helpful to give an explicit InstanceSig as 'belt and
> braces' for the instantiated -- possibly because the instantiation is hard
> to figure out; possibly because you want to use -XScopedTypeVariables
> within a where-bound sub-decl, as an extra piece of string.
>
> I can see you mustn't make the InstanceSig _less_ polymorphic than the
> suitably instantiated.
>
> But the docos don't give any example where it's essential to provide an
> InstanceSig _and_  make it strictly more polymorphic. Here all the sigs and
> annotations are just superfluous:
>
> >    maxPolyPlus :: Num a => a -> a -> a
> >    maxPolyPlus = (+)
> >
> >    class C a  where foo :: a -> T a
> >    instance Integral a => C a  where
> >      foo :: Num a => a -> T a
> >      foo (x :: a) = MkT (maxPolyPlus x x :: Num a => a)
>
> Is there a persuasive example (to put in the User Guide)?
>
> AntC
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20210808/3b87314f/attachment.html>

From sperber at deinprogramm.de  Mon Aug  9 13:24:41 2021
From: sperber at deinprogramm.de (Michael Sperber)
Date: Mon, 09 Aug 2021 15:24:41 +0200
Subject: Avoiding construction of dead dictionaries
References: <y9lo8aag1tk.fsf@valmont.fritz.box>
 <4uoPp42nVX4i5JRZO9XxsODOF2QZMyRoCYlrJhd6rnk0Y1AfWCQImFe7-K03IyBu0e0vy5T0-ksSRCNs9lojy9KMGI6mFPj5oQhHCvplbEA=@tomsmeding.com>
Message-ID: <y9lmtpqbvja.fsf@valmont.fritz.box>


Thanks for thinking about this one!

On Fri, Aug 06 2021, Tom Smeding <x at tomsmeding.com> wrote:

> Would it not be unsound for ghc to elide dictionary construction here?
> After all, the right-hand side might actually be a bottom
> (e.g. undefined) at run-time, in which case the pattern match cannot
> succeed according to the semantics of Haskell.

But wouldn't that imply that ghc can build dictionary-construction code
that evaluates to bottom?  Can that happen?

> I suspect that if you make the pattern match lazy (i.e. ~(Entail (Sub
> Dict))) or ignore the argument altogether (i.e. _), dictionary
> construction will be elided.

Thanks for the hint!  ghc gives me this unfortunately, implying that it
agreed with your first comment:

src/ConCat/Category.hs:190:29: error:
    • Could not deduce: Con b arising from a use of ‘r’
      from the context: Con a
        bound by the type signature for:
                   (<+) :: forall a b r. Con a => (Con b => r) -> (a |- b) -> r
        at src/ConCat/Category.hs:189:1-46
    • In the expression: r
      In an equation for ‘<+’: r <+ ~(Entail (Sub Dict)) = r
    • Relevant bindings include
        r :: Con b => r (bound at src/ConCat/Category.hs:190:1)
        (<+) :: (Con b => r) -> (a |- b) -> r
          (bound at src/ConCat/Category.hs:190:3)
    |
190 | r <+ ~(Entail (Sub Dict)) = r
    |                             ^

Other ideas welcome!

-- 
Regards,
Mike


From x at tomsmeding.com  Mon Aug  9 15:26:27 2021
From: x at tomsmeding.com (Tom Smeding)
Date: Mon, 09 Aug 2021 15:26:27 +0000
Subject: Avoiding construction of dead dictionaries
In-Reply-To: <y9lmtpqbvja.fsf@valmont.fritz.box>
References: <y9lo8aag1tk.fsf@valmont.fritz.box>
 <4uoPp42nVX4i5JRZO9XxsODOF2QZMyRoCYlrJhd6rnk0Y1AfWCQImFe7-K03IyBu0e0vy5T0-ksSRCNs9lojy9KMGI6mFPj5oQhHCvplbEA=@tomsmeding.com>
 <y9lmtpqbvja.fsf@valmont.fritz.box>
Message-ID: <zLTAlyXlXJI5vhvwXpKu1dg1uVmPOVzexAVi4BN2GNWYGE9twuZelaK4UyOe89tFqPdbTmfuvrfBEN7EP59xymXp9621ZVasYnyw-7jT8Kg=@tomsmeding.com>

Hi Mike,

> But wouldn't that imply that ghc can build dictionary-construction code

> that evaluates to bottom? Can that happen?

I assume no, but here the dictionary is embedded as a field in the GADT, right? So if the data value is bottom, there is not even a dictionary to be found, let alone not-bottom.

This assumes that the Dict in `Entail (Sub Dict)` is a GADT like

Dict :: Con b => Dict something

where the Con dictionary is contained in the GADT. Remember that in Core, dictionaries are values, and there is no difference between => and ->.

- Tom

-------- Original Message --------

On 9 Aug 2021, 15:24, Michael Sperber < sperber at deinprogramm.de> wrote:

Thanks for thinking about this one!

On Fri, Aug 06 2021, Tom Smeding <x at tomsmeding.com> wrote:

> Would it not be unsound for ghc to elide dictionary construction here?

> After all, the right-hand side might actually be a bottom

> (e.g. undefined) at run-time, in which case the pattern match cannot

> succeed according to the semantics of Haskell.

But wouldn't that imply that ghc can build dictionary-construction code

that evaluates to bottom? Can that happen?

> I suspect that if you make the pattern match lazy (i.e. ~(Entail (Sub

> Dict))) or ignore the argument altogether (i.e. _), dictionary

> construction will be elided.

Thanks for the hint! ghc gives me this unfortunately, implying that it

agreed with your first comment:

src/ConCat/Category.hs:190:29: error:

• Could not deduce: Con b arising from a use of ‘r’

from the context: Con a

bound by the type signature for:

(<+) :: forall a b r. Con a => (Con b => r) -> (a |- b) -> r

at src/ConCat/Category.hs:189:1-46

• In the expression: r

In an equation for ‘<+’: r <+ ~(Entail (Sub Dict)) = r

• Relevant bindings include

r :: Con b => r (bound at src/ConCat/Category.hs:190:1)

(<+) :: (Con b => r) -> (a |- b) -> r

(bound at src/ConCat/Category.hs:190:3)

|

190 | r <+ ~(Entail (Sub Dict)) = r

| ^

Other ideas welcome!

--

Regards,

Mike

_______________________________________________

Glasgow-haskell-users mailing list

Glasgow-haskell-users at haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20210809/e83d1603/attachment.html>

From allbery.b at gmail.com  Mon Aug  9 15:31:54 2021
From: allbery.b at gmail.com (Brandon Allbery)
Date: Mon, 9 Aug 2021 11:31:54 -0400
Subject: Avoiding construction of dead dictionaries
In-Reply-To: <zLTAlyXlXJI5vhvwXpKu1dg1uVmPOVzexAVi4BN2GNWYGE9twuZelaK4UyOe89tFqPdbTmfuvrfBEN7EP59xymXp9621ZVasYnyw-7jT8Kg=@tomsmeding.com>
References: <y9lo8aag1tk.fsf@valmont.fritz.box>
 <4uoPp42nVX4i5JRZO9XxsODOF2QZMyRoCYlrJhd6rnk0Y1AfWCQImFe7-K03IyBu0e0vy5T0-ksSRCNs9lojy9KMGI6mFPj5oQhHCvplbEA=@tomsmeding.com>
 <y9lmtpqbvja.fsf@valmont.fritz.box>
 <zLTAlyXlXJI5vhvwXpKu1dg1uVmPOVzexAVi4BN2GNWYGE9twuZelaK4UyOe89tFqPdbTmfuvrfBEN7EP59xymXp9621ZVasYnyw-7jT8Kg=@tomsmeding.com>
Message-ID: <CAKFCL4UnTJwGO9coXXQRW0KL33QFV1DiAQUJSexDEzYHjw7P2g@mail.gmail.com>

We haven't figured out what they did, but the other day we had someone in
#haskell with an infinite loop evaluating a dictionary. So apparently it is
possible for a dictionary to be bottom somehow.

On Mon, Aug 9, 2021 at 11:27 AM Tom Smeding <x at tomsmeding.com> wrote:

> Hi Mike,
>
>
> > But wouldn't that imply that ghc can build dictionary-construction code
>
> > that evaluates to bottom? Can that happen?
>
>
> I assume no, but here the dictionary is embedded as a field in the GADT,
> right? So if the data value is bottom, there is not even a dictionary to be
> found, let alone not-bottom.
>
>
> This assumes that the Dict in `Entail (Sub Dict)` is a GADT like
>
>
> Dict :: Con b => Dict something
>
>
> where the Con dictionary is contained in the GADT. Remember that in Core,
> dictionaries are values, and there is no difference between => and ->.
>
>
> - Tom
>
>
>
> -------- Original Message --------
>
> On 9 Aug 2021, 15:24, Michael Sperber < sperber at deinprogramm.de> wrote:
>
>
> Thanks for thinking about this one!
>
> On Fri, Aug 06 2021, Tom Smeding <x at tomsmeding.com> wrote:
>
> > Would it not be unsound for ghc to elide dictionary construction here?
>
> > After all, the right-hand side might actually be a bottom
>
> > (e.g. undefined) at run-time, in which case the pattern match cannot
>
> > succeed according to the semantics of Haskell.
>
> But wouldn't that imply that ghc can build dictionary-construction code
>
> that evaluates to bottom? Can that happen?
>
> > I suspect that if you make the pattern match lazy (i.e. ~(Entail (Sub
>
> > Dict))) or ignore the argument altogether (i.e. _), dictionary
>
> > construction will be elided.
>
> Thanks for the hint! ghc gives me this unfortunately, implying that it
>
> agreed with your first comment:
>
> src/ConCat/Category.hs:190:29: error:
>
> • Could not deduce: Con b arising from a use of ‘r’
>
> from the context: Con a
>
> bound by the type signature for:
>
> (<+) :: forall a b r. Con a => (Con b => r) -> (a |- b) -> r
>
> at src/ConCat/Category.hs:189:1-46
>
> • In the expression: r
>
> In an equation for ‘<+’: r <+ ~(Entail (Sub Dict)) = r
>
> • Relevant bindings include
>
> r :: Con b => r (bound at src/ConCat/Category.hs:190:1)
>
> (<+) :: (Con b => r) -> (a |- b) -> r
>
> (bound at src/ConCat/Category.hs:190:3)
>
> |
>
> 190 | r <+ ~(Entail (Sub Dict)) = r
>
> | ^
>
> Other ideas welcome!
>
> --
>
> Regards,
>
> Mike
>
> _______________________________________________
>
> Glasgow-haskell-users mailing list
>
> Glasgow-haskell-users at haskell.org
>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>


-- 
brandon s allbery kf8nh
allbery.b at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20210809/f801ec96/attachment.html>

From simonpj at microsoft.com  Mon Aug  9 15:56:27 2021
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 9 Aug 2021 15:56:27 +0000
Subject: Avoiding construction of dead dictionaries
In-Reply-To: <CAKFCL4UnTJwGO9coXXQRW0KL33QFV1DiAQUJSexDEzYHjw7P2g@mail.gmail.com>
References: <y9lo8aag1tk.fsf@valmont.fritz.box>
 <4uoPp42nVX4i5JRZO9XxsODOF2QZMyRoCYlrJhd6rnk0Y1AfWCQImFe7-K03IyBu0e0vy5T0-ksSRCNs9lojy9KMGI6mFPj5oQhHCvplbEA=@tomsmeding.com>
 <y9lmtpqbvja.fsf@valmont.fritz.box>
 <zLTAlyXlXJI5vhvwXpKu1dg1uVmPOVzexAVi4BN2GNWYGE9twuZelaK4UyOe89tFqPdbTmfuvrfBEN7EP59xymXp9621ZVasYnyw-7jT8Kg=@tomsmeding.com>
 <CAKFCL4UnTJwGO9coXXQRW0KL33QFV1DiAQUJSexDEzYHjw7P2g@mail.gmail.com>
Message-ID: <VI1PR83MB0269B9EC495C995523220823ADF69@VI1PR83MB0269.EURPRD83.prod.outlook.com>

> . So apparently it is possible for a dictionary to be bottom somehow.
That should not happen.

Except in the case of single-method dictionaries like
                class C a where op ::  a -> a
In these cases the "dictionary" is represented by a newtype, like this
                newtype C a = MkC (a->a)

Then you could say
                instance C Int where
                 op = bottom

and now a (C Int) dictionary is simply bottom.

It would be easy to change this decision, and use a data constructor even for single-method classes.  Some programs would become slightly less efficient, but things would be a bit more uniform.  If there was a real advantage to doing this, it'd definitely be worth measuring the perf cost (if any).

Simon

From: Glasgow-haskell-users <glasgow-haskell-users-bounces at haskell.org> On Behalf Of Brandon Allbery
Sent: 09 August 2021 16:32
To: Tom Smeding <x at tomsmeding.com>
Cc: GHC users <glasgow-haskell-users at haskell.org>; sperber at deinprogramm.de
Subject: Re: Avoiding construction of dead dictionaries

We haven't figured out what they did, but the other day we had someone in #haskell with an infinite loop evaluating a dictionary. So apparently it is possible for a dictionary to be bottom somehow.

On Mon, Aug 9, 2021 at 11:27 AM Tom Smeding <x at tomsmeding.com<mailto:x at tomsmeding.com>> wrote:
Hi Mike,


> But wouldn't that imply that ghc can build dictionary-construction code

> that evaluates to bottom? Can that happen?


I assume no, but here the dictionary is embedded as a field in the GADT, right? So if the data value is bottom, there is not even a dictionary to be found, let alone not-bottom.


This assumes that the Dict in `Entail (Sub Dict)` is a GADT like


Dict :: Con b => Dict something


where the Con dictionary is contained in the GADT. Remember that in Core, dictionaries are values, and there is no difference between => and ->.


- Tom



-------- Original Message --------

On 9 Aug 2021, 15:24, Michael Sperber < sperber at deinprogramm.de<mailto:sperber at deinprogramm.de>> wrote:


Thanks for thinking about this one!

On Fri, Aug 06 2021, Tom Smeding <x at tomsmeding.com<mailto:x at tomsmeding.com>> wrote:

> Would it not be unsound for ghc to elide dictionary construction here?

> After all, the right-hand side might actually be a bottom

> (e.g. undefined) at run-time, in which case the pattern match cannot

> succeed according to the semantics of Haskell.

But wouldn't that imply that ghc can build dictionary-construction code

that evaluates to bottom? Can that happen?

> I suspect that if you make the pattern match lazy (i.e. ~(Entail (Sub

> Dict))) or ignore the argument altogether (i.e. _), dictionary

> construction will be elided.

Thanks for the hint! ghc gives me this unfortunately, implying that it

agreed with your first comment:

src/ConCat/Category.hs:190:29: error:

* Could not deduce: Con b arising from a use of 'r'

from the context: Con a

bound by the type signature for:

(<+) :: forall a b r. Con a => (Con b => r) -> (a |- b) -> r

at src/ConCat/Category.hs:189:1-46

* In the expression: r

In an equation for '<+': r <+ ~(Entail (Sub Dict)) = r

* Relevant bindings include

r :: Con b => r (bound at src/ConCat/Category.hs:190:1)

(<+) :: (Con b => r) -> (a |- b) -> r

(bound at src/ConCat/Category.hs:190:3)

|

190 | r <+ ~(Entail (Sub Dict)) = r

| ^

Other ideas welcome!

--

Regards,

Mike

_______________________________________________

Glasgow-haskell-users mailing list

Glasgow-haskell-users at haskell.org<mailto:Glasgow-haskell-users at haskell.org>

http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fglasgow-haskell-users&data=04%7C01%7Csimonpj%40microsoft.com%7C7bf3769704884ed6592e08d95b4aeb26%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637641199636853840%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ix06XQPvpu%2B1PLzoc5rRQM6cMv8yPF6o87uVwD0sUwQ%3D&reserved=0>

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users at haskell.org<mailto:Glasgow-haskell-users at haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fglasgow-haskell-users&data=04%7C01%7Csimonpj%40microsoft.com%7C7bf3769704884ed6592e08d95b4aeb26%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637641199636863837%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=sQDTBnklNv7YLRvhiY5CEtbZgcZT8p7RR%2Bw57sCqFJk%3D&reserved=0>


--
brandon s allbery kf8nh
allbery.b at gmail.com<mailto:allbery.b at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20210809/5092b88d/attachment.html>

From allbery.b at gmail.com  Mon Aug  9 15:59:38 2021
From: allbery.b at gmail.com (Brandon Allbery)
Date: Mon, 9 Aug 2021 11:59:38 -0400
Subject: Avoiding construction of dead dictionaries
In-Reply-To: <VI1PR83MB0269B9EC495C995523220823ADF69@VI1PR83MB0269.EURPRD83.prod.outlook.com>
References: <y9lo8aag1tk.fsf@valmont.fritz.box>
 <4uoPp42nVX4i5JRZO9XxsODOF2QZMyRoCYlrJhd6rnk0Y1AfWCQImFe7-K03IyBu0e0vy5T0-ksSRCNs9lojy9KMGI6mFPj5oQhHCvplbEA=@tomsmeding.com>
 <y9lmtpqbvja.fsf@valmont.fritz.box>
 <zLTAlyXlXJI5vhvwXpKu1dg1uVmPOVzexAVi4BN2GNWYGE9twuZelaK4UyOe89tFqPdbTmfuvrfBEN7EP59xymXp9621ZVasYnyw-7jT8Kg=@tomsmeding.com>
 <CAKFCL4UnTJwGO9coXXQRW0KL33QFV1DiAQUJSexDEzYHjw7P2g@mail.gmail.com>
 <VI1PR83MB0269B9EC495C995523220823ADF69@VI1PR83MB0269.EURPRD83.prod.outlook.com>
Message-ID: <CAKFCL4V808mxedVKZPXK-gJur0b2BA=iP-z=S8c_o_ppMEgzig@mail.gmail.com>

They didn't show code (this is sadly common), so we had only speculation. :(

On Mon, Aug 9, 2021 at 11:56 AM Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> > . So apparently it is possible for a dictionary to be bottom somehow.
>
> That should not happen.
>
>
>
> Except in the case of single-method dictionaries like
>
>                 class C a where op ::  a -> a
>
> In these cases the “dictionary” is represented by a newtype, like this
>
>                 newtype C a = MkC (a->a)
>
>
>
> Then you could say
>
>                 instance C Int where
>
>                  op = bottom
>
>
>
> and now a (C Int) dictionary is simply bottom.
>
>
>
> It would be easy to change this decision, and use a data constructor even
> for single-method classes.  Some programs would become slightly less
> efficient, but things would be a bit more uniform.  If there was a real
> advantage to doing this, it’d definitely be worth measuring the perf cost
> (if any).
>
>
>
> Simon
>
>
>
> *From:* Glasgow-haskell-users <glasgow-haskell-users-bounces at haskell.org> *On
> Behalf Of *Brandon Allbery
> *Sent:* 09 August 2021 16:32
> *To:* Tom Smeding <x at tomsmeding.com>
> *Cc:* GHC users <glasgow-haskell-users at haskell.org>;
> sperber at deinprogramm.de
> *Subject:* Re: Avoiding construction of dead dictionaries
>
>
>
> We haven't figured out what they did, but the other day we had someone in
> #haskell with an infinite loop evaluating a dictionary. So apparently it is
> possible for a dictionary to be bottom somehow.
>
>
>
> On Mon, Aug 9, 2021 at 11:27 AM Tom Smeding <x at tomsmeding.com> wrote:
>
> Hi Mike,
>
>
>
>
>
> > But wouldn't that imply that ghc can build dictionary-construction code
>
>
>
> > that evaluates to bottom? Can that happen?
>
>
>
>
>
> I assume no, but here the dictionary is embedded as a field in the GADT,
> right? So if the data value is bottom, there is not even a dictionary to be
> found, let alone not-bottom.
>
>
>
>
>
> This assumes that the Dict in `Entail (Sub Dict)` is a GADT like
>
>
>
>
>
> Dict :: Con b => Dict something
>
>
>
>
>
> where the Con dictionary is contained in the GADT. Remember that in Core,
> dictionaries are values, and there is no difference between => and ->.
>
>
>
>
>
> - Tom
>
>
>
>
>
>
>
> -------- Original Message --------
>
>
>
> On 9 Aug 2021, 15:24, Michael Sperber < sperber at deinprogramm.de> wrote:
>
>
>
>
>
> Thanks for thinking about this one!
>
>
>
> On Fri, Aug 06 2021, Tom Smeding <x at tomsmeding.com> wrote:
>
>
>
> > Would it not be unsound for ghc to elide dictionary construction here?
>
>
>
> > After all, the right-hand side might actually be a bottom
>
>
>
> > (e.g. undefined) at run-time, in which case the pattern match cannot
>
>
>
> > succeed according to the semantics of Haskell.
>
>
>
> But wouldn't that imply that ghc can build dictionary-construction code
>
>
>
> that evaluates to bottom? Can that happen?
>
>
>
> > I suspect that if you make the pattern match lazy (i.e. ~(Entail (Sub
>
>
>
> > Dict))) or ignore the argument altogether (i.e. _), dictionary
>
>
>
> > construction will be elided.
>
>
>
> Thanks for the hint! ghc gives me this unfortunately, implying that it
>
>
>
> agreed with your first comment:
>
>
>
> src/ConCat/Category.hs:190:29: error:
>
>
>
> • Could not deduce: Con b arising from a use of ‘r’
>
>
>
> from the context: Con a
>
>
>
> bound by the type signature for:
>
>
>
> (<+) :: forall a b r. Con a => (Con b => r) -> (a |- b) -> r
>
>
>
> at src/ConCat/Category.hs:189:1-46
>
>
>
> • In the expression: r
>
>
>
> In an equation for ‘<+’: r <+ ~(Entail (Sub Dict)) = r
>
>
>
> • Relevant bindings include
>
>
>
> r :: Con b => r (bound at src/ConCat/Category.hs:190:1)
>
>
>
> (<+) :: (Con b => r) -> (a |- b) -> r
>
>
>
> (bound at src/ConCat/Category.hs:190:3)
>
>
>
> |
>
>
>
> 190 | r <+ ~(Entail (Sub Dict)) = r
>
>
>
> | ^
>
>
>
> Other ideas welcome!
>
>
>
> --
>
>
>
> Regards,
>
>
>
> Mike
>
>
>
> _______________________________________________
>
>
>
> Glasgow-haskell-users mailing list
>
>
>
> Glasgow-haskell-users at haskell.org
>
>
>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fglasgow-haskell-users&data=04%7C01%7Csimonpj%40microsoft.com%7C7bf3769704884ed6592e08d95b4aeb26%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637641199636853840%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ix06XQPvpu%2B1PLzoc5rRQM6cMv8yPF6o87uVwD0sUwQ%3D&reserved=0>
>
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fglasgow-haskell-users&data=04%7C01%7Csimonpj%40microsoft.com%7C7bf3769704884ed6592e08d95b4aeb26%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637641199636863837%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=sQDTBnklNv7YLRvhiY5CEtbZgcZT8p7RR%2Bw57sCqFJk%3D&reserved=0>
>
>
>
>
> --
>
> brandon s allbery kf8nh
>
> allbery.b at gmail.com
>


-- 
brandon s allbery kf8nh
allbery.b at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20210809/56a04046/attachment.html>

From claude at mathr.co.uk  Mon Aug  9 16:00:28 2021
From: claude at mathr.co.uk (Claude Heiland-Allen)
Date: Mon, 9 Aug 2021 17:00:28 +0100
Subject: Avoiding construction of dead dictionaries
In-Reply-To: <CAKFCL4UnTJwGO9coXXQRW0KL33QFV1DiAQUJSexDEzYHjw7P2g@mail.gmail.com>
References: <y9lo8aag1tk.fsf@valmont.fritz.box>
 <4uoPp42nVX4i5JRZO9XxsODOF2QZMyRoCYlrJhd6rnk0Y1AfWCQImFe7-K03IyBu0e0vy5T0-ksSRCNs9lojy9KMGI6mFPj5oQhHCvplbEA=@tomsmeding.com>
 <y9lmtpqbvja.fsf@valmont.fritz.box>
 <zLTAlyXlXJI5vhvwXpKu1dg1uVmPOVzexAVi4BN2GNWYGE9twuZelaK4UyOe89tFqPdbTmfuvrfBEN7EP59xymXp9621ZVasYnyw-7jT8Kg=@tomsmeding.com>
 <CAKFCL4UnTJwGO9coXXQRW0KL33QFV1DiAQUJSexDEzYHjw7P2g@mail.gmail.com>
Message-ID: <3d421491-b277-325a-670a-039e4a2920bc@mathr.co.uk>

Hi all,

On 09/08/2021 16:31, Brandon Allbery wrote:
> We haven't figured out what they did, but the other day we had someone 
> in #haskell with an infinite loop evaluating a dictionary. So 
> apparently it is possible for a dictionary to be bottom somehow.

I managed to do something like this once: I was using type level natural 
numbers to parameterize my type, and through carelessness my dictionary 
for `T n` depended on the dictionary for `T (Succ n)`.  My heap profile 
was a triangular wedge with space taken up by dictionaries growing 
linearly without bound.


Claude

-- 

https://mathr.co.uk



From simonpj at microsoft.com  Mon Aug  9 16:05:30 2021
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 9 Aug 2021 16:05:30 +0000
Subject: Avoiding construction of dead dictionaries
In-Reply-To: <y9lo8aag1tk.fsf@valmont.fritz.box>
References: <y9lo8aag1tk.fsf@valmont.fritz.box>
Message-ID: <VI1PR83MB02690B4E25F99252893586CEADF69@VI1PR83MB0269.EURPRD83.prod.outlook.com>

Hi Mike

|  The right-hand argument of <+ leads to a dictionary construction that is a
|  proof of a certain property, but the dictionary itself ends up being dead,
|  like so:
|  
|        case $w$dOpCon_r2kGJ ...
|        of
|        { (# ww1_s27L3 #) -> ... }
|             ^^^^^^^^^
|             never used

GHC needs to figure out that $w$dOpCon_r2kGJ always terminates, without throwing an exception etc.  That can't be too hard, and Sebastian Graf has thought about it quite a bit.

Could you offer a small repro case, with a pointer to evidence that it matters in practice, and open a ticket?

Thanks

Simon

|  -----Original Message-----
|  From: Glasgow-haskell-users <glasgow-haskell-users-bounces at haskell.org> On
|  Behalf Of Michael Sperber
|  Sent: 06 August 2021 14:06
|  To: glasgow-haskell-users at haskell.org
|  Subject: Avoiding construction of dead dictionaries
|  
|  [You don't often get email from sperber at deinprogramm.de. Learn why this is
|  important at http://aka.ms/LearnAboutSenderIdentification.]
|  
|  I have another optimization problem.  ConCat includes this definition:
|  
|  (<+) :: Con a => (Con b => r) -> (a |- b) -> r r <+ Entail (Sub Dict) = r
|  
|  The right-hand argument of <+ leads to a dictionary construction that is a
|  proof of a certain property, but the dictionary itself ends up being dead,
|  like so:
|  
|        case $w$dOpCon_r2kGJ ...
|        of
|        { (# ww1_s27L3 #) -> ... }
|             ^^^^^^^^^
|             never used
|  
|  Yet, ghc (8.10.4) never elides this code.  (I'm naively assuming because of
|  the unboxed tuple, but actually have no clue.)
|  
|  Is there any chance of convincing ghc of erasing the dictionary
|  construction?
|  
|  Help would be much appreciated!
|  
|  --
|  Regards,
|  Mike
|  
|  _______________________________________________
|  Glasgow-haskell-users mailing list
|  Glasgow-haskell-users at haskell.org
|  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskel
|  l.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fglasgow-haskell-
|  users&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C301c6f15cc1142fc645908d95
|  8dc725a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637638526127543532%7CUn
|  known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX
|  VCI6Mn0%3D%7C2000&amp;sdata=fh2YiJ5NuDMPzpzzxsAL0MyceMFH0MuveNgvTo7ZNow%3D&a
|  mp;reserved=0

From simonpj at microsoft.com  Tue Aug 10 09:15:51 2021
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 10 Aug 2021 09:15:51 +0000
Subject: InstanceSigs -- rationale for the "must be more polymorphic than"
In-Reply-To: <CAMgWh9vD7KZWG_TRkjUwxH6psyfAyNhqOTF4GvfteY_WFYDzKA@mail.gmail.com>
References: <CABU_mxgQKzksVgVTZ7tDhLps1k6zJwqZ4e3+PPE1YtwN05M0dg@mail.gmail.com>
 <CAMgWh9vD7KZWG_TRkjUwxH6psyfAyNhqOTF4GvfteY_WFYDzKA@mail.gmail.com>
Message-ID: <VI1PR83MB02697E58548D71ABB850ED43ADF79@VI1PR83MB0269.EURPRD83.prod.outlook.com>

AntC,

I think you see why the instance sig must be at least as polymorphic than the instantiated signature from the class - because that's what the client is going to expect.  We are building a record of functions, and they must conform to the class signature.

I agree with David's (1) and (2) reasons, but not with (3) or (4), neither of which I quite understand.

There is no compelling reason to make the instance signature more polymorphic - that is, doing so does not increase expressiveness.  But it might make a briefer, more comprehensible type for the reader.  The only alternative would be to insist that the two types are the same, a completely redundant test, but one you might conceivably want on stylistic grounds.

All in all, no big deal.  Instance signature are a convenience, never a necessity.

If you would like to offer a patch for the user manual to explain this better, that would be great.

Simon

From: Glasgow-haskell-users <glasgow-haskell-users-bounces at haskell.org> On Behalf Of David Feuer
Sent: 08 August 2021 09:37
To: Anthony Clayden <anthony.d.clayden at gmail.com>
Cc: GHC users <glasgow-haskell-users at haskell.org>
Subject: Re: InstanceSigs -- rationale for the "must be more polymorphic than"

To the best of my knowledge, `InstanceSigs` are never strictly necessary. They can, however, be useful for at least four purposes:

1. To provide a compiler-checked reminder of the type.
2. To bind type variables with `ScopedTypeVariables`.
3. To generalize the type so you can use polymorphic recursion.
4. To enhance parametricitry/polymorphism for internal documentation purposes.

The third reason is probably the main technical one to allow a more general signature, but the fourth is likely helpful too.

On Sun, Aug 8, 2021, 3:04 AM Anthony Clayden <anthony.d.clayden at gmail.com<mailto:anthony.d.clayden at gmail.com>> wrote:
I can't help but feel InstanceSigs are either superfluous or upside-down. It's this bit in the User Guide:

> The type signature in the instance declaration must be
> more polymorphic than (or the same as) the one in the class declaration,
> instantiated with the instance type.

Usually if you give a signature, it must be _less_ polymorphic (or the same as) the type inferred from the term:

>    lessPolyPlus :: Integral a => a -> a -> a
>    lessPolyPlus x y = x + y

Or

>    lessPolyPlus (x :: a) y = x + y :: Integral a => a

The examples in the User Guide aren't helping: you could just drop the InstanceSigs, and all is well-typed. (Even the example alleging to use -XScopedTypeVariables in a where sub-decl: you could just put random `xs :: [b]` without scoping `b`.)

Dropping the Sigs altogether works because the type from the class decl, suitably instantiated, is less polymorphic than inferred from the term. IOW the suitably instantiated type restricts what would otherwise be inferred. Situation normal.

I suppose it might be helpful to give an explicit InstanceSig as 'belt and braces' for the instantiated -- possibly because the instantiation is hard to figure out; possibly because you want to use -XScopedTypeVariables within a where-bound sub-decl, as an extra piece of string.

I can see you mustn't make the InstanceSig _less_ polymorphic than the suitably instantiated.

But the docos don't give any example where it's essential to provide an InstanceSig _and_  make it strictly more polymorphic. Here all the sigs and annotations are just superfluous:

>    maxPolyPlus :: Num a => a -> a -> a
>    maxPolyPlus = (+)
>
>    class C a  where foo :: a -> T a
>    instance Integral a => C a  where
>      foo :: Num a => a -> T a
>      foo (x :: a) = MkT (maxPolyPlus x x :: Num a => a)

Is there a persuasive example (to put in the User Guide)?

AntC

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users at haskell.org<mailto:Glasgow-haskell-users at haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fglasgow-haskell-users&data=04%7C01%7Csimonpj%40microsoft.com%7C51928cea45a84d24d62508d95a47ba3c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637640086425578886%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=qY9jOKGv3RIFPCuVT%2FZIBfaBBofcm6p7PG3yfq%2FJRiM%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20210810/12811913/attachment.html>

From simonpj at microsoft.com  Tue Aug 10 09:15:53 2021
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 10 Aug 2021 09:15:53 +0000
Subject: -dinline-check for symbolic names?
In-Reply-To: <y9lsfzmg2v4.fsf@valmont.fritz.box>
References: <y9lmtpxi66h.fsf@valmont.fritz.box>
 <CAHYVw0zrkVaFF2yFs_pX9Tdvtzs+C3JFW5Ev_DPd8vYWeY=EcA@mail.gmail.com>
 <y9lwnoyg3i9.fsf@valmont.fritz.box> <y9lsfzmg2v4.fsf@valmont.fritz.box>
Message-ID: <VI1PR83MB0269D9905F3E52ECCE8C4DB4ADF79@VI1PR83MB0269.EURPRD83.prod.outlook.com>

It's hard to tell what is happening without a repro case. Can you share one?

You suggested that it might have something to do with using an operator.   Does the same thing happen if you replace the operator with an alpha-numeric name?

Simon

| -----Original Message-----
| From: Glasgow-haskell-users <glasgow-haskell-users-bounces at haskell.org>
| On Behalf Of Michael Sperber
| Sent: 06 August 2021 13:44
| To: glasgow-haskell-users at haskell.org
| Subject: Re: -dinline-check for symbolic names?
| 
| [You don't often get email from sperber at deinprogramm.de. Learn why this
| is important at http://aka.ms/LearnAboutSenderIdentification.]
| 
| On Fri, Aug 06 2021, Michael Sperber <sperber at deinprogramm.de> wrote:
| 
| > On Wed, Aug 04 2021, Carter Schonwald <carter.schonwald at gmail.com>
| wrote:
| >
| >> I'm not sure about the pragma debugging, but are you using it in
| >> point free style? Cause I'm that case it may not be inclined because
| >> it's not being fully applied on the left hand side?
| >
| > Good point, but I checked, and it's fully applied. :-(
| 
| Another note: Once I change the INLINE to INLINE [0], everything works:
| (&&&) gets inlined, and -dinline-check works.  Explanation welcome ...
| 
| --
| Regards,
| Mike
| 
| _______________________________________________
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users at haskell.org
| https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.has
| kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fglasgow-haskell-
| users&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C7b8c76634e3c4ce86a7008
| d958d801ac%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63763850704993823
| 2%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1
| haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=DZHraN9nVbZMWxmekmYP2sAqRBh1qNbVWUlo
| JQdKnkc%3D&amp;reserved=0

From david.feuer at gmail.com  Tue Aug 10 11:00:49 2021
From: david.feuer at gmail.com (David Feuer)
Date: Tue, 10 Aug 2021 07:00:49 -0400
Subject: InstanceSigs -- rationale for the "must be more polymorphic than"
In-Reply-To: <VI1PR83MB02697E58548D71ABB850ED43ADF79@VI1PR83MB0269.EURPRD83.prod.outlook.com>
References: <CABU_mxgQKzksVgVTZ7tDhLps1k6zJwqZ4e3+PPE1YtwN05M0dg@mail.gmail.com>
 <CAMgWh9vD7KZWG_TRkjUwxH6psyfAyNhqOTF4GvfteY_WFYDzKA@mail.gmail.com>
 <VI1PR83MB02697E58548D71ABB850ED43ADF79@VI1PR83MB0269.EURPRD83.prod.outlook.com>
Message-ID: <CAMgWh9vMeapahdx9vwh1wSQRiPJDsTf3tPN3TnMok_LSbTRtmg@mail.gmail.com>

Simon, there are times when a function has to be generalized to be made
polymorphic recursive. Perhaps the method takes an argument of type x (not
a class parameter), but to call itself, it needs to be able to take types
x, T x, T (T x), etc. That additional polymorphism can be introduced in the
instance signature. The alternative is to introduce a helper function with
extra polymorphism.

On Tue, Aug 10, 2021, 5:15 AM Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> AntC,
>
>
>
> I think you see why the instance sig must be at least as polymorphic than
> the instantiated signature from the class – because that’s what the client
> is going to expect.  We are building a record of functions, and they must
> conform to the class signature.
>
>
>
> I agree with David’s (1) and (2) reasons, but not with (3) or (4), neither
> of which I quite understand.
>
>
>
> There is no compelling reason to make the instance signature *more*
> polymorphic – that is, doing so does not increase expressiveness.  But it
> might make a briefer, more comprehensible type for the reader.  The only
> alternative would be to insist that the two types are the same, a
> completely redundant test, but one you might conceivably want on stylistic
> grounds.
>
>
>
> All in all, no big deal.  Instance signature are a convenience, never a
> necessity.
>
>
>
> If you would like to offer a patch for the user manual to explain this
> better, that would be great.
>
>
>
> Simon
>
>
>
> *From:* Glasgow-haskell-users <glasgow-haskell-users-bounces at haskell.org> *On
> Behalf Of *David Feuer
> *Sent:* 08 August 2021 09:37
> *To:* Anthony Clayden <anthony.d.clayden at gmail.com>
> *Cc:* GHC users <glasgow-haskell-users at haskell.org>
> *Subject:* Re: InstanceSigs -- rationale for the "must be more
> polymorphic than"
>
>
>
> To the best of my knowledge, `InstanceSigs` are never strictly necessary.
> They can, however, be useful for at least four purposes:
>
>
>
> 1. To provide a compiler-checked reminder of the type.
>
> 2. To bind type variables with `ScopedTypeVariables`.
>
> 3. To generalize the type so you can use polymorphic recursion.
>
> 4. To enhance parametricitry/polymorphism for internal documentation
> purposes.
>
>
>
> The third reason is probably the main technical one to allow a more
> general signature, but the fourth is likely helpful too.
>
>
>
> On Sun, Aug 8, 2021, 3:04 AM Anthony Clayden <anthony.d.clayden at gmail.com>
> wrote:
>
> I can't help but feel InstanceSigs are either superfluous or upside-down.
> It's this bit in the User Guide:
>
>
>
> > The type signature in the instance declaration must be
>
> > more polymorphic than (or the same as) the one in the class declaration,
>
> > instantiated with the instance type.
>
>
>
> Usually if you give a signature, it must be _less_ polymorphic (or the
> same as) the type inferred from the term:
>
>
>
> >    lessPolyPlus :: Integral a => a -> a -> a
>
> >    lessPolyPlus x y = x + y
>
>
>
> Or
>
>
>
> >    lessPolyPlus (x :: a) y = x + y :: Integral a => a
>
>
>
> The examples in the User Guide aren't helping: you could just drop the
> InstanceSigs, and all is well-typed. (Even the example alleging to use
> -XScopedTypeVariables in a where sub-decl: you could just put random `xs ::
> [b]` without scoping `b`.)
>
>
>
> Dropping the Sigs altogether works because the type from the class decl,
> suitably instantiated, is less polymorphic than inferred from the term. IOW
> the suitably instantiated type restricts what would otherwise be inferred.
> Situation normal.
>
>
>
> I suppose it might be helpful to give an explicit InstanceSig as 'belt and
> braces' for the instantiated -- possibly because the instantiation is hard
> to figure out; possibly because you want to use -XScopedTypeVariables
> within a where-bound sub-decl, as an extra piece of string.
>
>
>
> I can see you mustn't make the InstanceSig _less_ polymorphic than the
> suitably instantiated.
>
>
>
> But the docos don't give any example where it's essential to provide an
> InstanceSig _and_  make it strictly more polymorphic. Here all the sigs and
> annotations are just superfluous:
>
>
>
> >    maxPolyPlus :: Num a => a -> a -> a
> >    maxPolyPlus = (+)
> >
>
> >    class C a  where foo :: a -> T a
> >    instance Integral a => C a  where
> >      foo :: Num a => a -> T a
> >      foo (x :: a) = MkT (maxPolyPlus x x :: Num a => a)
>
>
>
> Is there a persuasive example (to put in the User Guide)?
>
>
>
> AntC
>
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fglasgow-haskell-users&data=04%7C01%7Csimonpj%40microsoft.com%7C51928cea45a84d24d62508d95a47ba3c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637640086425578886%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=qY9jOKGv3RIFPCuVT%2FZIBfaBBofcm6p7PG3yfq%2FJRiM%3D&reserved=0>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20210810/f9ce2876/attachment.html>

From simonpj at microsoft.com  Tue Aug 10 19:15:09 2021
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 10 Aug 2021 19:15:09 +0000
Subject: InstanceSigs -- rationale for the "must be more polymorphic than"
In-Reply-To: <CAMgWh9vMeapahdx9vwh1wSQRiPJDsTf3tPN3TnMok_LSbTRtmg@mail.gmail.com>
References: <CABU_mxgQKzksVgVTZ7tDhLps1k6zJwqZ4e3+PPE1YtwN05M0dg@mail.gmail.com>
 <CAMgWh9vD7KZWG_TRkjUwxH6psyfAyNhqOTF4GvfteY_WFYDzKA@mail.gmail.com>
 <VI1PR83MB02697E58548D71ABB850ED43ADF79@VI1PR83MB0269.EURPRD83.prod.outlook.com>
 <CAMgWh9vMeapahdx9vwh1wSQRiPJDsTf3tPN3TnMok_LSbTRtmg@mail.gmail.com>
Message-ID: <VI1PR83MB02695652B50AEA44C1716C9DADF79@VI1PR83MB0269.EURPRD83.prod.outlook.com>

Do you have a concrete example?

I think that the recursive calls will all go via the original class method with its original type - we can't know that it's calling *this* instance till much later.   So I still don't get it.  An example would clear it up.

Simon

From: David Feuer <david.feuer at gmail.com>
Sent: 10 August 2021 12:01
To: Simon Peyton Jones <simonpj at microsoft.com>
Cc: Anthony Clayden <anthony.d.clayden at gmail.com>; GHC users <glasgow-haskell-users at haskell.org>
Subject: Re: InstanceSigs -- rationale for the "must be more polymorphic than"

Simon, there are times when a function has to be generalized to be made polymorphic recursive. Perhaps the method takes an argument of type x (not a class parameter), but to call itself, it needs to be able to take types x, T x, T (T x), etc. That additional polymorphism can be introduced in the instance signature. The alternative is to introduce a helper function with extra polymorphism.

On Tue, Aug 10, 2021, 5:15 AM Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
AntC,

I think you see why the instance sig must be at least as polymorphic than the instantiated signature from the class - because that's what the client is going to expect.  We are building a record of functions, and they must conform to the class signature.

I agree with David's (1) and (2) reasons, but not with (3) or (4), neither of which I quite understand.

There is no compelling reason to make the instance signature more polymorphic - that is, doing so does not increase expressiveness.  But it might make a briefer, more comprehensible type for the reader.  The only alternative would be to insist that the two types are the same, a completely redundant test, but one you might conceivably want on stylistic grounds.

All in all, no big deal.  Instance signature are a convenience, never a necessity.

If you would like to offer a patch for the user manual to explain this better, that would be great.

Simon

From: Glasgow-haskell-users <glasgow-haskell-users-bounces at haskell.org<mailto:glasgow-haskell-users-bounces at haskell.org>> On Behalf Of David Feuer
Sent: 08 August 2021 09:37
To: Anthony Clayden <anthony.d.clayden at gmail.com<mailto:anthony.d.clayden at gmail.com>>
Cc: GHC users <glasgow-haskell-users at haskell.org<mailto:glasgow-haskell-users at haskell.org>>
Subject: Re: InstanceSigs -- rationale for the "must be more polymorphic than"

To the best of my knowledge, `InstanceSigs` are never strictly necessary. They can, however, be useful for at least four purposes:

1. To provide a compiler-checked reminder of the type.
2. To bind type variables with `ScopedTypeVariables`.
3. To generalize the type so you can use polymorphic recursion.
4. To enhance parametricitry/polymorphism for internal documentation purposes.

The third reason is probably the main technical one to allow a more general signature, but the fourth is likely helpful too.

On Sun, Aug 8, 2021, 3:04 AM Anthony Clayden <anthony.d.clayden at gmail.com<mailto:anthony.d.clayden at gmail.com>> wrote:
I can't help but feel InstanceSigs are either superfluous or upside-down. It's this bit in the User Guide:

> The type signature in the instance declaration must be
> more polymorphic than (or the same as) the one in the class declaration,
> instantiated with the instance type.

Usually if you give a signature, it must be _less_ polymorphic (or the same as) the type inferred from the term:

>    lessPolyPlus :: Integral a => a -> a -> a
>    lessPolyPlus x y = x + y

Or

>    lessPolyPlus (x :: a) y = x + y :: Integral a => a

The examples in the User Guide aren't helping: you could just drop the InstanceSigs, and all is well-typed. (Even the example alleging to use -XScopedTypeVariables in a where sub-decl: you could just put random `xs :: [b]` without scoping `b`.)

Dropping the Sigs altogether works because the type from the class decl, suitably instantiated, is less polymorphic than inferred from the term. IOW the suitably instantiated type restricts what would otherwise be inferred. Situation normal.

I suppose it might be helpful to give an explicit InstanceSig as 'belt and braces' for the instantiated -- possibly because the instantiation is hard to figure out; possibly because you want to use -XScopedTypeVariables within a where-bound sub-decl, as an extra piece of string.

I can see you mustn't make the InstanceSig _less_ polymorphic than the suitably instantiated.

But the docos don't give any example where it's essential to provide an InstanceSig _and_  make it strictly more polymorphic. Here all the sigs and annotations are just superfluous:

>    maxPolyPlus :: Num a => a -> a -> a
>    maxPolyPlus = (+)
>
>    class C a  where foo :: a -> T a
>    instance Integral a => C a  where
>      foo :: Num a => a -> T a
>      foo (x :: a) = MkT (maxPolyPlus x x :: Num a => a)

Is there a persuasive example (to put in the User Guide)?

AntC

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users at haskell.org<mailto:Glasgow-haskell-users at haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fglasgow-haskell-users&data=04%7C01%7Csimonpj%40microsoft.com%7Cd48d198da4444de65d9008d95bee2560%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637641900674544282%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=j0m45j8G%2FJ7u6uHUB%2BwNQ0xM0p%2BMic3%2BM85xYud2U90%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20210810/7faeae6d/attachment.html>

From david.feuer at gmail.com  Tue Aug 10 19:18:20 2021
From: david.feuer at gmail.com (David Feuer)
Date: Tue, 10 Aug 2021 15:18:20 -0400
Subject: InstanceSigs -- rationale for the "must be more polymorphic than"
In-Reply-To: <VI1PR83MB02695652B50AEA44C1716C9DADF79@VI1PR83MB0269.EURPRD83.prod.outlook.com>
References: <CABU_mxgQKzksVgVTZ7tDhLps1k6zJwqZ4e3+PPE1YtwN05M0dg@mail.gmail.com>
 <CAMgWh9vD7KZWG_TRkjUwxH6psyfAyNhqOTF4GvfteY_WFYDzKA@mail.gmail.com>
 <VI1PR83MB02697E58548D71ABB850ED43ADF79@VI1PR83MB0269.EURPRD83.prod.outlook.com>
 <CAMgWh9vMeapahdx9vwh1wSQRiPJDsTf3tPN3TnMok_LSbTRtmg@mail.gmail.com>
 <VI1PR83MB02695652B50AEA44C1716C9DADF79@VI1PR83MB0269.EURPRD83.prod.outlook.com>
Message-ID: <CAMgWh9ueQVPozf25oed5piiBrLp_2FyQZeadQXAde_ss3WnodQ@mail.gmail.com>

Ah, I see. Yes, you're right. Sorry.

On Tue, Aug 10, 2021, 3:15 PM Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> Do you have a concrete example?
>
>
>
> I think that the recursive calls will all go via the original class method
> with its original type – we can’t know that it’s calling **this**
> instance till much later.   So I still don’t get it.  An example would
> clear it up.
>
>
>
> Simon
>
>
>
> *From:* David Feuer <david.feuer at gmail.com>
> *Sent:* 10 August 2021 12:01
> *To:* Simon Peyton Jones <simonpj at microsoft.com>
> *Cc:* Anthony Clayden <anthony.d.clayden at gmail.com>; GHC users <
> glasgow-haskell-users at haskell.org>
> *Subject:* Re: InstanceSigs -- rationale for the "must be more
> polymorphic than"
>
>
>
> Simon, there are times when a function has to be generalized to be made
> polymorphic recursive. Perhaps the method takes an argument of type x (not
> a class parameter), but to call itself, it needs to be able to take types
> x, T x, T (T x), etc. That additional polymorphism can be introduced in the
> instance signature. The alternative is to introduce a helper function with
> extra polymorphism.
>
>
>
> On Tue, Aug 10, 2021, 5:15 AM Simon Peyton Jones <simonpj at microsoft.com>
> wrote:
>
> AntC,
>
>
>
> I think you see why the instance sig must be at least as polymorphic than
> the instantiated signature from the class – because that’s what the client
> is going to expect.  We are building a record of functions, and they must
> conform to the class signature.
>
>
>
> I agree with David’s (1) and (2) reasons, but not with (3) or (4), neither
> of which I quite understand.
>
>
>
> There is no compelling reason to make the instance signature *more*
> polymorphic – that is, doing so does not increase expressiveness.  But it
> might make a briefer, more comprehensible type for the reader.  The only
> alternative would be to insist that the two types are the same, a
> completely redundant test, but one you might conceivably want on stylistic
> grounds.
>
>
>
> All in all, no big deal.  Instance signature are a convenience, never a
> necessity.
>
>
>
> If you would like to offer a patch for the user manual to explain this
> better, that would be great.
>
>
>
> Simon
>
>
>
> *From:* Glasgow-haskell-users <glasgow-haskell-users-bounces at haskell.org> *On
> Behalf Of *David Feuer
> *Sent:* 08 August 2021 09:37
> *To:* Anthony Clayden <anthony.d.clayden at gmail.com>
> *Cc:* GHC users <glasgow-haskell-users at haskell.org>
> *Subject:* Re: InstanceSigs -- rationale for the "must be more
> polymorphic than"
>
>
>
> To the best of my knowledge, `InstanceSigs` are never strictly necessary.
> They can, however, be useful for at least four purposes:
>
>
>
> 1. To provide a compiler-checked reminder of the type.
>
> 2. To bind type variables with `ScopedTypeVariables`.
>
> 3. To generalize the type so you can use polymorphic recursion.
>
> 4. To enhance parametricitry/polymorphism for internal documentation
> purposes.
>
>
>
> The third reason is probably the main technical one to allow a more
> general signature, but the fourth is likely helpful too.
>
>
>
> On Sun, Aug 8, 2021, 3:04 AM Anthony Clayden <anthony.d.clayden at gmail.com>
> wrote:
>
> I can't help but feel InstanceSigs are either superfluous or upside-down.
> It's this bit in the User Guide:
>
>
>
> > The type signature in the instance declaration must be
>
> > more polymorphic than (or the same as) the one in the class declaration,
>
> > instantiated with the instance type.
>
>
>
> Usually if you give a signature, it must be _less_ polymorphic (or the
> same as) the type inferred from the term:
>
>
>
> >    lessPolyPlus :: Integral a => a -> a -> a
>
> >    lessPolyPlus x y = x + y
>
>
>
> Or
>
>
>
> >    lessPolyPlus (x :: a) y = x + y :: Integral a => a
>
>
>
> The examples in the User Guide aren't helping: you could just drop the
> InstanceSigs, and all is well-typed. (Even the example alleging to use
> -XScopedTypeVariables in a where sub-decl: you could just put random `xs ::
> [b]` without scoping `b`.)
>
>
>
> Dropping the Sigs altogether works because the type from the class decl,
> suitably instantiated, is less polymorphic than inferred from the term. IOW
> the suitably instantiated type restricts what would otherwise be inferred.
> Situation normal.
>
>
>
> I suppose it might be helpful to give an explicit InstanceSig as 'belt and
> braces' for the instantiated -- possibly because the instantiation is hard
> to figure out; possibly because you want to use -XScopedTypeVariables
> within a where-bound sub-decl, as an extra piece of string.
>
>
>
> I can see you mustn't make the InstanceSig _less_ polymorphic than the
> suitably instantiated.
>
>
>
> But the docos don't give any example where it's essential to provide an
> InstanceSig _and_  make it strictly more polymorphic. Here all the sigs and
> annotations are just superfluous:
>
>
>
> >    maxPolyPlus :: Num a => a -> a -> a
> >    maxPolyPlus = (+)
> >
>
> >    class C a  where foo :: a -> T a
> >    instance Integral a => C a  where
> >      foo :: Num a => a -> T a
> >      foo (x :: a) = MkT (maxPolyPlus x x :: Num a => a)
>
>
>
> Is there a persuasive example (to put in the User Guide)?
>
>
>
> AntC
>
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fglasgow-haskell-users&data=04%7C01%7Csimonpj%40microsoft.com%7Cd48d198da4444de65d9008d95bee2560%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637641900674544282%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=j0m45j8G%2FJ7u6uHUB%2BwNQ0xM0p%2BMic3%2BM85xYud2U90%3D&reserved=0>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20210810/e346b2fc/attachment.html>

From anthony.d.clayden at gmail.com  Wed Aug 11 01:35:19 2021
From: anthony.d.clayden at gmail.com (Anthony Clayden)
Date: Wed, 11 Aug 2021 13:35:19 +1200
Subject: InstanceSigs -- rationale for the "must be more polymorphic than"
In-Reply-To: <VI1PR83MB02697E58548D71ABB850ED43ADF79@VI1PR83MB0269.EURPRD83.prod.outlook.com>
References: <CABU_mxgQKzksVgVTZ7tDhLps1k6zJwqZ4e3+PPE1YtwN05M0dg@mail.gmail.com>
 <CAMgWh9vD7KZWG_TRkjUwxH6psyfAyNhqOTF4GvfteY_WFYDzKA@mail.gmail.com>
 <VI1PR83MB02697E58548D71ABB850ED43ADF79@VI1PR83MB0269.EURPRD83.prod.outlook.com>
Message-ID: <CABU_mxi4xT_vV61Ze-_go3EtmE+kest0GHOn8NMkYyfU0Sqb=Q@mail.gmail.com>

On Tue, 10 Aug 2021 at 21:15, Simon Peyton Jones <simonpj at microsoft.com>
wrote:

>
>
> I think you see why the instance sig must be at least as polymorphic ...
>

Thanks Simon, I do now see, but I'd have to say there's a heck of lot of
questions on StackOverflow (most not from me) being surprised/asking why.
See more below.


>
>
I agree with David’s (1) and (2) reasons, but not with (3) or (4), neither
> of which I quite understand.
>
>
>

(1) is documented in the User Guide, but the magic words "compiler-checked"
don't appear.

(2) is documented and illustrated, but in that example the ScopedTyVar is
superfluous.


> There is no compelling reason to make the instance signature *more*
> polymorphic
>

I think there's an ergonomics reason (which is illustrated but not
explained):

(5) If the instance is constrained, there's no need to repeat the
constraints in the InstanceSig, so reducing clutter/making the Sig easier
to read (as you say). This results in making the InstanceSig more
polymorphic:

>    data T a = MkT a a>    instance Eq a => Eq (T a) where*>   *   (==) :: T a -> T a -> Bool   -- The signature*>   *   (==) (MkT x1 x2) (MkTy y1 y2) = x1==y1 && x2==y2

That Sig could be

*>    *  (==) :: Eq a => T a -> T a -> Bool   -- repeat constraint, but clutter



> – that is, doing so does not increase expressiveness.  But it might make a
> briefer, more comprehensible type for the reader.  The only alternative
> would be to insist that the two types are the same, a completely redundant
> test, but one you might conceivably want on stylistic grounds.
>

More to the point: it would bring into scope the ScopedTyVars.


>
>
> All in all, no big deal.  Instance signature are a convenience, never a
> necessity.
>
>
>
> If you would like to offer a patch for the user manual to explain this
> better, that would be great.
>
>
>
>
[Discussion cont. from first para]:

 ... [more polymorphic] than the instantiated signature from the class –
> because that’s what the client is going to expect.  We are building a
> record of functions, and they must conform to the class signature.
>

And that answer is unsatisfactory. It amounts to: we didn't think in
advance how useful it would be to put tighter constraints on methods --
particularly for the tyvars that are 'private' to the method/not from the
instance head -- that is within Constructor classes. Allowing that would be
a partial (heh, heh) way towards 'Restricted Data Types' Hughes 1999 and
Eisenberg et al 2020 (ref'ing many earlier attempts), and indeed Haskell
Language Report vintage 1990 (the design before 'stupid theta').

I suppose it's beyond a wild dream to allow the InstanceSig to be at least
as polymoprhic wrt the types/vars from the instance head but possibly less
polymorphic wrt the method's private types/vars? The actual type inferred
would be the mgu of the InstanceSig given with the substitution from the
instance head & constraints.




>
>
> *From:* Glasgow-haskell-users <glasgow-haskell-users-bounces at haskell.org> *On
> Behalf Of *David Feuer
> *Sent:* 08 August 2021 09:37
> *To:* Anthony Clayden <anthony.d.clayden at gmail.com>
> *Cc:* GHC users <glasgow-haskell-users at haskell.org>
> *Subject:* Re: InstanceSigs -- rationale for the "must be more
> polymorphic than"
>
>
>
> To the best of my knowledge, `InstanceSigs` are never strictly necessary.
> They can, however, be useful for at least four purposes:
>
>
>
> 1. To provide a compiler-checked reminder of the type.
>
> 2. To bind type variables with `ScopedTypeVariables`.
>
> 3. To generalize the type so you can use polymorphic recursion.
>
> 4. To enhance parametricitry/polymorphism for internal documentation
> purposes.
>
>
>
> The third reason is probably the main technical one to allow a more
> general signature, but the fourth is likely helpful too.
>
>
>
> On Sun, Aug 8, 2021, 3:04 AM Anthony Clayden <anthony.d.clayden at gmail.com>
> wrote:
>
> I can't help but feel InstanceSigs are either superfluous or upside-down.
> It's this bit in the User Guide:
>
>
>
> > The type signature in the instance declaration must be
>
> > more polymorphic than (or the same as) the one in the class declaration,
>
> > instantiated with the instance type.
>
>
>
> Usually if you give a signature, it must be _less_ polymorphic (or the
> same as) the type inferred from the term:
>
>
>
> >    lessPolyPlus :: Integral a => a -> a -> a
>
> >    lessPolyPlus x y = x + y
>
>
>
> Or
>
>
>
> >    lessPolyPlus (x :: a) y = x + y :: Integral a => a
>
>
>
> The examples in the User Guide aren't helping: you could just drop the
> InstanceSigs, and all is well-typed. (Even the example alleging to use
> -XScopedTypeVariables in a where sub-decl: you could just put random `xs ::
> [b]` without scoping `b`.)
>
>
>
> Dropping the Sigs altogether works because the type from the class decl,
> suitably instantiated, is less polymorphic than inferred from the term. IOW
> the suitably instantiated type restricts what would otherwise be inferred.
> Situation normal.
>
>
>
> I suppose it might be helpful to give an explicit InstanceSig as 'belt and
> braces' for the instantiated -- possibly because the instantiation is hard
> to figure out; possibly because you want to use -XScopedTypeVariables
> within a where-bound sub-decl, as an extra piece of string.
>
>
>
> I can see you mustn't make the InstanceSig _less_ polymorphic than the
> suitably instantiated.
>
>
>
> But the docos don't give any example where it's essential to provide an
> InstanceSig _and_  make it strictly more polymorphic. Here all the sigs and
> annotations are just superfluous:
>
>
>
> >    maxPolyPlus :: Num a => a -> a -> a
> >    maxPolyPlus = (+)
> >
>
> >    class C a  where foo :: a -> T a
> >    instance Integral a => C a  where
> >      foo :: Num a => a -> T a
> >      foo (x :: a) = MkT (maxPolyPlus x x :: Num a => a)
>
>
>
> Is there a persuasive example (to put in the User Guide)?
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20210811/8ad7d94a/attachment.html>

From sperber at deinprogramm.de  Thu Aug 12 09:15:04 2021
From: sperber at deinprogramm.de (Michael Sperber)
Date: Thu, 12 Aug 2021 11:15:04 +0200
Subject: Avoiding construction of dead dictionaries
In-Reply-To: <VI1PR83MB02690B4E25F99252893586CEADF69@VI1PR83MB0269.EURPRD83.prod.outlook.com>
 (Simon Peyton Jones's message of "Mon, 9 Aug 2021 16:05:30 +0000")
References: <y9lo8aag1tk.fsf@valmont.fritz.box>
 <VI1PR83MB02690B4E25F99252893586CEADF69@VI1PR83MB0269.EURPRD83.prod.outlook.com>
Message-ID: <y9lsfzf10tj.fsf@valmont.home.active-group.de>


On Mon, Aug 09 2021, Simon Peyton Jones <simonpj at microsoft.com> wrote:

> Could you offer a small repro case, with a pointer to evidence that it matters in practice, and open a ticket?

I'll try my best, but I'm unsure how I would generate evidence.  Could
you give me a hint?

Is there any way to see how far evaluates the dictionary construction to
be able to match on that unboxed tuple?

-- 
Regards,
Mike

From simonpj at microsoft.com  Thu Aug 12 12:01:04 2021
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 12 Aug 2021 12:01:04 +0000
Subject: Avoiding construction of dead dictionaries
In-Reply-To: <y9lsfzf10tj.fsf@valmont.home.active-group.de>
References: <y9lo8aag1tk.fsf@valmont.fritz.box>
 <VI1PR83MB02690B4E25F99252893586CEADF69@VI1PR83MB0269.EURPRD83.prod.outlook.com>
 <y9lsfzf10tj.fsf@valmont.home.active-group.de>
Message-ID: <VI1PR83MB02693B1B98C36686746CB446ADF99@VI1PR83MB0269.EURPRD83.prod.outlook.com>

Hi Mike

Repro case is something like
* Here is a source or files
* Compile like this
* Look at the generated Core...observe silly thing happening

Evidence of importance could be as simple as "in my application I'm seeing a lot of these redundant dictionaries being built for no reason".  Or, stronger "this is slowing my application down by 5%".  TL;DR: is this just a curiosity that you noticed, or is it something that matters to you, and if so why?

|  Is there any way to see how far evaluates the dictionary construction to be
|  able to match on that unboxed tuple?

Not sure what you mean here, but once we have a repro case we can discuss.

Worth opening a ticket too -- email is easily lost.

Thanks

Simon

|  -----Original Message-----
|  From: Michael Sperber <sperber at deinprogramm.de>
|  Sent: 12 August 2021 10:15
|  To: Simon Peyton Jones <simonpj at microsoft.com>
|  Cc: Sebastian Graf <sgraf1337 at gmail.com>; glasgow-haskell-users at haskell.org
|  Subject: Re: Avoiding construction of dead dictionaries
|  
|  
|  On Mon, Aug 09 2021, Simon Peyton Jones <simonpj at microsoft.com> wrote:
|  
|  > Could you offer a small repro case, with a pointer to evidence that it
|  matters in practice, and open a ticket?
|  
|  I'll try my best, but I'm unsure how I would generate evidence.  Could you
|  give me a hint?
|  
|  Is there any way to see how far evaluates the dictionary construction to be
|  able to match on that unboxed tuple?
|  
|  --
|  Regards,
|  Mike

From zubin at well-typed.com  Sat Aug 14 13:10:06 2021
From: zubin at well-typed.com (Zubin Duggal)
Date: Sat, 14 Aug 2021 18:40:06 +0530
Subject: [Haskell] [ANNOUNCE] GHC 8.10.6 released
Message-ID: <20210814131006.ttd55aaxh6etlq43@zubin-msi>

The GHC team is very pleased to announce the availability of GHC 8.10.6.
Source and binary distributions are available at the [usual
place](https://downloads.haskell.org/ghc/8.10.6/).

Download Page: https://www.haskell.org/ghc/download_ghc_8_10_6.html
Blog Post: https://www.haskell.org/ghc/blog/20210814-ghc-8.10.6-released.html

This is a bugfix release, fixing many issues present in GHC 8.10.5, including:

- A fix for segmentation faults in GHCi on `aarch64-darwin` due to
   an incorrect foreign import in `haskeline`. See [this blog
   post](https://www.haskell.org/ghc/blog/20210709-capi-usage.html) by Ben Gamari
   for more details on how your library could be affected.

- A fix for a critical bug affecting Haskell Language Server (HLS) among other
   applications caused by missing RTS symbols required for statically linked
   builds of the GHC library (#19763).

- No longer emitting spurious warnings for LLVM versions (LLVM 9-12) that were
   actually supported (#19973, #19829, #19959).

- Numerous bug fixes for the new LLVM based `aarch64-darwin` backend (#20132).

- Fixes and stability improvements for the non-moving GC (#19715).

- Many other bug fixes for the RTS (#18033, #20132, #20093, #19421).

- Many packaging related fixes, including versioned `ghc-pkg` executables
   (#20087), and actually distributing GHC versions linked against the
   `integer-simple` big integer backend (#18967, #19953) on both Windows and Alpine
   Linux. Previous releases were still linked against the `GMP` library due to a
   misconfiguration of the builders.

- A significant refactoring of `process` fixing numerous bugs mostly on
   Apple platforms (#19994, [process refactoring](https://github.com/haskell/process/pull/208)).

- A FreeBSD release after fixing issues that caused GHC 8.10.5 to be unable to build
   (#19958, #19948).

- Bug fixes for the linker on Darwin platforms (#20004, #19968, #19950).

A complete list of bug fixes and improvements can be found in the [release
notes](https://downloads.haskell.org/ghc/8.10.6/docs/html/users_guide/8.10.6-notes.html).

As always, feel free to report any issues you encounter via
[gitlab.haskell.org](https://gitlab.haskell.org/ghc/ghc/-/issues/new).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20210814/26772696/attachment.sig>

From steve.t.smith at gmail.com  Sun Aug 15 01:56:40 2021
From: steve.t.smith at gmail.com (Steven Smith)
Date: Sat, 14 Aug 2021 21:56:40 -0400
Subject: [ANN] Cabal-3.6.0.0
In-Reply-To: <krzfk5jw.134ee92c-06ec-4363-8ff0-27c0012a409a@we.are.superhuman.com>
References: <krzfk5jw.134ee92c-06ec-4363-8ff0-27c0012a409a@we.are.superhuman.com>
Message-ID: <B382EB2B-7D59-4478-893D-B93F0057101D@gmail.com>

Thank you! Will the release be posted to the haskell downloads site?

https://downloads.haskell.org/~cabal/

Several package managers (e.g. MacPorts) build using this site.


> On Aug 5, 2021, at 5:27 PM, Emily Pillmore <emilypi at cohomolo.gy> wrote:
> 
> Hello All,
> 
> The Cabal team is excited to announce the release of Cabal-3.6.0.0!
> 
> 
> This is the fourth release of the 3.0 release series, and highlights include support for GHC 9.2, as well as many new code quality improvements + organization work on the repo itself.
> 
> For future plans, we've announced a State of the Cabal post which describes where we want to take the library and executable over the next year or two here: https://discourse.haskell.org/t/state-of-the-cabal-q1-q2-2021/2548 <https://discourse.haskell.org/t/state-of-the-cabal-q1-q2-2021/2548>.
> 
> If you'd like to get involved, feel free to contact anyone from the maintainer team directly, or drop by #hackage on libera.chat <http://libera.chat/> to speak with us. Additionally, as we continue to modernize Cabal, I'd like to highlight and show appreciation for all of the help we've gotten from the community, including the developer hours coming from Well-Typed, Haskell Foundation/Haskell.org <http://foundation/Haskell.org>, Obsidian Systems, and the Haskell Language Server folks. I'm glad we could work together!
> 
> For a full set of release notes, see https://github.com/haskell/cabal/blob/master/release-notes/Cabal-3.6.0.0.md <https://github.com/haskell/cabal/blob/master/release-notes/Cabal-3.6.0.0.md>. If you have issues, we'd love to hear about there here: https://github.com/haskell/cabal/issues <https://github.com/haskell/cabal/issues>.
> 
> Happy hacking!
> 
> Emily
> 
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20210814/2a0487f8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3898 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20210814/2a0487f8/attachment.bin>

From emilypi at cohomolo.gy  Sun Aug 15 02:17:40 2021
From: emilypi at cohomolo.gy (Emily Pillmore)
Date: Sun, 15 Aug 2021 02:17:40 +0000
Subject: [ANN] Cabal-3.6.0.0
In-Reply-To: <B382EB2B-7D59-4478-893D-B93F0057101D@gmail.com>
References: <krzfk5jw.134ee92c-06ec-4363-8ff0-27c0012a409a@we.are.superhuman.com>
 <B382EB2B-7D59-4478-893D-B93F0057101D@gmail.com>
Message-ID: <kscksxvj.bcaab278-cd39-4951-9bec-b3ecdd32cac3@we.are.superhuman.com>

It already exists on the site, but it looks like the old dirs are cached

On Sat, Aug 14, 2021 at 7:56 PM, Steven Smith < steve.t.smith at gmail.com > wrote:

> 
> Thank you! Will the release be posted to the haskell downloads site?
> 
> 
> https:/ / downloads. haskell. org/ ~cabal/ (
> https://downloads.haskell.org/~cabal/ )
> 
> 
> Several package managers (e.g. MacPorts) build using this site.
> 
> 
> 
>> On Aug 5, 2021, at 5:27 PM, Emily Pillmore < emilypi@ cohomolo. gy (
>> emilypi at cohomolo.gy ) > wrote:
>> 
>> Hello All,
>> 
>> 
>> 
>> The Cabal team is excited to announce the release of Cabal-3.6.0.0!
>> 
>> 
>> 
>> 
>> 
>> This is the fourth release of the 3.0 release series, and highlights
>> include support for GHC 9.2, as well as many new code quality improvements
>> + organization work on the repo itself.
>> 
>> 
>> 
>> For future plans, we've announced a State of the Cabal post which
>> describes where we want to take the library and executable over the next
>> year or two here: https:/ / discourse. haskell. org/ t/ state-of-the-cabal-q1-q2-2021/
>> 2548 ( https://discourse.haskell.org/t/state-of-the-cabal-q1-q2-2021/2548 )
>> .
>> 
>> 
>> 
>> If you'd like to get involved, feel free to contact anyone from the
>> maintainer team directly, or drop by #hackage on libera. chat (
>> http://libera.chat/ ) to speak with us. Additionally, as we continue to
>> modernize Cabal, I'd like to highlight and show appreciation for all of
>> the help we've gotten from the community, including the developer hours
>> coming from Well-Typed, Haskell Foundation/ Haskell. org (
>> http://foundation/Haskell.org ) , Obsidian Systems, and the Haskell
>> Language Server folks. I'm glad we could work together!
>> 
>> 
>> 
>> For a full set of release notes, see https:/ / github. com/ haskell/ cabal/
>> blob/ master/ release-notes/ Cabal-3. 6. 0. 0. md (
>> https://github.com/haskell/cabal/blob/master/release-notes/Cabal-3.6.0.0.md
>> ). If you have issues, we'd love to hear about there here: https:/ / github.
>> com/ haskell/ cabal/ issues ( https://github.com/haskell/cabal/issues ).
>> 
>> 
>> 
>> Happy hacking!
>> 
>> 
>> 
>> Emily
>> 
>> 
>> 
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users@ haskell. org ( Glasgow-haskell-users at haskell.org )
>> http:/ / mail. haskell. org/ cgi-bin/ mailman/ listinfo/ glasgow-haskell-users
>> ( http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users )
>> 
>> 
> 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20210815/03684111/attachment.html>

From emilypi at cohomolo.gy  Sun Aug 15 02:50:45 2021
From: emilypi at cohomolo.gy (Emily Pillmore)
Date: Sun, 15 Aug 2021 02:50:45 +0000
Subject: [ANN] Cabal-3.6.0.0
In-Reply-To: <kscksxvj.bcaab278-cd39-4951-9bec-b3ecdd32cac3@we.are.superhuman.com>
References: <krzfk5jw.134ee92c-06ec-4363-8ff0-27c0012a409a@we.are.superhuman.com>
 <B382EB2B-7D59-4478-893D-B93F0057101D@gmail.com>
 <kscksxvj.bcaab278-cd39-4951-9bec-b3ecdd32cac3@we.are.superhuman.com>
Message-ID: <kscm1mz8.2f416906-9602-4e59-a2bb-49243dbc92de@we.are.superhuman.com>

There, we've purged the cache and I'm seeing everything up to date :)

On Sat, Aug 14, 2021 at 8:17 PM, Emily Pillmore < emilypi at cohomolo.gy > wrote:

> 
> It already exists on the site, but it looks like the old dirs are cached
> 
> 
> 
> 
> 
> 
> 
> On Sat, Aug 14, 2021 at 7:56 PM, Steven Smith < steve. t. smith@ gmail. com
> ( steve.t.smith at gmail.com ) > wrote:
> 
>> Thank you! Will the release be posted to the haskell downloads site?
>> 
>> 
>> https:/ / downloads. haskell. org/ ~cabal/ (
>> https://downloads.haskell.org/~cabal/ )
>> 
>> 
>> Several package managers (e.g. MacPorts) build using this site.
>> 
>> 
>> 
>>> On Aug 5, 2021, at 5:27 PM, Emily Pillmore < emilypi@ cohomolo. gy (
>>> emilypi at cohomolo.gy ) > wrote:
>>> 
>>> Hello All,
>>> 
>>> 
>>> 
>>> The Cabal team is excited to announce the release of Cabal-3.6.0.0!
>>> 
>>> 
>>> 
>>> 
>>> 
>>> This is the fourth release of the 3.0 release series, and highlights
>>> include support for GHC 9.2, as well as many new code quality improvements
>>> + organization work on the repo itself.
>>> 
>>> 
>>> 
>>> For future plans, we've announced a State of the Cabal post which
>>> describes where we want to take the library and executable over the next
>>> year or two here: https:/ / discourse. haskell. org/ t/ state-of-the-cabal-q1-q2-2021/
>>> 2548 ( https://discourse.haskell.org/t/state-of-the-cabal-q1-q2-2021/2548 )
>>> .
>>> 
>>> 
>>> 
>>> If you'd like to get involved, feel free to contact anyone from the
>>> maintainer team directly, or drop by #hackage on libera. chat (
>>> http://libera.chat/ ) to speak with us. Additionally, as we continue to
>>> modernize Cabal, I'd like to highlight and show appreciation for all of
>>> the help we've gotten from the community, including the developer hours
>>> coming from Well-Typed, Haskell Foundation/ Haskell. org (
>>> http://foundation/Haskell.org ) , Obsidian Systems, and the Haskell
>>> Language Server folks. I'm glad we could work together!
>>> 
>>> 
>>> 
>>> For a full set of release notes, see https:/ / github. com/ haskell/ cabal/
>>> blob/ master/ release-notes/ Cabal-3. 6. 0. 0. md (
>>> https://github.com/haskell/cabal/blob/master/release-notes/Cabal-3.6.0.0.md
>>> ). If you have issues, we'd love to hear about there here: https:/ / github.
>>> com/ haskell/ cabal/ issues ( https://github.com/haskell/cabal/issues ).
>>> 
>>> 
>>> 
>>> Happy hacking!
>>> 
>>> 
>>> 
>>> Emily
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Glasgow-haskell-users mailing list
>>> Glasgow-haskell-users@ haskell. org ( Glasgow-haskell-users at haskell.org )
>>> http:/ / mail. haskell. org/ cgi-bin/ mailman/ listinfo/ glasgow-haskell-users
>>> ( http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users )
>>> 
>>> 
>> 
>> 
> 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20210815/2e468b3e/attachment.html>

From steve.t.smith at gmail.com  Sun Aug 15 12:18:19 2021
From: steve.t.smith at gmail.com (Steven Smith)
Date: Sun, 15 Aug 2021 08:18:19 -0400
Subject: [ANN] Cabal-3.6.0.0
In-Reply-To: <kscm1mz8.2f416906-9602-4e59-a2bb-49243dbc92de@we.are.superhuman.com>
References: <kscm1mz8.2f416906-9602-4e59-a2bb-49243dbc92de@we.are.superhuman.com>
Message-ID: <897BE842-751F-4E74-B03F-46396BD7A7EF@gmail.com>

Sorry, I still do not see 3.6.0.0 on the downloads site. Here’s the tail of what I see at https://downloads.haskell.org/~cabal/

…
> cabal-install-3.2.0.0/                             16-May-2020 07:42                   -
> cabal-install-3.4.0.0/                             23-Feb-2021 23:00                   -
> cabal-install-latest/                              23-Feb-2021 23:00                   -
> old/                                               17-Feb-2019 01:10                   -


> On Aug 14, 2021, at 22:50, Emily Pillmore <emilypi at cohomolo.gy> wrote:
> 
> 
> There, we've purged the cache and I'm seeing everything up to date :)
> 
> 
>> On Sat, Aug 14, 2021 at 8:17 PM, Emily Pillmore <emilypi at cohomolo.gy> wrote:
>> It already exists on the site, but it looks like the old dirs are cached
>> 
>> 
>> 
>> On Sat, Aug 14, 2021 at 7:56 PM, Steven Smith <steve.t.smith at gmail.com> wrote:
>> Thank you! Will the release be posted to the haskell downloads site?
>> 
>> https://downloads.haskell.org/~cabal/
>> 
>> Several package managers (e.g. MacPorts) build using this site.
>> 
>> 
>>> On Aug 5, 2021, at 5:27 PM, Emily Pillmore <emilypi at cohomolo.gy> wrote:
>>> 
>>> Hello All,
>>> 
>>> The Cabal team is excited to announce the release of Cabal-3.6.0.0!
>>> 
>>> 
>>> This is the fourth release of the 3.0 release series, and highlights include support for GHC 9.2, as well as many new code quality improvements + organization work on the repo itself.
>>> 
>>> For future plans, we've announced a State of the Cabal post which describes where we want to take the library and executable over the next year or two here: https://discourse.haskell.org/t/state-of-the-cabal-q1-q2-2021/2548.
>>> 
>>> If you'd like to get involved, feel free to contact anyone from the maintainer team directly, or drop by #hackage on libera.chat to speak with us. Additionally, as we continue to modernize Cabal, I'd like to highlight and show appreciation for all of the help we've gotten from the community, including the developer hours coming from Well-Typed, Haskell Foundation/Haskell.org, Obsidian Systems, and the Haskell Language Server folks. I'm glad we could work together!
>>> 
>>> For a full set of release notes, see https://github.com/haskell/cabal/blob/master/release-notes/Cabal-3.6.0.0.md. If you have issues, we'd love to hear about there here: https://github.com/haskell/cabal/issues.
>>> 
>>> Happy hacking!
>>> 
>>> Emily
>>> 
>>> _______________________________________________
>>> Glasgow-haskell-users mailing list
>>> Glasgow-haskell-users at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20210815/6dbebcc0/attachment.html>

From emilypi at cohomolo.gy  Sun Aug 15 16:40:40 2021
From: emilypi at cohomolo.gy (Emily Pillmore)
Date: Sun, 15 Aug 2021 16:40:40 +0000
Subject: [ANN] Cabal-3.6.0.0
In-Reply-To: <897BE842-751F-4E74-B03F-46396BD7A7EF@gmail.com>
References: <kscm1mz8.2f416906-9602-4e59-a2bb-49243dbc92de@we.are.superhuman.com>
 <897BE842-751F-4E74-B03F-46396BD7A7EF@gmail.com>
Message-ID: <ksdfoy9v.9dc6bbfd-1a10-46ba-973c-5e3b6d6405ce@we.are.superhuman.com>

This may be a local problem with your browser cache. Here's what I see:

> 
> Cabal-3.2.1.0/ ( https://downloads.haskell.org/~cabal/Cabal-3.2.1.0/ )    
> 01-Mar-2021 19:27                   -
> Cabal-3.4.0.0/ ( https://downloads.haskell.org/~cabal/Cabal-3.4.0.0/ )    
> 28-Feb-2021 21:59                   -
> Cabal-3.6.0.0/ ( https://downloads.haskell.org/~cabal/Cabal-3.6.0.0/ )    
> 05-Aug-2021 21:59                   -
> Cabal-latest/ ( https://downloads.haskell.org/~cabal/Cabal-latest/ )      
> 05-Aug-2021 21:59   
> 

On Sun, Aug 15, 2021 at 6:18 AM, Steven Smith < steve.t.smith at gmail.com > wrote:

> 
> Sorry, I still do not see 3.6.0.0 on the downloads site. Here’s the tail
> of what I see at https:/ / downloads. haskell. org/ ~cabal/ (
> https://downloads.haskell.org/~cabal/ )
> 
> 
> …
> 
>> cabal-install-3. 2. 0. 0/ (
>> https://downloads.haskell.org/~cabal/cabal-install-3.2.0.0/ )             
>> 16-May-2020 07:42                   -
>> cabal-install-3. 4. 0. 0/ (
>> https://downloads.haskell.org/~cabal/cabal-install-3.4.0.0/ )             
>> 23-Feb-2021 23:00                   -
>> cabal-install-latest/ (
>> https://downloads.haskell.org/~cabal/cabal-install-latest/ )              
>> 23-Feb-2021 23:00                   -
>> old/ ( https://downloads.haskell.org/~cabal/old/ )                        
>> 17-Feb-2019 01:10                   -
> 
> 
> 
> 
>> On Aug 14, 2021, at 22:50, Emily Pillmore < emilypi@ cohomolo. gy (
>> emilypi at cohomolo.gy ) > wrote:
>> 
>> 
> 
> 
> 
>> 
>> There, we've purged the cache and I'm seeing everything up to date :)
>> 
>> 
>> 
>> On Sat, Aug 14, 2021 at 8:17 PM, Emily Pillmore < emilypi@ cohomolo. gy (
>> emilypi at cohomolo.gy ) > wrote:
>> 
>>> It already exists on the site, but it looks like the old dirs are cached
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On Sat, Aug 14, 2021 at 7:56 PM, Steven Smith < steve. t. smith@ gmail. com
>>> ( steve.t.smith at gmail.com ) > wrote:
>>> 
>>>> Thank you! Will the release be posted to the haskell downloads site?
>>>> 
>>>> 
>>>> https:/ / downloads. haskell. org/ ~cabal/ (
>>>> https://downloads.haskell.org/~cabal/ )
>>>> 
>>>> 
>>>> Several package managers (e.g. MacPorts) build using this site.
>>>> 
>>>> 
>>>> 
>>>>> On Aug 5, 2021, at 5:27 PM, Emily Pillmore < emilypi@ cohomolo. gy (
>>>>> emilypi at cohomolo.gy ) > wrote:
>>>>> 
>>>>> Hello All,
>>>>> 
>>>>> 
>>>>> 
>>>>> The Cabal team is excited to announce the release of Cabal-3.6.0.0!
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> This is the fourth release of the 3.0 release series, and highlights
>>>>> include support for GHC 9.2, as well as many new code quality improvements
>>>>> + organization work on the repo itself.
>>>>> 
>>>>> 
>>>>> 
>>>>> For future plans, we've announced a State of the Cabal post which
>>>>> describes where we want to take the library and executable over the next
>>>>> year or two here: https:/ / discourse. haskell. org/ t/ state-of-the-cabal-q1-q2-2021/
>>>>> 2548 ( https://discourse.haskell.org/t/state-of-the-cabal-q1-q2-2021/2548 )
>>>>> .
>>>>> 
>>>>> 
>>>>> 
>>>>> If you'd like to get involved, feel free to contact anyone from the
>>>>> maintainer team directly, or drop by #hackage on libera. chat (
>>>>> http://libera.chat/ ) to speak with us. Additionally, as we continue to
>>>>> modernize Cabal, I'd like to highlight and show appreciation for all of
>>>>> the help we've gotten from the community, including the developer hours
>>>>> coming from Well-Typed, Haskell Foundation/ Haskell. org (
>>>>> http://foundation/Haskell.org ) , Obsidian Systems, and the Haskell
>>>>> Language Server folks. I'm glad we could work together!
>>>>> 
>>>>> 
>>>>> 
>>>>> For a full set of release notes, see https:/ / github. com/ haskell/ cabal/
>>>>> blob/ master/ release-notes/ Cabal-3. 6. 0. 0. md (
>>>>> https://github.com/haskell/cabal/blob/master/release-notes/Cabal-3.6.0.0.md
>>>>> ). If you have issues, we'd love to hear about there here: https:/ / github.
>>>>> com/ haskell/ cabal/ issues ( https://github.com/haskell/cabal/issues ).
>>>>> 
>>>>> 
>>>>> 
>>>>> Happy hacking!
>>>>> 
>>>>> 
>>>>> 
>>>>> Emily
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Glasgow-haskell-users mailing list
>>>>> Glasgow-haskell-users@ haskell. org ( Glasgow-haskell-users at haskell.org )
>>>>> http:/ / mail. haskell. org/ cgi-bin/ mailman/ listinfo/ glasgow-haskell-users
>>>>> ( http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users )
>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
> 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20210815/c58d3127/attachment.html>

From x at tomsmeding.com  Sun Aug 15 17:05:04 2021
From: x at tomsmeding.com (Tom Smeding)
Date: Sun, 15 Aug 2021 17:05:04 +0000
Subject: [ANN] Cabal-3.6.0.0
In-Reply-To: <ksdfoy9v.9dc6bbfd-1a10-46ba-973c-5e3b6d6405ce@we.are.superhuman.com>
References: <kscm1mz8.2f416906-9602-4e59-a2bb-49243dbc92de@we.are.superhuman.com>
 <897BE842-751F-4E74-B03F-46396BD7A7EF@gmail.com>
 <ksdfoy9v.9dc6bbfd-1a10-46ba-973c-5e3b6d6405ce@we.are.superhuman.com>
Message-ID: <74623d7e-05cf-b700-3287-1630c81b5168@tomsmeding.com>

Cabal-3.6.0.0 is there, but cabal-install-3.6.0.0 is not. :)

- Tom

On 15/08/2021 18:40, Emily Pillmore wrote:
> This may be a local problem with your browser cache. Here's what I see:
>
>     Cabal-3.2.1.0/  <https://downloads.haskell.org/~cabal/Cabal-3.2.1.0/>                                      01-Mar-2021 19:27                   -
>     Cabal-3.4.0.0/  <https://downloads.haskell.org/~cabal/Cabal-3.4.0.0/>                                      28-Feb-2021 21:59                   -
>     Cabal-3.6.0.0/  <https://downloads.haskell.org/~cabal/Cabal-3.6.0.0/>                                      05-Aug-2021 21:59                   -
>     Cabal-latest/  <https://downloads.haskell.org/~cabal/Cabal-latest/>                                       05-Aug-2021 21:59
>
>
>
>
> On Sun, Aug 15, 2021 at 6:18 AM, Steven Smith <steve.t.smith at gmail.com
> <mailto:steve.t.smith at gmail.com>> wrote:
>
>     Sorry, I still do not see 3.6.0.0 on the downloads site. Here’s the
>     tail of what I see at https://downloads.haskell.org/~cabal/
>     <https://downloads.haskell.org/~cabal/>
>
>     …
>>     cabal-install-3.2.0.0/  <https://downloads.haskell.org/~cabal/cabal-install-3.2.0.0/>                              16-May-2020 07:42                   -
>>     cabal-install-3.4.0.0/  <https://downloads.haskell.org/~cabal/cabal-install-3.4.0.0/>                              23-Feb-2021 23:00                   -
>>     cabal-install-latest/  <https://downloads.haskell.org/~cabal/cabal-install-latest/>                               23-Feb-2021 23:00                   -
>>     old/  <https://downloads.haskell.org/~cabal/old/>                                                17-Feb-2019 01:10                   -
>
>>     On Aug 14, 2021, at 22:50, Emily Pillmore <emilypi at cohomolo.gy
>>     <mailto:emilypi at cohomolo.gy>> wrote:
>>
>>     
>>     There, we've purged the cache and I'm seeing everything up to date :)
>>
>>
>>     On Sat, Aug 14, 2021 at 8:17 PM, Emily Pillmore
>>     <emilypi at cohomolo.gy <mailto:emilypi at cohomolo.gy>> wrote:
>>
>>         It already exists on the site, but it looks like the old dirs
>>         are cached
>>
>>
>>
>>         On Sat, Aug 14, 2021 at 7:56 PM, Steven Smith
>>         <steve.t.smith at gmail.com <mailto:steve.t.smith at gmail.com>> wrote:
>>
>>             Thank you! Will the release be posted to the haskell
>>             downloads site?
>>
>>             https://downloads.haskell.org/~cabal/
>>             <https://downloads.haskell.org/~cabal/>
>>
>>             Several package managers (e.g. MacPorts) build using this
>>             site.
>>
>>
>>>             On Aug 5, 2021, at 5:27 PM, Emily Pillmore
>>>             <emilypi at cohomolo.gy <mailto:emilypi at cohomolo.gy>> wrote:
>>>
>>>             Hello All,
>>>
>>>             The Cabal team is excited to announce the release
>>>             of Cabal-3.6.0.0!
>>>
>>>
>>>             This is the fourth release of the 3.0 release series, and
>>>             highlights include support for GHC 9.2, as well as many
>>>             new code quality improvements + organization work on the
>>>             repo itself.
>>>
>>>             For future plans, we've announced a State of the Cabal
>>>             post which describes where we want to take the library
>>>             and executable over the next year or two here:
>>>             https://discourse.haskell.org/t/state-of-the-cabal-q1-q2-2021/2548
>>>             <https://discourse.haskell.org/t/state-of-the-cabal-q1-q2-2021/2548>.
>>>
>>>             If you'd like to get involved, feel free to contact
>>>             anyone from the maintainer team directly, or drop by
>>>             #hackage onlibera.chat <http://libera.chat/>to speak with
>>>             us. Additionally, as we continue to modernize Cabal, I'd
>>>             like to highlight and show appreciation for all of the
>>>             help we've gotten from the community, including the
>>>             developer hours coming from Well-Typed,
>>>             HaskellFoundation/Haskell.org
>>>             <http://foundation/Haskell.org>, Obsidian Systems, and
>>>             the Haskell Language Server folks. I'm glad we could work
>>>             together!
>>>
>>>             For a full set of release notes, see
>>>             https://github.com/haskell/cabal/blob/master/release-notes/Cabal-3.6.0.0.md
>>>             <https://github.com/haskell/cabal/blob/master/release-notes/Cabal-3.6.0.0.md>.
>>>             If you have issues, we'd love to hear about there here:
>>>             https://github.com/haskell/cabal/issues
>>>             <https://github.com/haskell/cabal/issues>.
>>>
>>>             Happy hacking!
>>>
>>>             Emily
>>>
>>>             _______________________________________________
>>>             Glasgow-haskell-users mailing list
>>>             Glasgow-haskell-users at haskell.org
>>>             <mailto:Glasgow-haskell-users at haskell.org>
>>>             http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>>>             <http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users>
>
>


From emilypi at cohomolo.gy  Sun Aug 15 17:23:53 2021
From: emilypi at cohomolo.gy (Emily Pillmore)
Date: Sun, 15 Aug 2021 17:23:53 +0000
Subject: [ANN] Cabal-3.6.0.0
In-Reply-To: <74623d7e-05cf-b700-3287-1630c81b5168@tomsmeding.com>
References: <kscm1mz8.2f416906-9602-4e59-a2bb-49243dbc92de@we.are.superhuman.com>
 <897BE842-751F-4E74-B03F-46396BD7A7EF@gmail.com>
 <ksdfoy9v.9dc6bbfd-1a10-46ba-973c-5e3b6d6405ce@we.are.superhuman.com>
 <74623d7e-05cf-b700-3287-1630c81b5168@tomsmeding.com>
Message-ID: <ksdh7kmu.0fccfa6f-9ec3-4f98-afa5-7d289b2ce2be@we.are.superhuman.com>

Ah - i didn't even notice the confusion: Cabal (the library) and cabal-install (the tool) are not released in lockstep. The cabal-install-3.6.0.0 release is coming next week, and is currently in review.

On Sun, Aug 15, 2021 at 11:05 AM, Tom Smeding < x at tomsmeding.com > wrote:

> 
> 
> 
> Cabal-3.6.0.0 is there, but cabal-install-3.6.0.0 is not. :)
> 
> 
> 
> - Tom
> 
> 
> 
> On 15/08/2021 18:40, Emily Pillmore wrote:
> 
> 
>> 
>> 
>> This may be a local problem with your browser cache. Here's what I see:
>> 
>> 
>> 
>> Cabal-3.2.1.0/ < https:/ / downloads. haskell. org/ ~cabal/ Cabal-3. 2. 1.
>> 0/ ( https://downloads.haskell.org/~cabal/Cabal-3.2.1.0/ ) > 01-Mar-2021
>> 19:27 - Cabal-3.4.0.0/ < https:/ / downloads. haskell. org/ ~cabal/ Cabal-3.
>> 4. 0. 0/ ( https://downloads.haskell.org/~cabal/Cabal-3.4.0.0/ ) >
>> 28-Feb-2021 21:59 - Cabal-3.6.0.0/ < https:/ / downloads. haskell. org/ ~cabal/
>> Cabal-3. 6. 0. 0/ ( https://downloads.haskell.org/~cabal/Cabal-3.6.0.0/ ) >
>> 05-Aug-2021 21:59 - Cabal-latest/ < https:/ / downloads. haskell. org/ ~cabal/
>> Cabal-latest/ ( https://downloads.haskell.org/~cabal/Cabal-latest/ ) >
>> 05-Aug-2021 21:59
>> 
>> 
>> 
>> On Sun, Aug 15 , 2021 at 6:18 AM, Steven Smith < steve. t. smith@ gmail. com
>> ( steve.t.smith at gmail.com )
>> <mailto: steve. t. smith@ gmail. com ( steve.t.smith at gmail.com ) >> wrote:
>> 
>> 
>> 
>> 
>> Sorry, I still do not see 3.6.0.0 on the downloads site. Here’s the tail
>> of what I see at https:/ / downloads. haskell. org/ ~cabal/ (
>> https://downloads.haskell.org/~cabal/ )
>> < https:/ / downloads. haskell. org/ ~cabal/ (
>> https://downloads.haskell.org/~cabal/ ) >
>> 
>> 
>> 
>> …
>> 
>> 
>>> 
>>> 
>>> cabal-install-3.2.0.0/ < https:/ / downloads. haskell. org/ ~cabal/ cabal-install-3.
>>> 2. 0. 0/ ( https://downloads.haskell.org/~cabal/cabal-install-3.2.0.0/ ) >
>>> 16-May-2020 07:42 - cabal-install-3.4.0.0/ < https:/ / downloads. haskell.
>>> org/ ~cabal/ cabal-install-3. 4. 0. 0/ (
>>> https://downloads.haskell.org/~cabal/cabal-install-3.4.0.0/ ) > 23-Feb-2021
>>> 23:00 - cabal-install-latest/ < https:/ / downloads. haskell. org/ ~cabal/
>>> cabal-install-latest/ (
>>> https://downloads.haskell.org/~cabal/cabal-install-latest/ ) > 23-Feb-2021
>>> 23:00 - old/ < https:/ / downloads. haskell. org/ ~cabal/ old/ (
>>> https://downloads.haskell.org/~cabal/old/ ) > 17-Feb-2019 01:10 -
>>> 
>>> 
>>> 
>>> On Aug 14, 2021 , at 22:50, Emily Pillmore < emilypi@ cohomolo. gy (
>>> emilypi at cohomolo.gy )
>>> <mailto: emilypi@ cohomolo. gy ( emilypi at cohomolo.gy ) >> wrote:
>>> 
>>> 
>>> 
>>> There, we've purged the cache and I'm seeing everything up to date :)
>>> 
>>> 
>>> 
>>> On Sat, Aug 14 , 2021 at 8:17 PM, Emily Pillmore
>>> < emilypi@ cohomolo. gy ( emilypi at cohomolo.gy ) <mailto: emilypi@ cohomolo.
>>> gy ( emilypi at cohomolo.gy ) >> wrote:
>>> 
>>> 
>>> 
>>> It already exists on the site, but it looks like the old dirs are cached
>>> 
>>> 
>>> 
>>> On Sat, Aug 14 , 2021 at 7:56 PM, Steven Smith
>>> < steve. t. smith@ gmail. com ( steve.t.smith at gmail.com ) <mailto: steve. t.
>>> smith@ gmail. com ( steve.t.smith at gmail.com ) >> wrote:
>>> 
>>> 
>>> 
>>> Thank you! Will the release be posted to the haskell downloads site?
>>> 
>>> 
>>> 
>>> https:/ / downloads. haskell. org/ ~cabal/ (
>>> https://downloads.haskell.org/~cabal/ )
>>> < https:/ / downloads. haskell. org/ ~cabal/ (
>>> https://downloads.haskell.org/~cabal/ ) >
>>> 
>>> 
>>> 
>>> Several package managers (e.g. MacPorts) build using this site.
>>> 
>>> 
>>>> 
>>>> 
>>>> On Aug 5, 2021 , at 5:27 PM, Emily Pillmore
>>>> < emilypi@ cohomolo. gy ( emilypi at cohomolo.gy ) <mailto: emilypi@ cohomolo.
>>>> gy ( emilypi at cohomolo.gy ) >> wrote:
>>>> 
>>>> 
>>>> 
>>>> Hello All,
>>>> 
>>>> 
>>>> 
>>>> The Cabal team is excited to announce the release
>>>> of Cabal-3.6.0.0!
>>>> 
>>>> 
>>>> 
>>>> This is the fourth release of the 3.0 release series, and highlights
>>>> include support for GHC 9.2, as well as many new code quality improvements
>>>> + organization work on the repo itself.
>>>> 
>>>> 
>>>> 
>>>> For future plans, we've announced a State of the Cabal post which
>>>> describes where we want to take the library and executable over the next
>>>> year or two here:
>>>> https:/ / discourse. haskell. org/ t/ state-of-the-cabal-q1-q2-2021/ 2548 (
>>>> https://discourse.haskell.org/t/state-of-the-cabal-q1-q2-2021/2548 )
>>>> < https:/ / discourse. haskell. org/ t/ state-of-the-cabal-q1-q2-2021/ 2548
>>>> ( https://discourse.haskell.org/t/state-of-the-cabal-q1-q2-2021/2548 ) >.
>>>> 
>>>> 
>>>> 
>>>> If you'd like to get involved, feel free to contact anyone from the
>>>> maintainer team directly, or drop by
>>>> #hackage onlibera. chat ( http://onlibera.chat/ ) < http:/ / libera. chat/
>>>> ( http://libera.chat/ ) >to speak with us. Additionally, as we continue to
>>>> modernize Cabal, I'd like to highlight and show appreciation for all of
>>>> the help we've gotten from the community, including the developer hours
>>>> coming from Well-Typed,
>>>> HaskellFoundation/ Haskell. org ( http://haskellfoundation/Haskell.org )
>>>> < http:/ / foundation/ Haskell. org ( http://foundation/Haskell.org ) >,
>>>> Obsidian Systems, and the Haskell Language Server folks. I'm glad we could
>>>> work together!
>>>> 
>>>> 
>>>> 
>>>> For a full set of release notes, see
>>>> https:/ / github. com/ haskell/ cabal/ blob/ master/ release-notes/ Cabal-3.
>>>> 6. 0. 0. md (
>>>> https://github.com/haskell/cabal/blob/master/release-notes/Cabal-3.6.0.0.md
>>>> )
>>>> < https:/ / github. com/ haskell/ cabal/ blob/ master/ release-notes/ Cabal-3.
>>>> 6. 0. 0. md (
>>>> https://github.com/haskell/cabal/blob/master/release-notes/Cabal-3.6.0.0.md
>>>> ) >. If you have issues, we'd love to hear about there here: https:/ / github.
>>>> com/ haskell/ cabal/ issues ( https://github.com/haskell/cabal/issues )
>>>> < https:/ / github. com/ haskell/ cabal/ issues (
>>>> https://github.com/haskell/cabal/issues ) >.
>>>> 
>>>> 
>>>> 
>>>> Happy hacking!
>>>> 
>>>> 
>>>> 
>>>> Emily
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Glasgow-haskell-users mailing list
>>>> Glasgow-haskell-users@ haskell. org ( Glasgow-haskell-users at haskell.org )
>>>> <mailto: Glasgow-haskell-users@ haskell. org (
>>>> Glasgow-haskell-users at haskell.org ) >
>>>> http:/ / mail. haskell. org/ cgi-bin/ mailman/ listinfo/ glasgow-haskell-users
>>>> ( http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users )
>>>> 
>>>> < http:/ / mail. haskell. org/ cgi-bin/ mailman/ listinfo/ glasgow-haskell-users
>>>> ( http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users )
>>>> >
>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
> 
> 
> 
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@ haskell. org ( Glasgow-haskell-users at haskell.org )
> http:/ / mail. haskell. org/ cgi-bin/ mailman/ listinfo/ glasgow-haskell-users
> ( http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users )
> 
> 
> 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20210815/1014891c/attachment.html>

From sperber at deinprogramm.de  Mon Aug 16 12:17:45 2021
From: sperber at deinprogramm.de (Michael Sperber)
Date: Mon, 16 Aug 2021 14:17:45 +0200
Subject: Avoiding construction of dead dictionaries
In-Reply-To: <VI1PR83MB02693B1B98C36686746CB446ADF99@VI1PR83MB0269.EURPRD83.prod.outlook.com>
 (Simon Peyton Jones's message of "Thu, 12 Aug 2021 12:01:04 +0000")
References: <y9lo8aag1tk.fsf@valmont.fritz.box>
 <VI1PR83MB02690B4E25F99252893586CEADF69@VI1PR83MB0269.EURPRD83.prod.outlook.com>
 <y9lsfzf10tj.fsf@valmont.home.active-group.de>
 <VI1PR83MB02693B1B98C36686746CB446ADF99@VI1PR83MB0269.EURPRD83.prod.outlook.com>
Message-ID: <y9leeatd1na.fsf@valmont.fritz.box>


On Thu, Aug 12 2021, Simon Peyton Jones <simonpj at microsoft.com> wrote:

> Repro case is something like
> * Here is a source or files
> * Compile like this
> * Look at the generated Core...observe silly thing happening

Tried my best here:

https://gitlab.haskell.org/ghc/ghc/-/issues/20237

Any help on this would be much appreciated!

-- 
Regards,
Mike

From sperber at deinprogramm.de  Wed Aug 18 13:14:09 2021
From: sperber at deinprogramm.de (Michael Sperber)
Date: Wed, 18 Aug 2021 15:14:09 +0200
Subject: -dinline-check for symbolic names?
In-Reply-To: <VI1PR83MB0269D9905F3E52ECCE8C4DB4ADF79@VI1PR83MB0269.EURPRD83.prod.outlook.com>
 (Simon Peyton Jones's message of "Tue, 10 Aug 2021 09:15:53 +0000")
References: <y9lmtpxi66h.fsf@valmont.fritz.box>
 <CAHYVw0zrkVaFF2yFs_pX9Tdvtzs+C3JFW5Ev_DPd8vYWeY=EcA@mail.gmail.com>
 <y9lwnoyg3i9.fsf@valmont.fritz.box>
 <y9lsfzmg2v4.fsf@valmont.fritz.box>
 <VI1PR83MB0269D9905F3E52ECCE8C4DB4ADF79@VI1PR83MB0269.EURPRD83.prod.outlook.com>
Message-ID: <y9leeaq99pa.fsf@valmont.fritz.box>


On Tue, Aug 10 2021, Simon Peyton Jones <simonpj at microsoft.com> wrote:

> It's hard to tell what is happening without a repro case. Can you share one?

Haven't been able to do that with <10MB of output, I'm afraid ...

> You suggested that it might have something to do with using an
> operator.  Does the same thing happen if you replace the operator with
> an alpha-numeric name?

I've now concluded several things are coming together.  As things
started working with INLINE [0] instead of INLINE, it's not the symbolic
name.

First, reading the ghc source code suggests I can only have one
-ddinline-check. Correct?

Also, I'm guessing that the inlining I didn't see reported by
-dinline-check happened inside the simplifier pass inserted by the
ConCat plugin.  (And hence INLINE [0] moved it out of that pass.)  Is it
possible that the flag isn't getting propagated there?

(Sorry for being vague - if you don't know offhand, it's not worth
digging without more info from me.)

-- 
Regards,
Mike

From simonpj at microsoft.com  Thu Aug 19 11:17:23 2021
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 19 Aug 2021 11:17:23 +0000
Subject: -dinline-check for symbolic names?
In-Reply-To: <y9leeaq99pa.fsf@valmont.fritz.box>
References: <y9lmtpxi66h.fsf@valmont.fritz.box>
 <CAHYVw0zrkVaFF2yFs_pX9Tdvtzs+C3JFW5Ev_DPd8vYWeY=EcA@mail.gmail.com>
 <y9lwnoyg3i9.fsf@valmont.fritz.box>	<y9lsfzmg2v4.fsf@valmont.fritz.box>
 <VI1PR83MB0269D9905F3E52ECCE8C4DB4ADF79@VI1PR83MB0269.EURPRD83.prod.outlook.com>
 <y9leeaq99pa.fsf@valmont.fritz.box>
Message-ID: <VI1PR83MB026933DCA5924AEAE623668EADC09@VI1PR83MB0269.EURPRD83.prod.outlook.com>

|  First, reading the ghc source code suggests I can only have one -ddinline-
|  check. Correct?

Yes. The last one wins.  This should be in the user manual.  Would anyone like to offer a PR?

|  Also, I'm guessing that the inlining I didn't see reported by -dinline-check
|  happened inside the simplifier pass inserted by the ConCat plugin.  (And
|  hence INLINE [0] moved it out of that pass.)  Is it possible that the flag
|  isn't getting propagated there?

I don't see how that could happen, but I only have a vague idea of what is going on.

Simon

|  -----Original Message-----
|  From: Michael Sperber <sperber at deinprogramm.de>
|  Sent: 18 August 2021 14:14
|  To: Simon Peyton Jones <simonpj at microsoft.com>
|  Cc: glasgow-haskell-users at haskell.org
|  Subject: Re: -dinline-check for symbolic names?
|  
|  
|  On Tue, Aug 10 2021, Simon Peyton Jones <simonpj at microsoft.com> wrote:
|  
|  > It's hard to tell what is happening without a repro case. Can you share
|  one?
|  
|  Haven't been able to do that with <10MB of output, I'm afraid ...
|  
|  > You suggested that it might have something to do with using an
|  > operator.  Does the same thing happen if you replace the operator with
|  > an alpha-numeric name?
|  
|  I've now concluded several things are coming together.  As things started
|  working with INLINE [0] instead of INLINE, it's not the symbolic name.
|  
|  First, reading the ghc source code suggests I can only have one -ddinline-
|  check. Correct?
|  
|  Also, I'm guessing that the inlining I didn't see reported by -dinline-check
|  happened inside the simplifier pass inserted by the ConCat plugin.  (And
|  hence INLINE [0] moved it out of that pass.)  Is it possible that the flag
|  isn't getting propagated there?
|  
|  (Sorry for being vague - if you don't know offhand, it's not worth digging
|  without more info from me.)
|  
|  --
|  Regards,
|  Mike

From zubin at well-typed.com  Sat Aug 21 09:50:24 2021
From: zubin at well-typed.com (Zubin Duggal)
Date: Sat, 21 Aug 2021 15:20:24 +0530
Subject: The State of GHC 8.10
Message-ID: <20210821095024.aobr5jrtedls4om6@zubin-msi>

Hi all,

GHC 8.10.6 was released last week, with high hopes of finally putting an
end to the long running saga of the GHC 8.10 series. Unfortunately, this
was not to be the case as we soon discovered #19950, an issue that we
claimed to have fixed in the 8.10.6 release, was still affecting the
released compiler.

#19950 is caused by a bug in newer Apple toolchains (specifically XCode
12) where programs compiled with affected versions of XCode are not
backwards compatible with configurations running older version of XCode
(certain versions of XCode 11). It surfaced in GHC 8.10.5 since we
upgraded the toolchain on our Darwin builders to one of the affected
versions.

The original fix/workaround for #19950 was tested on the master and
GHC-9.2 branches and found to be working, and so backported to the 8.10
branch. Unfortunately, Darwin releases for 8.10 are still done using
the Make build system, which did not pick up the extra linker options
needed to work around the issue. 

It places a heavy burden on developers to have so many active branches
of the compiler to keep in mind, and the current situation with 4 active
branches is simply not sustainable. As the oldest currently active
branch, it is currently a priority to retire the 8.10 branch of GHC from
active development as soon as possible.

We have now fixed and verified the fix for #19950 on the 8.10 branch
and prepared a GHC 8.10.7 release including it. As of now, the only
change in GHC 8.10.7 is to link the x86_64 darwin release build with a
few extra linker options to work around #19950.

If you have any other critical issues that prevent you from using GHC
8.10(.6), please raise them soon by either pointing to existing tickets
on the tracker or creating a new one. We are planning to cut the new
release as soon as early next week, and we are really hoping that this
would be the final release in the 8.10 series.

Cheers,
Zubin.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20210821/76e5a8d7/attachment.sig>

From ben at well-typed.com  Sun Aug 22 21:56:37 2021
From: ben at well-typed.com (Ben Gamari)
Date: Sun, 22 Aug 2021 17:56:37 -0400
Subject: [ANNOUNCE] GHC 9.2.1-rc1 now available
Message-ID: <87wnodm9dq.fsf@smart-cactus.org>


Hi all,

The GHC developers are very happy to announce the availability of the
release cadidate of the 9.2.1 release. Binary distributions, source
distributions, and documentation are available at

     https://downloads.haskell.org/ghc/9.2.1-rc1

GHC 9.2 will bring a number of exciting features including:

 * A native code generation backend for AArch64, significantly speeding
   compilation time on ARM platforms like the Apple M1.

 * Many changes in the area of records, including the new
   `RecordDotSyntax` and `NoFieldSelectors` language extensions, as well
   as Support for `DuplicateRecordFields` with `PatternSynonyms`.

 * Introduction of the new `GHC2021` language extension set, giving
   users convenient access to a larger set of language extensions which
   have been long considered stable.

 * Merge of `ghc-exactprint` into the GHC tree, providing infrastructure
   for source-to-source program rewriting out-of-the-box.

 * Introduction of a `BoxedRep` `RuntimeRep`, allowing for polymorphism
   over levity of boxed objects (#17526)

 * Implementation of the `UnliftedDataTypes` extension, allowing users
   to define types which do not admit lazy evaluation ([proposal])

 * The new [-hi profiling] mechanism which provides significantly
   improved insight into thunk leaks.

 * Support for the `ghc-debug` out-of-process heap inspection library
   [ghc-debug]

 * Support for profiling of pinned objects with the cost-centre profiler
   (#7275)

 * Introduction of Haddock documentation support in TemplateHaskell (#5467)

Finally, thank you to Microsoft Research, GitHub, IOHK, the Zw3rk stake
pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous
contributors whose on-going financial and in-kind support has
facilitated GHC maintenance and release management over the years.
Moreover, 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 testing,

- Ben


[apple-m1]: https://www.haskell.org/ghc/blog/20210309-apple-m1-story.html
[proposal]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0265-unlifted-datatypes.rst
[-hi profiling]: https://well-typed.com/blog/2021/01/first-look-at-hi-profiling-mode/
[ghc-debug]: http://ghc.gitlab.haskell.org/ghc-debug/
[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/glasgow-haskell-users/attachments/20210822/58af141e/attachment.sig>

From david.feuer at gmail.com  Sun Aug 22 22:10:20 2021
From: david.feuer at gmail.com (David Feuer)
Date: Sun, 22 Aug 2021 18:10:20 -0400
Subject: [ANNOUNCE] GHC 9.2.1-rc1 now available
In-Reply-To: <87wnodm9dq.fsf@smart-cactus.org>
References: <87wnodm9dq.fsf@smart-cactus.org>
Message-ID: <CAMgWh9sF4Ann5MO+mwahDbWW44yaddLrE_FVf0iV6_fBH0ioQw@mail.gmail.com>

Have array and reference types and primos been updated to be
BoxedRep-polymorphic, or is it still just expensive scaffolding?

On Sun, Aug 22, 2021, 6:01 PM Ben Gamari <ben at well-typed.com> wrote:

>
> Hi all,
>
> The GHC developers are very happy to announce the availability of the
> release cadidate of the 9.2.1 release. Binary distributions, source
> distributions, and documentation are available at
>
>      https://downloads.haskell.org/ghc/9.2.1-rc1
>
> GHC 9.2 will bring a number of exciting features including:
>
>  * A native code generation backend for AArch64, significantly speeding
>    compilation time on ARM platforms like the Apple M1.
>
>  * Many changes in the area of records, including the new
>    `RecordDotSyntax` and `NoFieldSelectors` language extensions, as well
>    as Support for `DuplicateRecordFields` with `PatternSynonyms`.
>
>  * Introduction of the new `GHC2021` language extension set, giving
>    users convenient access to a larger set of language extensions which
>    have been long considered stable.
>
>  * Merge of `ghc-exactprint` into the GHC tree, providing infrastructure
>    for source-to-source program rewriting out-of-the-box.
>
>  * Introduction of a `BoxedRep` `RuntimeRep`, allowing for polymorphism
>    over levity of boxed objects (#17526)
>
>  * Implementation of the `UnliftedDataTypes` extension, allowing users
>    to define types which do not admit lazy evaluation ([proposal])
>
>  * The new [-hi profiling] mechanism which provides significantly
>    improved insight into thunk leaks.
>
>  * Support for the `ghc-debug` out-of-process heap inspection library
>    [ghc-debug]
>
>  * Support for profiling of pinned objects with the cost-centre profiler
>    (#7275)
>
>  * Introduction of Haddock documentation support in TemplateHaskell (#5467)
>
> Finally, thank you to Microsoft Research, GitHub, IOHK, the Zw3rk stake
> pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous
> contributors whose on-going financial and in-kind support has
> facilitated GHC maintenance and release management over the years.
> Moreover, 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 testing,
>
> - Ben
>
>
> [apple-m1]: https://www.haskell.org/ghc/blog/20210309-apple-m1-story.html
> [proposal]:
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0265-unlifted-datatypes.rst
> [-hi
> <https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0265-unlifted-datatypes.rst%5B-hi>
> profiling]:
> https://well-typed.com/blog/2021/01/first-look-at-hi-profiling-mode/
> [ghc-debug
> <https://well-typed.com/blog/2021/01/first-look-at-hi-profiling-mode/%5Bghc-debug>]:
> http://ghc.gitlab.haskell.org/ghc-debug/
> [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20210822/aa709a25/attachment.html>

From david.feuer at gmail.com  Mon Aug 23 00:14:01 2021
From: david.feuer at gmail.com (David Feuer)
Date: Sun, 22 Aug 2021 20:14:01 -0400
Subject: [ANNOUNCE] GHC 9.2.1-rc1 now available
In-Reply-To: <87wnodm9dq.fsf@smart-cactus.org>
References: <87wnodm9dq.fsf@smart-cactus.org>
Message-ID: <CAMgWh9utBYWXRmavvT2VXbM-F49Q6tLkHFZCbT+-4hV8wAM73A@mail.gmail.com>

One more question: is Solo exported from Data.Tuple yet, or do we still
have to depend on ghc-prim and import it from GHC.Magic? It would be really
nice to have that fixed by release, and it's so tiny.

On Sun, Aug 22, 2021, 6:01 PM Ben Gamari <ben at well-typed.com> wrote:

>
> Hi all,
>
> The GHC developers are very happy to announce the availability of the
> release cadidate of the 9.2.1 release. Binary distributions, source
> distributions, and documentation are available at
>
>      https://downloads.haskell.org/ghc/9.2.1-rc1
>
> GHC 9.2 will bring a number of exciting features including:
>
>  * A native code generation backend for AArch64, significantly speeding
>    compilation time on ARM platforms like the Apple M1.
>
>  * Many changes in the area of records, including the new
>    `RecordDotSyntax` and `NoFieldSelectors` language extensions, as well
>    as Support for `DuplicateRecordFields` with `PatternSynonyms`.
>
>  * Introduction of the new `GHC2021` language extension set, giving
>    users convenient access to a larger set of language extensions which
>    have been long considered stable.
>
>  * Merge of `ghc-exactprint` into the GHC tree, providing infrastructure
>    for source-to-source program rewriting out-of-the-box.
>
>  * Introduction of a `BoxedRep` `RuntimeRep`, allowing for polymorphism
>    over levity of boxed objects (#17526)
>
>  * Implementation of the `UnliftedDataTypes` extension, allowing users
>    to define types which do not admit lazy evaluation ([proposal])
>
>  * The new [-hi profiling] mechanism which provides significantly
>    improved insight into thunk leaks.
>
>  * Support for the `ghc-debug` out-of-process heap inspection library
>    [ghc-debug]
>
>  * Support for profiling of pinned objects with the cost-centre profiler
>    (#7275)
>
>  * Introduction of Haddock documentation support in TemplateHaskell (#5467)
>
> Finally, thank you to Microsoft Research, GitHub, IOHK, the Zw3rk stake
> pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous
> contributors whose on-going financial and in-kind support has
> facilitated GHC maintenance and release management over the years.
> Moreover, 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 testing,
>
> - Ben
>
>
> [apple-m1]: https://www.haskell.org/ghc/blog/20210309-apple-m1-story.html
> [proposal]:
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0265-unlifted-datatypes.rst
> [-hi
> <https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0265-unlifted-datatypes.rst%5B-hi>
> profiling]:
> https://well-typed.com/blog/2021/01/first-look-at-hi-profiling-mode/
> [ghc-debug
> <https://well-typed.com/blog/2021/01/first-look-at-hi-profiling-mode/%5Bghc-debug>]:
> http://ghc.gitlab.haskell.org/ghc-debug/
> [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20210822/85def702/attachment.html>

From david.feuer at gmail.com  Mon Aug 23 00:15:10 2021
From: david.feuer at gmail.com (David Feuer)
Date: Sun, 22 Aug 2021 20:15:10 -0400
Subject: [ANNOUNCE] GHC 9.2.1-rc1 now available
In-Reply-To: <CAMgWh9utBYWXRmavvT2VXbM-F49Q6tLkHFZCbT+-4hV8wAM73A@mail.gmail.com>
References: <87wnodm9dq.fsf@smart-cactus.org>
 <CAMgWh9utBYWXRmavvT2VXbM-F49Q6tLkHFZCbT+-4hV8wAM73A@mail.gmail.com>
Message-ID: <CAMgWh9s4UDEh5-0=G5ha8jbegsGk7kix7gkNjUHObPWo9xcaCA@mail.gmail.com>

I mean GHC.Tuple, of course.

On Sun, Aug 22, 2021, 8:14 PM David Feuer <david.feuer at gmail.com> wrote:

> One more question: is Solo exported from Data.Tuple yet, or do we still
> have to depend on ghc-prim and import it from GHC.Magic? It would be really
> nice to have that fixed by release, and it's so tiny.
>
> On Sun, Aug 22, 2021, 6:01 PM Ben Gamari <ben at well-typed.com> wrote:
>
>>
>> Hi all,
>>
>> The GHC developers are very happy to announce the availability of the
>> release cadidate of the 9.2.1 release. Binary distributions, source
>> distributions, and documentation are available at
>>
>>      https://downloads.haskell.org/ghc/9.2.1-rc1
>>
>> GHC 9.2 will bring a number of exciting features including:
>>
>>  * A native code generation backend for AArch64, significantly speeding
>>    compilation time on ARM platforms like the Apple M1.
>>
>>  * Many changes in the area of records, including the new
>>    `RecordDotSyntax` and `NoFieldSelectors` language extensions, as well
>>    as Support for `DuplicateRecordFields` with `PatternSynonyms`.
>>
>>  * Introduction of the new `GHC2021` language extension set, giving
>>    users convenient access to a larger set of language extensions which
>>    have been long considered stable.
>>
>>  * Merge of `ghc-exactprint` into the GHC tree, providing infrastructure
>>    for source-to-source program rewriting out-of-the-box.
>>
>>  * Introduction of a `BoxedRep` `RuntimeRep`, allowing for polymorphism
>>    over levity of boxed objects (#17526)
>>
>>  * Implementation of the `UnliftedDataTypes` extension, allowing users
>>    to define types which do not admit lazy evaluation ([proposal])
>>
>>  * The new [-hi profiling] mechanism which provides significantly
>>    improved insight into thunk leaks.
>>
>>  * Support for the `ghc-debug` out-of-process heap inspection library
>>    [ghc-debug]
>>
>>  * Support for profiling of pinned objects with the cost-centre profiler
>>    (#7275)
>>
>>  * Introduction of Haddock documentation support in TemplateHaskell
>> (#5467)
>>
>> Finally, thank you to Microsoft Research, GitHub, IOHK, the Zw3rk stake
>> pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous
>> contributors whose on-going financial and in-kind support has
>> facilitated GHC maintenance and release management over the years.
>> Moreover, 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 testing,
>>
>> - Ben
>>
>>
>> [apple-m1]: https://www.haskell.org/ghc/blog/20210309-apple-m1-story.html
>> [proposal]:
>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0265-unlifted-datatypes.rst
>> [-hi
>> <https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0265-unlifted-datatypes.rst%5B-hi>
>> profiling]:
>> https://well-typed.com/blog/2021/01/first-look-at-hi-profiling-mode/
>> [ghc-debug
>> <https://well-typed.com/blog/2021/01/first-look-at-hi-profiling-mode/%5Bghc-debug>]:
>> http://ghc.gitlab.haskell.org/ghc-debug/
>> [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new
>>
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20210822/201b8f76/attachment.html>

From zubin at well-typed.com  Thu Aug 26 22:13:15 2021
From: zubin at well-typed.com (Zubin Duggal)
Date: Fri, 27 Aug 2021 03:43:15 +0530
Subject: [Haskell] [ANNOUNCE] GHC 8.10.7 released
Message-ID: <20210826221315.tumzvm3q2p24qa4x@zubin-msi>

The GHC team is very pleased to announce the availability of GHC
8.10.7. Source and binary distributions are available at the [usual
place](https://downloads.haskell.org/ghc/8.10.7/).

Download Page: https://www.haskell.org/ghc/download_ghc_8_10_7.html
Blog Post: https://www.haskell.org/ghc/blog/20210827-ghc-8.10.7-released.html

This is a small bugfix release, fixing one linking portability
issue (#19950) present in GHC 8.10.5 and GHC 8.10.6 on some x86_64
macOS toolchains, which resulted in undefined symbol errors for
`___darwin_check_fd_set_overflow`.

Issue #19950 is caused by a bug in newer Apple toolchains (specifically
XCode 12) where programs compiled with affected versions of XCode are
not backwards compatible with configurations running older version of
XCode (certain versions of XCode 11).

We claimed to have fixed this in GHC 8.10.6, but alas this wasn't the
case. The fix was originally tested on the master branch, which uses a
different build configuration from the 8.10 branch. We have now tested
the fix on the GHC 8.10 branch and finally squashed the bug.

We would like to thank Microsoft Research, GitHub, IOHK, the Zw3rk
stake pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous
contributors whose on-going financial and in-kind support has
facilitated GHC maintenance and release management over the years. We
would also like to thank the hundreds of open-source contributors whose
work makes GHC possible.

A complete list of bug fixes and
improvements can be found in the [release
notes](https://downloads.haskell.org/ghc/8.10.7/docs/html/users_guide/8.
10.7-notes.html).

As always, feel free to report any issues you encounter via
[gitlab.haskell.org](https://gitlab.haskell.org/ghc/ghc/-/issues/new).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20210827/86531f16/attachment.sig>