From g9ks157k at acme.softbase.org  Thu May  4 17:20:53 2017
From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch)
Date: Thu, 04 May 2017 20:20:53 +0300
Subject: Untouchable type variables
Message-ID: <1493918453.8081.30.camel@acme.softbase.org>

Hi!

Today I encountered for the first time the notion of an “untouchable”
type variable. I have no clue what this is supposed to mean. A minimal
example that exposes my problem is the following:

> {-# LANGUAGE Rank2Types, TypeFamilies #-}
> 
> import GHC.Exts (Constraint)
> 
> type family F a b :: Constraint
> 
> data T b c = T
> 
> f :: (forall b . F a b => T b c) -> a
> f _ = undefined

This results in the following error message from GHC 8.0.1:

> Untouchable.hs:9:6: error:
>     • Couldn't match type ‘c0’ with ‘c’
>         ‘c0’ is untouchable
>           inside the constraints: F a b
>           bound by the type signature for:
>                      f :: F a b => T b c0
>           at Untouchable.hs:9:6-37
>       ‘c’ is a rigid type variable bound by
>         the type signature for:
>           f :: forall a c. (forall b. F a b => T b c) -> a
>         at Untouchable.hs:9:6
>       Expected type: T b c0
>         Actual type: T b c
>     • In the ambiguity check for ‘f’
>       To defer the ambiguity check to use sites, enable AllowAmbiguousTypes
>       In the type signature:
>         f :: (forall b. F a b => T b c) -> a

I have no idea what the problem is. The type of f looks fine to me. The
type variable c should be universally quantified at the outermost level.
Why does the type checker even introduce a type variable c0?

All the best,
Wolfgang

From g9ks157k at acme.softbase.org  Thu May  4 22:42:08 2017
From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch)
Date: Fri, 05 May 2017 01:42:08 +0300
Subject: ConstraintKinds seems to be automatically enabled
Message-ID: <1493937728.12756.79.camel@acme.softbase.org>

Hi!

In my previous e-mail, I showed some code that uses the Constraint kind.
I forgot to enable the ConstraintKinds extension though, but GHC 8.0.1
did not complain. Is this a bug?

All the best,
Wolfgang

From allbery.b at gmail.com  Thu May  4 22:46:42 2017
From: allbery.b at gmail.com (Brandon Allbery)
Date: Thu, 4 May 2017 18:46:42 -0400
Subject: ConstraintKinds seems to be automatically enabled
In-Reply-To: <1493937728.12756.79.camel@acme.softbase.org>
References: <1493937728.12756.79.camel@acme.softbase.org>
Message-ID: <CAKFCL4X0d4c+SH++oQNjoedV-L4_FGSbtodaFRSradrGrFzmLQ@mail.gmail.com>

On Thu, May 4, 2017 at 6:42 PM, Wolfgang Jeltsch <g9ks157k at acme.softbase.org
> wrote:

> In my previous e-mail, I showed some code that uses the Constraint kind.
> I forgot to enable the ConstraintKinds extension though, but GHC 8.0.1
> did not complain. Is this a bug?
>

I think it's a known side effect of * being conflated with Constraint, a
problem that is actively being worked on (
https://ghc.haskell.org/trac/ghc/ticket/11715 ).

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20170504/d0834353/attachment.html>

From carter.schonwald at gmail.com  Fri May  5 14:14:19 2017
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Fri, 5 May 2017 10:14:19 -0400
Subject: ConstraintKinds seems to be automatically enabled
In-Reply-To: <CAKFCL4X0d4c+SH++oQNjoedV-L4_FGSbtodaFRSradrGrFzmLQ@mail.gmail.com>
References: <1493937728.12756.79.camel@acme.softbase.org>
 <CAKFCL4X0d4c+SH++oQNjoedV-L4_FGSbtodaFRSradrGrFzmLQ@mail.gmail.com>
Message-ID: <CAHYVw0xSEanMXeO9LCXC8_mxYSDv8=i_KDMvtSjS1xxOHvh3iQ@mail.gmail.com>

in newer versions of ghc, client code of a module that uses constraint
kinds gets constraint kinds enabled.

this is to make it pleasant to use constraint kinds in libraries.

this is deliberate feature :)

On Thu, May 4, 2017 at 6:46 PM, Brandon Allbery <allbery.b at gmail.com> wrote:

> On Thu, May 4, 2017 at 6:42 PM, Wolfgang Jeltsch <
> g9ks157k at acme.softbase.org> wrote:
>
>> In my previous e-mail, I showed some code that uses the Constraint kind.
>> I forgot to enable the ConstraintKinds extension though, but GHC 8.0.1
>> did not complain. Is this a bug?
>>
>
> I think it's a known side effect of * being conflated with Constraint, a
> problem that is actively being worked on ( https://ghc.haskell.org/trac/
> ghc/ticket/11715 ).
>
> --
> brandon s allbery kf8nh                               sine nomine
> associates
> allbery.b at gmail.com
> ballbery at sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
> _______________________________________________
> 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/20170505/265bf5e1/attachment.html>

From carter.schonwald at gmail.com  Fri May  5 14:20:15 2017
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Fri, 5 May 2017 10:20:15 -0400
Subject: ConstraintKinds seems to be automatically enabled
In-Reply-To: <CAHYVw0xSEanMXeO9LCXC8_mxYSDv8=i_KDMvtSjS1xxOHvh3iQ@mail.gmail.com>
References: <1493937728.12756.79.camel@acme.softbase.org>
 <CAKFCL4X0d4c+SH++oQNjoedV-L4_FGSbtodaFRSradrGrFzmLQ@mail.gmail.com>
 <CAHYVw0xSEanMXeO9LCXC8_mxYSDv8=i_KDMvtSjS1xxOHvh3iQ@mail.gmail.com>
Message-ID: <CAHYVw0x6P8SixXcWE_Njh2-iYTQ4ErEVed_YnqB-v64jjvTjkA@mail.gmail.com>

woops, i mispoke, its probably that bug brandon spoke of or somesuch,
didn't look closely enough at the previous email :)

On Fri, May 5, 2017 at 10:14 AM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> in newer versions of ghc, client code of a module that uses constraint
> kinds gets constraint kinds enabled.
>
> this is to make it pleasant to use constraint kinds in libraries.
>
> this is deliberate feature :)
>
> On Thu, May 4, 2017 at 6:46 PM, Brandon Allbery <allbery.b at gmail.com>
> wrote:
>
>> On Thu, May 4, 2017 at 6:42 PM, Wolfgang Jeltsch <
>> g9ks157k at acme.softbase.org> wrote:
>>
>>> In my previous e-mail, I showed some code that uses the Constraint kind.
>>> I forgot to enable the ConstraintKinds extension though, but GHC 8.0.1
>>> did not complain. Is this a bug?
>>>
>>
>> I think it's a known side effect of * being conflated with Constraint, a
>> problem that is actively being worked on ( https://ghc.haskell.org/trac/g
>> hc/ticket/11715 ).
>>
>> --
>> brandon s allbery kf8nh                               sine nomine
>> associates
>> allbery.b at gmail.com
>> ballbery at sinenomine.net
>> unix, openafs, kerberos, infrastructure, xmonad
>> http://sinenomine.net
>>
>> _______________________________________________
>> 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/20170505/137dc894/attachment.html>

From anthony_clayden at clear.net.nz  Sun May  7 02:11:14 2017
From: anthony_clayden at clear.net.nz (Anthony Clayden)
Date: Sun, 07 May 2017 14:11:14 +1200
Subject: Superclass Equality constraints cp FunDeps
Message-ID: <590e8242.152.4f4a.22505@clear.net.nz>

> On Sun Apr 30 19:35:17 UTC 2017 Brandon Allbery wrote:

>> On Sun, Apr 30, 2017 at 3:31 PM, Richard Eisenberg wrote:
>>>
>>> On Apr 30, 2017, at 6:37 AM, Anthony Clayden wrote:
>>> Is that behaviour officially documented somewhere?
>>
>> Not that I can find. ...
> 
> ... the originally cited behavior of
> equality constraints could also stand to be documented.
..

Thanks Brandon, I've added a request to #10431 [q.v.].

Actually, the required flags are documented,
just in an obscure place.
Anyway it's not too bad:
GHC's error message tells you what to do.


AntC

From anthony_clayden at clear.net.nz  Sun May  7 02:19:43 2017
From: anthony_clayden at clear.net.nz (Anthony Clayden)
Date: Sun, 07 May 2017 14:19:43 +1200
Subject: Superclass Equality constraints cp FunDeps
Message-ID: <590e843f.2a8.5c77.7987@clear.net.nz>

> On Sun Apr 30 19:45:34 UTC 2017, Richard Eisenberg wrote:

> Documentation is just about always suboptimal -- but the
> best people to suggest concrete improvements are those who
> were confused to begin with. So, by all means, submit
> patches!

Thanks for the invite ;-).

OK. Done. See #13657.

I've put suggested wording, please improve!

The trickier problem is where to put the wording;
the 'feature' is really at the intersection of
several extensions.

> 
> Some relevant discussion on this point is on
> https://ghc.haskell.org/trac/ghc/ticket/10431
>

I've linked my ticket to that one.


AntC

> 
> > On Apr 30, 2017, at 3:35 PM, Brandon Allbery wrote: 
>>> On Sun, Apr 30, 2017 at 3:31 PM, Richard Eisenberg
wrote:
>>>> On Apr 30, 2017, at 6:37 AM, Anthony Clayden wrote:

>>>> Is that behaviour officially documented somewhere? 

>>> Not that I can find. Documentation on functional
>>> dependencies is somewhat lacking. This may be 
>>> because fundeps has received little love of late. 


From anthony_clayden at clear.net.nz  Mon May  8 00:42:41 2017
From: anthony_clayden at clear.net.nz (Anthony Clayden)
Date: Mon, 08 May 2017 12:42:41 +1200
Subject: Superclass Equality constraints cp FunDeps
Message-ID: <590fbf01.181.3f1d.13228@clear.net.nz>

Now that I've got the bit between my teeth ...

Superclass constraints are not subject to the Paterson
conditions.
IOW I can write superclass constraints
that are not permitted as instance constraints.
(Superclass constraints are required to be
 non-cyclic, which ensures they're terminating.)

Is that worth adding to the docos?

Something like this is OK:

> class (F a b ~ b) => C a b ...
> -- equivalently
> class (D a b b) => C a b ...

Can I think of a use for that? Maybe ...

Sometimes even though you have a type function,
you can use knowledge of the result
to 'improve' the parameters.

The classic case is adding type-level Naturals.

Maybe even type-level Boolean And:
- if the result is True, so must be the params.
- if the result is False,
  and you know one param is True,
  the other must be False.
- but that can't be a function, because
  if the result is False
  and you know one param is False,
  that tells nothing about the other param.


AntC

> > On Sun Apr 30 19:45:34 UTC 2017, Richard Eisenberg
> wrote:
> 
> > Documentation is just about always suboptimal -- but the
> > best people to suggest concrete improvements are those
> > who were confused to begin with. So, by all means,
> > submit patches!
> 
> OK. Done. See #13657.
> 


From rae at cs.brynmawr.edu  Mon May  8 17:43:39 2017
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Mon, 8 May 2017 13:43:39 -0400
Subject: Superclass Equality constraints cp FunDeps
In-Reply-To: <590fbf01.181.3f1d.13228@clear.net.nz>
References: <590fbf01.181.3f1d.13228@clear.net.nz>
Message-ID: <6DFE47A7-090E-40F3-9D16-F9CF3786867E@cs.brynmawr.edu>


> On May 7, 2017, at 8:42 PM, Anthony Clayden <anthony_clayden at clear.net.nz> wrote:
> 
> Is that worth adding to the docos?

The best way to evaluate this is to submit a concrete patch -- better if it’s a patch directly to the manual than just a note on Trac. (Better ==> it will be adopted sooner.) A great way to do this is to create a ticket on Trac and then post a patch on Phabricator. (https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/FixingBugs has some instructions)

Thanks!
Richard

From gale at sefer.org  Wed May 10 12:56:21 2017
From: gale at sefer.org (Yitzchak Gale)
Date: Wed, 10 May 2017 15:56:21 +0300
Subject: Unused import warning on re-export
Message-ID: <CAOrUaLYwVhpKfBJ2u4ghX+bGf95t0mUPLKkrnNdvLJVn2n1qHg@mail.gmail.com>

I have a module A with no export list, and a function f which from the
API point of view should part of the export list of A. But f must be
defined in module B, not module A, due an import cycle. I added this
line in module A to re-export f from A:

import B as A (f)

This resulted in an unused import warning. That is a problem for us -
we keep our large code base clean of warnings as a policy.

Is there a reason GHC considers this case an unused import? It seems
that the use of the import is explicitly stated right within the
import itself. Should I submit a ticket for this?

Thanks,
Yitz

From simonpj at microsoft.com  Thu May 11 20:23:00 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 11 May 2017 20:23:00 +0000
Subject: Unused import warning on re-export
In-Reply-To: <CAOrUaLYwVhpKfBJ2u4ghX+bGf95t0mUPLKkrnNdvLJVn2n1qHg@mail.gmail.com>
References: <CAOrUaLYwVhpKfBJ2u4ghX+bGf95t0mUPLKkrnNdvLJVn2n1qHg@mail.gmail.com>
Message-ID: <DM2PR21MB00281A07F71A4A4D505D0FDAADED0@DM2PR21MB0028.namprd21.prod.outlook.com>

| Is there a reason GHC considers this case an unused import? It seems that
| the use of the import is explicitly stated right within the import
| itself. Should I submit a ticket for this?

Hmm.  I think you are saying that

  module A where
    import B as A(f)
    g = True

that is equivalent to
   module A( module A ) where ...

which exports all things "x" in scope as "A.x".  So it'll export both f and g.

But GHC will report f as unused, but not g. And that's inconsistent.  Fair point.  Yes, file a ticket.  Better still, offer a patch :-).

Simon

| -----Original Message-----
| From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
| bounces at haskell.org] On Behalf Of Yitzchak Gale
| Sent: 10 May 2017 13:56
| To: GHC users <glasgow-haskell-users at haskell.org>
| Subject: Unused import warning on re-export
| 
| I have a module A with no export list, and a function f which from the
| API point of view should part of the export list of A. But f must be
| defined in module B, not module A, due an import cycle. I added this line
| in module A to re-export f from A:
| 
| import B as A (f)
| 
| This resulted in an unused import warning. That is a problem for us - we
| keep our large code base clean of warnings as a policy.
| 
| Is there a reason GHC considers this case an unused import? It seems that
| the use of the import is explicitly stated right within the import
| itself. Should I submit a ticket for this?
| 
| Thanks,
| Yitz
| _______________________________________________
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users at haskell.org
| https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask
| ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fglasgow-haskell-
| users&data=02%7C01%7Csimonpj%40microsoft.com%7C81b06c9737d540a597df08d497
| a413d0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636300178355700119&sd
| ata=xHt1FXEF5r4WMaMF3FSW4jFBRlB4OK8DQdcNAxZ7HOc%3D&reserved=0

From iavor.diatchki at gmail.com  Fri May 12 17:39:55 2017
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Fri, 12 May 2017 10:39:55 -0700
Subject: Unused import warning on re-export
In-Reply-To: <DM2PR21MB00281A07F71A4A4D505D0FDAADED0@DM2PR21MB0028.namprd21.prod.outlook.com>
References: <CAOrUaLYwVhpKfBJ2u4ghX+bGf95t0mUPLKkrnNdvLJVn2n1qHg@mail.gmail.com>
 <DM2PR21MB00281A07F71A4A4D505D0FDAADED0@DM2PR21MB0028.namprd21.prod.outlook.com>
Message-ID: <CAGK9nupec6fAhmEdHeZx8124Q8R8GnsdcxUyVdrsm9MH6h=7AQ@mail.gmail.com>

Hello,

actually, the bug here is that `f` is exported, as omitting the export list
is not equivalent to writing `module A` in the export list.

This is explicitly stated in Section 5.2 of the Haskell report:

 "If the export list is omitted, all values, types and classes defined in
the module are exported, but not those that are imported."

-Iavor









On Thu, May 11, 2017 at 1:23 PM, Simon Peyton Jones via
Glasgow-haskell-users <glasgow-haskell-users at haskell.org> wrote:

> | Is there a reason GHC considers this case an unused import? It seems that
> | the use of the import is explicitly stated right within the import
> | itself. Should I submit a ticket for this?
>
> Hmm.  I think you are saying that
>
>   module A where
>     import B as A(f)
>     g = True
>
> that is equivalent to
>    module A( module A ) where ...
>
> which exports all things "x" in scope as "A.x".  So it'll export both f
> and g.
>
> But GHC will report f as unused, but not g. And that's inconsistent.  Fair
> point.  Yes, file a ticket.  Better still, offer a patch :-).
>
> Simon
>
> | -----Original Message-----
> | From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
> | bounces at haskell.org] On Behalf Of Yitzchak Gale
> | Sent: 10 May 2017 13:56
> | To: GHC users <glasgow-haskell-users at haskell.org>
> | Subject: Unused import warning on re-export
> |
> | I have a module A with no export list, and a function f which from the
> | API point of view should part of the export list of A. But f must be
> | defined in module B, not module A, due an import cycle. I added this line
> | in module A to re-export f from A:
> |
> | import B as A (f)
> |
> | This resulted in an unused import warning. That is a problem for us - we
> | keep our large code base clean of warnings as a policy.
> |
> | Is there a reason GHC considers this case an unused import? It seems that
> | the use of the import is explicitly stated right within the import
> | itself. Should I submit a ticket for this?
> |
> | Thanks,
> | Yitz
> | _______________________________________________
> | Glasgow-haskell-users mailing list
> | Glasgow-haskell-users at haskell.org
> | https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fmail.hask
> | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fglasgow-haskell-
> | users&data=02%7C01%7Csimonpj%40microsoft.com%
> 7C81b06c9737d540a597df08d497
> | a413d0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%
> 7C636300178355700119&sd
> | ata=xHt1FXEF5r4WMaMF3FSW4jFBRlB4OK8DQdcNAxZ7HOc%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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20170512/7bf4f2e7/attachment.html>

From iavor.diatchki at gmail.com  Mon May 15 17:04:53 2017
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Mon, 15 May 2017 10:04:53 -0700
Subject: Unused import warning on re-export
In-Reply-To: <CAGK9nupec6fAhmEdHeZx8124Q8R8GnsdcxUyVdrsm9MH6h=7AQ@mail.gmail.com>
References: <CAOrUaLYwVhpKfBJ2u4ghX+bGf95t0mUPLKkrnNdvLJVn2n1qHg@mail.gmail.com>
 <DM2PR21MB00281A07F71A4A4D505D0FDAADED0@DM2PR21MB0028.namprd21.prod.outlook.com>
 <CAGK9nupec6fAhmEdHeZx8124Q8R8GnsdcxUyVdrsm9MH6h=7AQ@mail.gmail.com>
Message-ID: <CAGK9nuoAvDQ3yUfMBB7iJE=s6A2TQ6Ngo0PeCCoOZ_5yPtNTUw@mail.gmail.com>

Actually, I just tried to make an example of this, and GHC does not seem to
export `f`, just as the report says.  So I'd say GHC is behaving correctly,
both with the exports and the warning.



On Fri, May 12, 2017 at 10:39 AM, Iavor Diatchki <iavor.diatchki at gmail.com>
wrote:

> Hello,
>
> actually, the bug here is that `f` is exported, as omitting the export
> list is not equivalent to writing `module A` in the export list.
>
> This is explicitly stated in Section 5.2 of the Haskell report:
>
>  "If the export list is omitted, all values, types and classes defined in
> the module are exported, but not those that are imported."
>
> -Iavor
>
>
>
>
>
>
>
>
>
> On Thu, May 11, 2017 at 1:23 PM, Simon Peyton Jones via
> Glasgow-haskell-users <glasgow-haskell-users at haskell.org> wrote:
>
>> | Is there a reason GHC considers this case an unused import? It seems
>> that
>> | the use of the import is explicitly stated right within the import
>> | itself. Should I submit a ticket for this?
>>
>> Hmm.  I think you are saying that
>>
>>   module A where
>>     import B as A(f)
>>     g = True
>>
>> that is equivalent to
>>    module A( module A ) where ...
>>
>> which exports all things "x" in scope as "A.x".  So it'll export both f
>> and g.
>>
>> But GHC will report f as unused, but not g. And that's inconsistent.
>> Fair point.  Yes, file a ticket.  Better still, offer a patch :-).
>>
>> Simon
>>
>> | -----Original Message-----
>> | From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
>> | bounces at haskell.org] On Behalf Of Yitzchak Gale
>> | Sent: 10 May 2017 13:56
>> | To: GHC users <glasgow-haskell-users at haskell.org>
>> | Subject: Unused import warning on re-export
>> |
>> | I have a module A with no export list, and a function f which from the
>> | API point of view should part of the export list of A. But f must be
>> | defined in module B, not module A, due an import cycle. I added this
>> line
>> | in module A to re-export f from A:
>> |
>> | import B as A (f)
>> |
>> | This resulted in an unused import warning. That is a problem for us - we
>> | keep our large code base clean of warnings as a policy.
>> |
>> | Is there a reason GHC considers this case an unused import? It seems
>> that
>> | the use of the import is explicitly stated right within the import
>> | itself. Should I submit a ticket for this?
>> |
>> | Thanks,
>> | Yitz
>> | _______________________________________________
>> | Glasgow-haskell-users mailing list
>> | Glasgow-haskell-users at haskell.org
>> | https://na01.safelinks.protection.outlook.com/?url=http%3A%
>> 2F%2Fmail.hask
>> | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fglasgow-haskell-
>> | users&data=02%7C01%7Csimonpj%40microsoft.com%7C81b06c9737d54
>> 0a597df08d497
>> | a413d0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63630017
>> 8355700119&sd
>> | ata=xHt1FXEF5r4WMaMF3FSW4jFBRlB4OK8DQdcNAxZ7HOc%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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20170515/161bd2fc/attachment.html>

From ben at well-typed.com  Tue May 16 02:47:17 2017
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 15 May 2017 22:47:17 -0400
Subject: [ANNOUNCE] GHC 8.2.1 release candidate 2
Message-ID: <87fug5frgq.fsf@ben-laptop.smart-cactus.org>


Hello everyone,

The GHC team is very pleased to announce the second candidate of the
8.2.1 release of the Glasgow Haskell Compiler. Source and binary
distributions are available at

    https://downloads.haskell.org/~ghc/8.2.1-rc2/

This is the second of what will likely be either two or three release
candidates leading up the final 8.2.1 release. This release will
feature,

  * A new type-indexed Typeable implementation

  * The long awaited Backpack

  * Deriving strategies for disambiguating DeriveAnyClass,
    GeneralizedNewtypeDeriving, and stock mechanisms

  * Overloaded record fields

  * Improved compiler performance

  * Better code generation through more robust tracking of join points

  * Compact regions for more efficient garbage collection and serialization

  * Better support for machines with non-uniform memory architectures

  * More robust support for levity (e.g. RuntimeRep) polymorphism

  * A simple interface for streaming eventlog data from live processes

  * Further refinement of DWARF support

This candidate fixes most of the issues present in release candidate
one including,

 * #13233: typePrimRep panic while compiling GHC with profiling enabled
 * #13509: type error involving unboxed tuples
 * #13426: compile-time memory-usage regression
 * #13560: Windows binary distributions carry absolute paths to toolchain
 * #13585: Control.Lens.Wrapped.ala causes compiler panic
 * #13623: Join points produce bad code for stream fusion
 
As always, please let us know if you have difficulty. Thanks to everyone
who has contributed!

Happy testing,

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

From ben at well-typed.com  Tue May 16 18:19:29 2017
From: ben at well-typed.com (Ben Gamari)
Date: Tue, 16 May 2017 14:19:29 -0400
Subject: [ANNOUNCE] GHC 8.2.1 release candidate 2
In-Reply-To: <20170516171548.GA9248@x4>
References: <87fug5frgq.fsf@ben-laptop.smart-cactus.org>
 <20170516171548.GA9248@x4>
Message-ID: <87pof8ekb2.fsf@ben-laptop.smart-cactus.org>

Markus Trippelsdorf <markus at trippelsdorf.de> writes:

> On 2017.05.15 at 22:47 -0400, Ben Gamari wrote:
>>
>>
>> The GHC team is very pleased to announce the second candidate of the
>> 8.2.1 release of the Glasgow Haskell Compiler. Source and binary
>> distributions are available at
>>
>>     https://downloads.haskell.org/~ghc/8.2.1-rc2/
>>
>> This is the second of what will likely be either two or three release
>> candidates leading up the final 8.2.1 release. This release will
>> feature,
>>
>> As always, please let us know if you have difficulty. Thanks to everyone
>> who has contributed!
>>
>> Happy testing,
>
> Unfortunately xmobar segfaults from time to time when build with
> 8.2.1-rc2, e.g.:
>
Thanks for your report! Segfaults are certainly no good. Do you know
whether these are also reproducible with rc1? What version of xmobar are
you using? What does your configuration look like?

I've started an xmobar built from upstream's master branch with an empty
configuration to see whether this is reproducible locally.

I've opened #13707 to track this.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20170516/4fef0929/attachment.sig>

From george.colpitts at gmail.com  Wed May 17 11:52:32 2017
From: george.colpitts at gmail.com (George Colpitts)
Date: Wed, 17 May 2017 11:52:32 +0000
Subject: [ANNOUNCE] GHC 8.2.1 release candidate 2
In-Reply-To: <87fug5frgq.fsf@ben-laptop.smart-cactus.org>
References: <87fug5frgq.fsf@ben-laptop.smart-cactus.org>
Message-ID: <CAB-d4A5FGa-Ejp+aRgseSodaTrrZZwzeF-vXi6dO1Swx1EGMkg@mail.gmail.com>

Hi Ben

I built from source and ran the tests on my Mac and found some
problems. I'm not sure if the failing tests have been ran successfully
by others on this platform. I did "make slowtest". Maybe the problem
only happens on my machine.

I'm new to running the testsuite and not sure how the sleep settings on my
computer affect long running computations.

   - If I want to run a long running test such as "make slowtest" overnight
   will my computer go to sleep preventing the test from running? i.e. should
   I invoke it with something like "caffeinate -i make slowtest" ?

I almost didn't run the tests assuming they had been run as part of the
release process but then I guessed that maybe slowtest had not been run. It
would be a pain but would it be worth documenting which tests had been run
on which platforms?

I assume I should file a bug for the following?

make TEST=dynamic-paper WAY=profasm
...
=====> dynamic-paper(profasm) 1 of 1 [0, 0, 0]
cd "./dependent/should_compile/dynamic-paper.run" &&
 "/Users/gcolpitts/Downloads/ghc-8.2.0.20170507/inplace/bin/ghc-stage2" -c
dynamic-paper.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts
-fno-warn-missed-specialisations -fshow-warning-groups
-fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output  -O
-prof -static -fprof-auto
Compile failed (exit code 1) errors were:
ghc-stage2: panic! (the 'impossible' happened)
 (GHC version 8.2.0.20170507 for x86_64-apple-darwin):
Simplifier ticks exhausted
 When trying UnfoldingDone delta
 To increase the limit, use -fsimpl-tick-factor=N (default 100)
 If you need to do this, let GHC HQ know, and what factor you needed
 To see detailed counts use -ddump-simpl-stats
 Total ticks: 143842
 Call stack:
     CallStack (from HasCallStack):
prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1134:58 in
ghc:Outputable
callStackDoc, called at compiler/utils/Outputable.hs:1138:37 in
ghc:Outputable
pprPanic, called at compiler/simplCore/SimplMonad.hs:199:31 in
ghc:SimplMonad

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug


*** unexpected failure for dynamic-paper(profasm)

Unexpected results from:
TEST="dynamic-paper"

SUMMARY for test run started at Wed May 17 08:19:59 2017 ADT
0:00:06 spent to go through
      1 total tests, which gave rise to
      5 test cases, of which
      4 were skipped

      0 had missing libraries
      0 expected passes
      0 expected failures

      0 caused framework failures
      0 caused framework warnings
      0 unexpected passes
      1 unexpected failures
      0 unexpected stat failures

Unexpected failures:
  dependent/should_compile/dynamic-paper.run  dynamic-paper [exit code
non-0] (profasm)

It fails with  -fsimpl-tick-factor=1000 also:

make TEST=dynamic-paper WAY=profasm EXTRA_HC_OPTS='-fsimpl-tick-factor=1000'
...
cd "./dependent/should_compile/dynamic-paper.run" &&
 "/Users/gcolpitts/Downloads/ghc-8.2.0.20170507/inplace/bin/ghc-stage2" -c
dynamic-paper.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts
-fsimpl-tick-factor=1000 -fno-warn-missed-specialisations
-fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret
-dno-debug-output  -O -prof -static -fprof-auto
Compile failed (exit code 1) errors were:
ghc-stage2: panic! (the 'impossible' happened)
 (GHC version 8.2.0.20170507 for x86_64-apple-darwin):
Simplifier ticks exhausted
 When trying UnfoldingDone delta
 To increase the limit, use -fsimpl-tick-factor=N (default 100)
 If you need to do this, let GHC HQ know, and what factor you needed
 To see detailed counts use -ddump-simpl-stats
 Total ticks: 1438402
 Call stack:
     CallStack (from HasCallStack):
prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1134:58 in
ghc:Outputable
callStackDoc, called at compiler/utils/Outputable.hs:1138:37 in
ghc:Outputable
pprPanic, called at compiler/simplCore/SimplMonad.hs:199:31 in
ghc:SimplMonad

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug


*** unexpected failure for dynamic-paper(profasm)

Unexpected results from:
TEST="dynamic-paper"

SUMMARY for test run started at Wed May 17 08:29:43 2017 ADT
0:00:35 spent to go through
      1 total tests, which gave rise to
      5 test cases, of which
      4 were skipped

      0 had missing libraries
      0 expected passes
      0 expected failures

      0 caused framework failures
      0 caused framework warnings
      0 unexpected passes
      1 unexpected failures
      0 unexpected stat failures

Unexpected failures:
  dependent/should_compile/dynamic-paper.run  dynamic-paper [exit code
non-0] (profasm)



Cheers
George



On Mon, May 15, 2017 at 11:48 PM Ben Gamari <ben at well-typed.com> wrote:

>
> Hello everyone,
>
> The GHC team is very pleased to announce the second candidate of the
> 8.2.1 release of the Glasgow Haskell Compiler. Source and binary
> distributions are available at
>
>     https://downloads.haskell.org/~ghc/8.2.1-rc2/
>
> This is the second of what will likely be either two or three release
> candidates leading up the final 8.2.1 release. This release will
> feature,
>
>   * A new type-indexed Typeable implementation
>
>   * The long awaited Backpack
>
>   * Deriving strategies for disambiguating DeriveAnyClass,
>     GeneralizedNewtypeDeriving, and stock mechanisms
>
>   * Overloaded record fields
>
>   * Improved compiler performance
>
>   * Better code generation through more robust tracking of join points
>
>   * Compact regions for more efficient garbage collection and serialization
>
>   * Better support for machines with non-uniform memory architectures
>
>   * More robust support for levity (e.g. RuntimeRep) polymorphism
>
>   * A simple interface for streaming eventlog data from live processes
>
>   * Further refinement of DWARF support
>
> This candidate fixes most of the issues present in release candidate
> one including,
>
>  * #13233: typePrimRep panic while compiling GHC with profiling enabled
>  * #13509: type error involving unboxed tuples
>  * #13426: compile-time memory-usage regression
>  * #13560: Windows binary distributions carry absolute paths to toolchain
>  * #13585: Control.Lens.Wrapped.ala causes compiler panic
>  * #13623: Join points produce bad code for stream fusion
>
> As always, please let us know if you have difficulty. Thanks to everyone
> who has contributed!
>
> Happy testing,
>
> - Ben
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20170517/e9b9342c/attachment.html>

From ben at well-typed.com  Wed May 17 13:26:34 2017
From: ben at well-typed.com (Ben Gamari)
Date: Wed, 17 May 2017 09:26:34 -0400
Subject: [ANNOUNCE] GHC 8.2.1 release candidate 2
In-Reply-To: <CAB-d4A5FGa-Ejp+aRgseSodaTrrZZwzeF-vXi6dO1Swx1EGMkg@mail.gmail.com>
References: <87fug5frgq.fsf@ben-laptop.smart-cactus.org>
 <CAB-d4A5FGa-Ejp+aRgseSodaTrrZZwzeF-vXi6dO1Swx1EGMkg@mail.gmail.com>
Message-ID: <87lgpvehrp.fsf@ben-laptop.smart-cactus.org>

George Colpitts <george.colpitts at gmail.com> writes:

> Hi Ben
>
> I built from source and ran the tests on my Mac and found some
> problems. I'm not sure if the failing tests have been ran successfully
> by others on this platform. I did "make slowtest". Maybe the problem
> only happens on my machine.
>
Currently Harbormaster only runs `make test`, not `make slowtest`.
Consequently, `slowtest` is generally rather broken, even on Linux.
Every once in a while I look at it and try to pare down the failures,
but it's an up-hill battle.

> I'm new to running the testsuite and not sure how the sleep settings on my
> computer affect long running computations.
>
>    - If I want to run a long running test such as "make slowtest" overnight
>    will my computer go to sleep preventing the test from running? i.e. should
>    I invoke it with something like "caffeinate -i make slowtest" ?
>
That sounds right to me.

> I almost didn't run the tests assuming they had been run as part of the
> release process but then I guessed that maybe slowtest had not been run. It
> would be a pain but would it be worth documenting which tests had been run
> on which platforms?
>
I currently don't validate the binary distribution tarballs. Instead I
judge validation state from Harbormaster's testing of the ghc-8.2
branch.

Over the summer we intend on revamping our CI infrastructure, which
should make it easier to do nightly runs of slowtest (and perhaps
provide nightly or even per-commit binary distributions).

> I assume I should file a bug for the following?
>
That would be great. I had a quick look at this and it looks quite
likely that the simplifier is looping: even -fsimpl-tick-factor=1000
doesn't succeed. This looks like a real regression.

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20170517/30a69f32/attachment.sig>

From george.colpitts at gmail.com  Wed May 17 16:44:10 2017
From: george.colpitts at gmail.com (George Colpitts)
Date: Wed, 17 May 2017 16:44:10 +0000
Subject: [ANNOUNCE] GHC 8.2.1 release candidate 2
In-Reply-To: <87lgpvehrp.fsf@ben-laptop.smart-cactus.org>
References: <87fug5frgq.fsf@ben-laptop.smart-cactus.org>
 <CAB-d4A5FGa-Ejp+aRgseSodaTrrZZwzeF-vXi6dO1Swx1EGMkg@mail.gmail.com>
 <87lgpvehrp.fsf@ben-laptop.smart-cactus.org>
Message-ID: <CAB-d4A6mpbZOy8jbGTfXLf0tY9CoUdRTy_Gh=p7PoACpFHr5YA@mail.gmail.com>

Yes, I agree, will file a bug this evening.

On Wed, May 17, 2017 at 10:26 AM Ben Gamari <ben at well-typed.com> wrote:

> George Colpitts <george.colpitts at gmail.com> writes:
>
> > Hi Ben
> >
> > I built from source and ran the tests on my Mac and found some
> > problems. I'm not sure if the failing tests have been ran successfully
> > by others on this platform. I did "make slowtest". Maybe the problem
> > only happens on my machine.
> >
> Currently Harbormaster only runs `make test`, not `make slowtest`.
> Consequently, `slowtest` is generally rather broken, even on Linux.
> Every once in a while I look at it and try to pare down the failures,
> but it's an up-hill battle.
>
> > I'm new to running the testsuite and not sure how the sleep settings on
> my
> > computer affect long running computations.
> >
> >    - If I want to run a long running test such as "make slowtest"
> overnight
> >    will my computer go to sleep preventing the test from running? i.e.
> should
> >    I invoke it with something like "caffeinate -i make slowtest" ?
> >
> That sounds right to me.
>
> > I almost didn't run the tests assuming they had been run as part of the
> > release process but then I guessed that maybe slowtest had not been run.
> It
> > would be a pain but would it be worth documenting which tests had been
> run
> > on which platforms?
> >
> I currently don't validate the binary distribution tarballs. Instead I
> judge validation state from Harbormaster's testing of the ghc-8.2
> branch.
>
> Over the summer we intend on revamping our CI infrastructure, which
> should make it easier to do nightly runs of slowtest (and perhaps
> provide nightly or even per-commit binary distributions).
>
> > I assume I should file a bug for the following?
> >
> That would be great. I had a quick look at this and it looks quite
> likely that the simplifier is looping: even -fsimpl-tick-factor=1000
> doesn't succeed. This looks like a real regression.
>
> Cheers,
>
> - Ben
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20170517/c091ded5/attachment.html>

From george.colpitts at gmail.com  Wed May 17 22:01:26 2017
From: george.colpitts at gmail.com (George Colpitts)
Date: Wed, 17 May 2017 22:01:26 +0000
Subject: [ANNOUNCE] GHC 8.2.1 release candidate 2
In-Reply-To: <CAB-d4A6mpbZOy8jbGTfXLf0tY9CoUdRTy_Gh=p7PoACpFHr5YA@mail.gmail.com>
References: <87fug5frgq.fsf@ben-laptop.smart-cactus.org>
 <CAB-d4A5FGa-Ejp+aRgseSodaTrrZZwzeF-vXi6dO1Swx1EGMkg@mail.gmail.com>
 <87lgpvehrp.fsf@ben-laptop.smart-cactus.org>
 <CAB-d4A6mpbZOy8jbGTfXLf0tY9CoUdRTy_Gh=p7PoACpFHr5YA@mail.gmail.com>
Message-ID: <CAB-d4A7cqLWELCtw6EW7wKjFUqihUCr7hVrJDS0y_SRdgBFZEg@mail.gmail.com>

Done: https://ghc.haskell.org/trac/ghc/ticket/13715#ticket

On Wed, May 17, 2017 at 1:44 PM George Colpitts <george.colpitts at gmail.com>
wrote:

> Yes, I agree, will file a bug this evening.
>
> On Wed, May 17, 2017 at 10:26 AM Ben Gamari <ben at well-typed.com> wrote:
>
>> George Colpitts <george.colpitts at gmail.com> writes:
>>
>> > Hi Ben
>> >
>> > I built from source and ran the tests on my Mac and found some
>> > problems. I'm not sure if the failing tests have been ran successfully
>> > by others on this platform. I did "make slowtest". Maybe the problem
>> > only happens on my machine.
>> >
>> Currently Harbormaster only runs `make test`, not `make slowtest`.
>> Consequently, `slowtest` is generally rather broken, even on Linux.
>> Every once in a while I look at it and try to pare down the failures,
>> but it's an up-hill battle.
>>
>> > I'm new to running the testsuite and not sure how the sleep settings on
>> my
>> > computer affect long running computations.
>> >
>> >    - If I want to run a long running test such as "make slowtest"
>> overnight
>> >    will my computer go to sleep preventing the test from running? i.e.
>> should
>> >    I invoke it with something like "caffeinate -i make slowtest" ?
>> >
>> That sounds right to me.
>>
>> > I almost didn't run the tests assuming they had been run as part of the
>> > release process but then I guessed that maybe slowtest had not been
>> run. It
>> > would be a pain but would it be worth documenting which tests had been
>> run
>> > on which platforms?
>> >
>> I currently don't validate the binary distribution tarballs. Instead I
>> judge validation state from Harbormaster's testing of the ghc-8.2
>> branch.
>>
>> Over the summer we intend on revamping our CI infrastructure, which
>> should make it easier to do nightly runs of slowtest (and perhaps
>> provide nightly or even per-commit binary distributions).
>>
>> > I assume I should file a bug for the following?
>> >
>> That would be great. I had a quick look at this and it looks quite
>> likely that the simplifier is looping: even -fsimpl-tick-factor=1000
>> doesn't succeed. This looks like a real regression.
>>
>> Cheers,
>>
>> - Ben
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20170517/78dd3875/attachment.html>

From alberto at toscat.net  Fri May 19 09:33:36 2017
From: alberto at toscat.net (Alberto Valverde)
Date: Fri, 19 May 2017 11:33:36 +0200
Subject: [ANNOUNCE] GHC 8.2.1 release candidate 2
In-Reply-To: <87fug5frgq.fsf@ben-laptop.smart-cactus.org>
References: <87fug5frgq.fsf@ben-laptop.smart-cactus.org>
Message-ID: <CA+F8DE4XhqZA3+nFG+VZdup7mVY3MXfYgtjWO5HS4Ut14G106Q@mail.gmail.com>

Hi,

I'm trying to build an app with the new release candidate and I'm running
into a couple of issues, some which I can fix or workaround, some are
worrisome and others are blocking me. I'm using Nix, if that matters.

The fixable
---------------

- The expected too strict version bounds. Worked around using doJailbreak,
will send PRs to the respective packages with relaxed bounds.
- A weird kind error when using ConstraintKinds in a propietary package
which didn't manifest itself with ghc < 8.2:

src/Sigym4/Propag/Types.hs:1071:4: error:
    • Expected a type, but
      ‘(PropagIOConstraint l a,
        Missing (PropagIOVector l) (PropagIONullable l a),
        Elem (PropagIONullable l a) ~ a)’ has kind
      ‘Constraint’
    • In the type ‘((PropagIOConstraint l a,
                     Missing (PropagIOVector l) (PropagIONullable l a),
                     Elem (PropagIONullable l a) ~ a))’
      In the type declaration for ‘CanSerialize’
     |
1071 |   (( PropagIOConstraint l a
     |    ^^^^^^^^^^^^^^^^^^^^^^^^...

src/Sigym4/Propag/Types.hs:1077:4: error:
    • Expected a constraint,
        but ‘(CanSerialize l Double, CanSerialize l Int16)’ has kind ‘*’
    • In the type ‘(CanSerialize l Double, CanSerialize l Int16)’
      In the type declaration for ‘CanSerializePropagTypes’
     |
1077 |    ( CanSerialize l Double
     |    ^^^^^^^^^^^^^^^^^^^^^^^...

I cannot link to the source for this package since it belongs to my
employer but I think that the interesting code is:

type CanSerialize l a =
( PropagIOConstraint l a
, Missing (PropagIOVector l) (PropagIONullable l a)
, Elem (PropagIONullable l a) ~ a
)

where PropagIOConstraint, PropagIONullable and PropagIOVector are
"standalone" type families and Elem is an associated type family (not from
IsList)

Both errors disappear if I give an explicit kind signature like this: "type
CanSerialize l a = (..... :: Constraint)". Is this expected behaviour?
Should I try to isolate and open a ticket?

The worrisome
--------------------

- I had to disable the tests for two packages since they seem to "hang"
 (ie: they never finish running and don't seem to consume any CPU time).
These packages are lens-4.15.1 and fingertree-0.1.1.0. Maybe it's a Nix
environmental issue, I'm not sure. Can anyone reproduce this?

The blockers
-----------------

- I can't manage to install several packages which include executables
(namely, update-nix-fetchgit and snap-server, for the moment) because Cabal
says that it cannot find the source for the main module of the executables:

"Setup: can't find source for Main in ."

It seems that the "hs-source-dir" directive in the .cabal file is not being
honored. Maybe a Nix-only issue? Can anyone reproduce this? Any ideas on
how can I fix it?

Thanks very much for GHC, btw :)

Alberto


On Tue, May 16, 2017 at 4:47 AM, Ben Gamari <ben at well-typed.com> wrote:

>
> Hello everyone,
>
> The GHC team is very pleased to announce the second candidate of the
> 8.2.1 release of the Glasgow Haskell Compiler. Source and binary
> distributions are available at
>
>     https://downloads.haskell.org/~ghc/8.2.1-rc2/
>
> This is the second of what will likely be either two or three release
> candidates leading up the final 8.2.1 release. This release will
> feature,
>
>   * A new type-indexed Typeable implementation
>
>   * The long awaited Backpack
>
>   * Deriving strategies for disambiguating DeriveAnyClass,
>     GeneralizedNewtypeDeriving, and stock mechanisms
>
>   * Overloaded record fields
>
>   * Improved compiler performance
>
>   * Better code generation through more robust tracking of join points
>
>   * Compact regions for more efficient garbage collection and serialization
>
>   * Better support for machines with non-uniform memory architectures
>
>   * More robust support for levity (e.g. RuntimeRep) polymorphism
>
>   * A simple interface for streaming eventlog data from live processes
>
>   * Further refinement of DWARF support
>
> This candidate fixes most of the issues present in release candidate
> one including,
>
>  * #13233: typePrimRep panic while compiling GHC with profiling enabled
>  * #13509: type error involving unboxed tuples
>  * #13426: compile-time memory-usage regression
>  * #13560: Windows binary distributions carry absolute paths to toolchain
>  * #13585: Control.Lens.Wrapped.ala causes compiler panic
>  * #13623: Join points produce bad code for stream fusion
>
> As always, please let us know if you have difficulty. Thanks to everyone
> who has contributed!
>
> Happy testing,
>
> - Ben
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20170519/ee30dbc2/attachment.html>