From lemming at henning-thielemann.de  Sat Jan  9 22:57:37 2016
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Sat, 9 Jan 2016 23:57:37 +0100 (CET)
Subject: =?ISO-8859-7?Q?suppress_warning_=22Defined_but_not_used=3A_type_variable_=A1x=A2=22_in_GHC-8=2E0?=
Message-ID: <alpine.DEB.2.02.1601092352010.8054@sputnik>


GHC-8.0 emits several new warnings of this kind:

    Defined but not used: type variable ?x?

for declarations like

    type instance Snd x y = y

Enthusiastically, I started to replace unused type function arguments by 
underscores, only to find out that older GHC versions do not accept that. 
With what option can I disable this warning? Or can it be removed from 
-Wall for now?

From carter.schonwald at gmail.com  Sat Jan  9 23:06:07 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 9 Jan 2016 18:06:07 -0500
Subject: =?UTF-8?Q?Re=3A_suppress_warning_=22Defined_but_not_used=3A_type_var?=
 =?UTF-8?Q?iable_=E2=80=98x=E2=80=99=22_in_GHC=2D8=2E0?=
In-Reply-To: <alpine.DEB.2.02.1601092352010.8054@sputnik>
References: <alpine.DEB.2.02.1601092352010.8054@sputnik>
Message-ID: <CAHYVw0w7R28G+BTUZXHEUrj1xYAu+ywsY_a1haPNQY=3sy3FCA@mail.gmail.com>

Have you tried _x instead?

On Saturday, January 9, 2016, Henning Thielemann <
lemming at henning-thielemann.de> wrote:

>
> GHC-8.0 emits several new warnings of this kind:
>
>    Defined but not used: type variable ?x?
>
> for declarations like
>
>    type instance Snd x y = y
>
> Enthusiastically, I started to replace unused type function arguments by
> underscores, only to find out that older GHC versions do not accept that.
> With what option can I disable this warning? Or can it be removed from
> -Wall for now?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20160109/600e11b9/attachment.html>

From lemming at henning-thielemann.de  Sat Jan  9 23:44:41 2016
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Sun, 10 Jan 2016 00:44:41 +0100 (CET)
Subject: =?ISO-8859-7?Q?Re=3A_suppress_warning_=22Defined_but_not_used=3A_type_variable_=A1x=A2=22_in_GHC-8=2E0?=
In-Reply-To: <CAHYVw0w7R28G+BTUZXHEUrj1xYAu+ywsY_a1haPNQY=3sy3FCA@mail.gmail.com>
References: <alpine.DEB.2.02.1601092352010.8054@sputnik>
 <CAHYVw0w7R28G+BTUZXHEUrj1xYAu+ywsY_a1haPNQY=3sy3FCA@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1601100031270.8054@sputnik>


On Sat, 9 Jan 2016, Carter Schonwald wrote:

> Have you tried _x instead?

Ah, this solves the problem! Almost.

I have an instance like this one:

instance (Natural n) => Num.Integer (Un n) where
     type Repr (Un _n) = Unary


GHC-7.6.3 and GHC-7.4.2 complain:
     Type indexes must match class instance head
     Found `Un _n' but expected `Un n'
     In the type synonym instance declaration for `Num.Repr'
     In the instance declaration for `Num.Integer (Un n)'


GHC-7.8.4, GHC-7.10.3 and GHC-8.0 are happy with the difference.

From lemming at henning-thielemann.de  Sat Jan  9 23:49:26 2016
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Sun, 10 Jan 2016 00:49:26 +0100 (CET)
Subject: Optimization of IORefs and STRefs - comparison to g++
Message-ID: <alpine.DEB.2.02.1601100047020.8054@sputnik>


How about just using alloca, peek and poke - like C guys do in order to 
get C's speed?

From eir at cis.upenn.edu  Mon Jan 11 17:42:38 2016
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Mon, 11 Jan 2016 12:42:38 -0500
Subject: =?windows-1252?Q?Re=3A_suppress_warning_=22Defined_but_not_used?=
 =?windows-1252?Q?=3A_type_variable_=91x=92=22_in_GHC-8=2E0?=
In-Reply-To: <alpine.DEB.2.02.1601100031270.8054@sputnik>
References: <alpine.DEB.2.02.1601092352010.8054@sputnik>
 <CAHYVw0w7R28G+BTUZXHEUrj1xYAu+ywsY_a1haPNQY=3sy3FCA@mail.gmail.com>
 <alpine.DEB.2.02.1601100031270.8054@sputnik>
Message-ID: <DCB10CB2-ABBA-42B0-B1AE-16B986233FC1@cis.upenn.edu>


On Jan 9, 2016, at 6:44 PM, Henning Thielemann <lemming at henning-thielemann.de> wrote:
> 
> instance (Natural n) => Num.Integer (Un n) where
>    type Repr (Un _n) = Unary
> 
> 
> GHC-7.6.3 and GHC-7.4.2 complain:
>    Type indexes must match class instance head
>    Found `Un _n' but expected `Un n'
>    In the type synonym instance declaration for `Num.Repr'
>    In the instance declaration for `Num.Integer (Un n)'
> 
> 
> GHC-7.8.4, GHC-7.10.3 and GHC-8.0 are happy with the difference.

I'm surprised this is accepted at all. Looks like hogwash to me. I think you should post a bug report.

Richard

From lemming at henning-thielemann.de  Mon Jan 11 19:12:39 2016
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Mon, 11 Jan 2016 20:12:39 +0100 (CET)
Subject: =?ISO-8859-7?Q?Re=3A_suppress_warning_=22Defined_but_not_used=3A_type_variable_=A1x=A2=22_in_GHC-8=2E0?=
In-Reply-To: <DCB10CB2-ABBA-42B0-B1AE-16B986233FC1@cis.upenn.edu>
References: <alpine.DEB.2.02.1601092352010.8054@sputnik>
 <CAHYVw0w7R28G+BTUZXHEUrj1xYAu+ywsY_a1haPNQY=3sy3FCA@mail.gmail.com>
 <alpine.DEB.2.02.1601100031270.8054@sputnik>
 <DCB10CB2-ABBA-42B0-B1AE-16B986233FC1@cis.upenn.edu>
Message-ID: <alpine.DEB.2.02.1601112011410.8884@sputnik>


On Mon, 11 Jan 2016, Richard Eisenberg wrote:

> On Jan 9, 2016, at 6:44 PM, Henning Thielemann <lemming at henning-thielemann.de> wrote:
>>
>> instance (Natural n) => Num.Integer (Un n) where
>>    type Repr (Un _n) = Unary
>>
>>
>> GHC-7.6.3 and GHC-7.4.2 complain:
>>    Type indexes must match class instance head
>>    Found `Un _n' but expected `Un n'
>>    In the type synonym instance declaration for `Num.Repr'
>>    In the instance declaration for `Num.Integer (Un n)'
>>
>>
>> GHC-7.8.4, GHC-7.10.3 and GHC-8.0 are happy with the difference.
>
> I'm surprised this is accepted at all. Looks like hogwash to me. I think you should post a bug report.

Ok, but then GHC must not warn about the unused argument of Repr.

From marlowsd at gmail.com  Tue Jan 12 16:18:46 2016
From: marlowsd at gmail.com (Simon Marlow)
Date: Tue, 12 Jan 2016 16:18:46 +0000
Subject: Warnings, -Wall, and versioning policy
Message-ID: <56952766.2000505@gmail.com>

Hi folks,

We haven't described what guarantees GHC provides with respect to -Wall 
behaviour across versions, and as a result there are some differing 
expectations around this.  It came up in this weeks' GHC meeting, so we 
thought it would be a good idea to state the policy explicitly.  Here it is:

   We guarantee that code that compiles with no warnings with -Wall
   ("Wall-clean") and a particular GHC version, on a particular
   platform, will be Wall-clean with future minor releases of the same
   major GHC version on the same platform.

(we plan to put this text in the User's Guide for future releases)

There are no other guarantees.  In particular:
- In a new major release, GHC may introduce new warnings into -Wall, 
and/or change the meaning of existing warnings such that they trigger 
(or not) under different conditions.
- GHC may generate different warnings on different platforms. (examples 
of this are -fwarn-overflowed-literals and 
-fwarn-unsupported-calling-conventions)

Some rationale:
- We consider any change to the language that GHC accepts to be a 
potentially code-breaking change, and subject to careful scrutiny. To 
extend this to warnings would be a *lot* of work, and would make it 
really difficult to introduce new warnings and improve the existing ones.
- Warnings can be based on analyses that can change in accuracy over 
time. The -fwarn-unused-imports warning has changed a lot in what it 
rejects, for example.
- We often introduce new warnings that naturally belong in -Wall. If 
-Wall was required to be a fixed point, we would have to start 
introducing new flags, and versioning, etc. and even keep the old 
implementation of warnings when they change. It would get really messy.

There are some consequences to this.  -Wall -Werror is useful for 
keeping your code warning-clean when developing, but shipping code with 
these options turned on in the build system is asking for trouble when 
building your code with different GHC versions and platforms.  Keep 
those options for development only.  Hackage already rejects packages 
that include -Wall for this reason.

One reason we're raising this now is that it causes problems for the 
3-release policy 
(https://prime.haskell.org/wiki/Libraries/3-Release-Policy) which 
requires that it be possible to write code that is Wall-clean with 3 
major releases of GHC.  GHC itself doesn't guarantee this, so it might 
be hard for the core libraries committee to provide this guarantee.  I 
suggest this requirement be dropped from the policy.

Cheers,
Simon

From gershomb at gmail.com  Wed Jan 13 02:19:45 2016
From: gershomb at gmail.com (Gershom B)
Date: Tue, 12 Jan 2016 21:19:45 -0500
Subject: Warnings, -Wall, and versioning policy
In-Reply-To: <56952766.2000505@gmail.com>
References: <56952766.2000505@gmail.com>
Message-ID: <etPan.5695b47e.25d11c39.241@mbp.local>

Hi Simon. I think you raise important issues here, although I believe you?re mistaken in one regard. Hackage rejects -Werror but I don?t think it rejects -Wall.

?What I?d suggest is perhaps the following.

1) The libraries committee put forward -Wall cleanliness as an _aspirational goal_ rather than a final product, noting that the actual cleanliness might be with regards to `-Wall -Wno-foo -Wno-bar``.

2) GHC _change its code_ so that `ghc -Wno-wat` yields a _warning_ rather than an _error_ on `-W` followed by an unrecognized string.

3) No warning flags be introduced into the _default_ set without at least a few releases in some other set such as `-Wall`.

We may also want to try to maintain a ?best practices? example cabal file that shows how one can build with additional warnings under a ?dev? flag, and with fewer warnings otherwise ? so that the noise inflicted on package devs under their builds doesn?t get inflicted on all end users, and even perhaps with different warning flags per ghc version flag.

I think this will respect the concerns of people that like to use `-Wall`, want to have relatively warning clean code, and want to have some degree of backwards compatibility (which is not an unreasonable combination in my opinion).

Some related discussion:?https://ghc.haskell.org/trac/ghc/ticket/11370?and?https://ghc.haskell.org/trac/ghc/wiki/Design/Warnings

Cheers,
Gershom


On January 12, 2016 at 11:18:57 AM, Simon Marlow (marlowsd at gmail.com) wrote:
> Hi folks,
>  
> We haven't described what guarantees GHC provides with respect to -Wall
> behaviour across versions, and as a result there are some differing
> expectations around this. It came up in this weeks' GHC meeting, so we
> thought it would be a good idea to state the policy explicitly. Here it is:
>  
> We guarantee that code that compiles with no warnings with -Wall
> ("Wall-clean") and a particular GHC version, on a particular
> platform, will be Wall-clean with future minor releases of the same
> major GHC version on the same platform.
>  
> (we plan to put this text in the User's Guide for future releases)
>  
> There are no other guarantees. In particular:
> - In a new major release, GHC may introduce new warnings into -Wall,
> and/or change the meaning of existing warnings such that they trigger
> (or not) under different conditions.
> - GHC may generate different warnings on different platforms. (examples
> of this are -fwarn-overflowed-literals and
> -fwarn-unsupported-calling-conventions)
>  
> Some rationale:
> - We consider any change to the language that GHC accepts to be a
> potentially code-breaking change, and subject to careful scrutiny. To
> extend this to warnings would be a *lot* of work, and would make it
> really difficult to introduce new warnings and improve the existing ones.
> - Warnings can be based on analyses that can change in accuracy over
> time. The -fwarn-unused-imports warning has changed a lot in what it
> rejects, for example.
> - We often introduce new warnings that naturally belong in -Wall. If
> -Wall was required to be a fixed point, we would have to start
> introducing new flags, and versioning, etc. and even keep the old
> implementation of warnings when they change. It would get really messy.
>  
> There are some consequences to this. -Wall -Werror is useful for
> keeping your code warning-clean when developing, but shipping code with
> these options turned on in the build system is asking for trouble when
> building your code with different GHC versions and platforms. Keep
> those options for development only. Hackage already rejects packages
> that include -Wall for this reason.
>  
> One reason we're raising this now is that it causes problems for the
> 3-release policy
> (https://prime.haskell.org/wiki/Libraries/3-Release-Policy) which
> requires that it be possible to write code that is Wall-clean with 3
> major releases of GHC. GHC itself doesn't guarantee this, so it might
> be hard for the core libraries committee to provide this guarantee. I
> suggest this requirement be dropped from the policy.
>  
> Cheers,
> Simon
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>  


From simonpj at microsoft.com  Wed Jan 13 12:43:58 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 13 Jan 2016 12:43:58 +0000
Subject: Warnings, -Wall, and versioning policy
In-Reply-To: <etPan.5695b47e.25d11c39.241@mbp.local>
References: <56952766.2000505@gmail.com>
 <etPan.5695b47e.25d11c39.241@mbp.local>
Message-ID: <f38ee6ffa3bb4fa0b4b986150ffab707@DB4PR30MB030.064d.mgd.msft.net>

Thanks Gershom.  That all sounds fine to me.  

An implication is that GHC is free to introduce new warnings X into -Wall.   Indeed doing so would be good, because the warning X might later move into the default set.  Indeed for such warnings, adding a "PS: this warning will become the default in GHC 9.2" might be a useful way to signal the upcoming change.  Then you can use -Wall and look for any "PS" indicators.

You don?t give a rationale for (2) but I think you intend that if someone wants to add -Wno-X when GHC introduces X in 9.0, you don't want GHC 8.6 to fall over.  Worth articulating the rationale.

Simon

| -----Original Message-----
| From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
| bounces at haskell.org] On Behalf Of Gershom B
| Sent: 13 January 2016 02:20
| To: GHC users <glasgow-haskell-users at haskell.org>; ghc-devs at haskell.org;
| Edward Kmett <ekmett at gmail.com>; Herbert Valerio Riedel <hvr at gnu.org>; Simon
| Marlow <marlowsd at gmail.com>
| Subject: Re: Warnings, -Wall, and versioning policy
| 
| Hi Simon. I think you raise important issues here, although I believe you?re
| mistaken in one regard. Hackage rejects -Werror but I don?t think it rejects
| -Wall.
| 
| ?What I?d suggest is perhaps the following.
| 
| 1) The libraries committee put forward -Wall cleanliness as an _aspirational
| goal_ rather than a final product, noting that the actual cleanliness might
| be with regards to `-Wall -Wno-foo -Wno-bar``.
| 
| 2) GHC _change its code_ so that `ghc -Wno-wat` yields a _warning_ rather
| than an _error_ on `-W` followed by an unrecognized string.
| 
| 3) No warning flags be introduced into the _default_ set without at least a
| few releases in some other set such as `-Wall`.
| 
| We may also want to try to maintain a ?best practices? example cabal file
| that shows how one can build with additional warnings under a ?dev? flag, and
| with fewer warnings otherwise ? so that the noise inflicted on package devs
| under their builds doesn?t get inflicted on all end users, and even perhaps
| with different warning flags per ghc version flag.
| 
| I think this will respect the concerns of people that like to use `-Wall`,
| want to have relatively warning clean code, and want to have some degree of
| backwards compatibility (which is not an unreasonable combination in my
| opinion).
| 
| Some related
| discussion:?https://ghc.haskell.org/trac/ghc/ticket/11370?and?https://ghc.has
| kell.org/trac/ghc/wiki/Design/Warnings
| 
| Cheers,
| Gershom
| 
| 
| On January 12, 2016 at 11:18:57 AM, Simon Marlow (marlowsd at gmail.com) wrote:
| > Hi folks,
| >
| > We haven't described what guarantees GHC provides with respect to -Wall
| > behaviour across versions, and as a result there are some differing
| > expectations around this. It came up in this weeks' GHC meeting, so we
| > thought it would be a good idea to state the policy explicitly. Here it is:
| >
| > We guarantee that code that compiles with no warnings with -Wall
| > ("Wall-clean") and a particular GHC version, on a particular
| > platform, will be Wall-clean with future minor releases of the same
| > major GHC version on the same platform.
| >
| > (we plan to put this text in the User's Guide for future releases)
| >
| > There are no other guarantees. In particular:
| > - In a new major release, GHC may introduce new warnings into -Wall,
| > and/or change the meaning of existing warnings such that they trigger
| > (or not) under different conditions.
| > - GHC may generate different warnings on different platforms. (examples
| > of this are -fwarn-overflowed-literals and
| > -fwarn-unsupported-calling-conventions)
| >
| > Some rationale:
| > - We consider any change to the language that GHC accepts to be a
| > potentially code-breaking change, and subject to careful scrutiny. To
| > extend this to warnings would be a *lot* of work, and would make it
| > really difficult to introduce new warnings and improve the existing ones.
| > - Warnings can be based on analyses that can change in accuracy over
| > time. The -fwarn-unused-imports warning has changed a lot in what it
| > rejects, for example.
| > - We often introduce new warnings that naturally belong in -Wall. If
| > -Wall was required to be a fixed point, we would have to start
| > introducing new flags, and versioning, etc. and even keep the old
| > implementation of warnings when they change. It would get really messy.
| >
| > There are some consequences to this. -Wall -Werror is useful for
| > keeping your code warning-clean when developing, but shipping code with
| > these options turned on in the build system is asking for trouble when
| > building your code with different GHC versions and platforms. Keep
| > those options for development only. Hackage already rejects packages
| > that include -Wall for this reason.
| >
| > One reason we're raising this now is that it causes problems for the
| > 3-release policy
| >
| (https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fprime.haske
| ll.org%2fwiki%2fLibraries%2f3-Release-
| Policy&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c5d13dce17e0b47a80263
| 08d31bc02832%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=KzdY%2bG8jP8ofztNpN
| khKGyB5PVW1XUWbw2lCQqdSNmc%3d) which
| > requires that it be possible to write code that is Wall-clean with 3
| > major releases of GHC. GHC itself doesn't guarantee this, so it might
| > be hard for the core libraries committee to provide this guarantee. I
| > suggest this requirement be dropped from the policy.
| >
| > Cheers,
| > Simon
| > _______________________________________________
| > Glasgow-haskell-users mailing list
| > Glasgow-haskell-users at haskell.org
| >
| https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.
| org%2fcgi-bin%2fmailman%2flistinfo%2fglasgow-haskell-
| users&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c5d13dce17e0b47a802630
| 8d31bc02832%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=f395AsIaHpKb8S9z4CAo
| qfGhiDxa5tzQUo8Sm5%2bgKPQ%3d
| >
| 
| _______________________________________________
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users at haskell.org
| https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.
| org%2fcgi-bin%2fmailman%2flistinfo%2fglasgow-haskell-
| users%0a&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c5d13dce17e0b47a802
| 6308d31bc02832%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=6snGzNQuPSFVsZ2SY
| fAxdSvo%2fjCOXvlq6cwzQM0L6iY%3d

From ben at well-typed.com  Wed Jan 13 16:19:19 2016
From: ben at well-typed.com (Ben Gamari)
Date: Wed, 13 Jan 2016 17:19:19 +0100
Subject: Dropping bzip2 release tarballs?
Message-ID: <87r3hl5u60.fsf@smart-cactus.org>

tl;dr do you rely on the .bz2 release tarballs on downloads.haskell.org?
      If so, let us know!


Hello everyone,

As you may have noticed, a few releases ago we started producing
xz-compressed binary distributions in addition to the usual bzip2
tarballs.

While preparing 8.0.1-rc1 it was suggested that we move to distributing
xz tarballs exclusively. Not only would this move reduce storage and
bandwidth demands on our infrastructure but it would also simplify the
job of producing the distributions. Indeed there is plenty of precendent 
for projects who have moved exclusively to xz (the Linux kernel and git
being two examples).

Of course, these reasons alone aren't sufficient to abandon those who
might rely on our bzip2 tarballs. If you feel strongly that we should
continue to distribute bzip2 tarballs, please let us know.

Thanks!

- Your friendly GHC packaging gnomes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20160113/b15766bf/attachment.sig>

From gershomb at gmail.com  Wed Jan 13 18:17:46 2016
From: gershomb at gmail.com (Gershom B)
Date: Wed, 13 Jan 2016 13:17:46 -0500
Subject: Warnings, -Wall, and versioning policy
In-Reply-To: <f38ee6ffa3bb4fa0b4b986150ffab707@DB4PR30MB030.064d.mgd.msft.net>
References: <56952766.2000505@gmail.com>
 <etPan.5695b47e.25d11c39.241@mbp.local>
 <f38ee6ffa3bb4fa0b4b986150ffab707@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <CAM8RHpELBHbsuif+qZerQYRPrcjRaRB74cviOnCFUybLqr5QSA@mail.gmail.com>

On Wed, Jan 13, 2016 at 7:43 AM, Simon Peyton Jones
<simonpj at microsoft.com> wrote:

> An implication is that GHC is free to introduce new warnings X into -Wall.   Indeed doing so would be good, because the warning X might later move into the default set.  Indeed for such warnings, adding a "PS: this warning will become the default in GHC 9.2" might be a useful way to signal the upcoming change.  Then you can use -Wall and look for any "PS" indicators.

Yep. In general I think we don't know how _much_ noise a warning will
create until it makes it into the wild, so just as with other new
features its good to give them a bit of a "dry run" before deciding
that they come "by default."

> You don?t give a rationale for (2) but I think you intend that if someone wants to add -Wno-X when GHC introduces X in 9.0, you don't want GHC 8.6 to fall over.  Worth articulating the rationale.

Yes, that's exactly the rationale. It doesn't help us short term, but
longer term it should let users fiddle with warning flags more freely.

I think the general issue with three releases is not whether or not
GHC introduces warnings and at what pace, but that certain _types_ of
warnings (in particular redundancies, be they constraints, imports,
etc) will fire on entirely desirable code due to certain migration
paths. Most of the tricks we developed for backwards-compatible
migrations essentially depend on certain redundancies in code for a
period. Those can't be removed without hurting backwards-compatibility
of code, but their presence also induces warnings.

So as a whole "warning freeness" and "backwards compatible migrations"
become increasingly at odds with one another.

A full refactor of our warning sets would probably help in this
regard, so that the default advice could be "good code is -Wlint clean
but not necessarily -Wpedantic clean". Or even "is clean under
-Wpedantic -Wno-redundancies".

--Gershom

>
> | -----Original Message-----
> | From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
> | bounces at haskell.org] On Behalf Of Gershom B
> | Sent: 13 January 2016 02:20
> | To: GHC users <glasgow-haskell-users at haskell.org>; ghc-devs at haskell.org;
> | Edward Kmett <ekmett at gmail.com>; Herbert Valerio Riedel <hvr at gnu.org>; Simon
> | Marlow <marlowsd at gmail.com>
> | Subject: Re: Warnings, -Wall, and versioning policy
> |
> | Hi Simon. I think you raise important issues here, although I believe you?re
> | mistaken in one regard. Hackage rejects -Werror but I don?t think it rejects
> | -Wall.
> |
> |  What I?d suggest is perhaps the following.
> |
> | 1) The libraries committee put forward -Wall cleanliness as an _aspirational
> | goal_ rather than a final product, noting that the actual cleanliness might
> | be with regards to `-Wall -Wno-foo -Wno-bar``.
> |
> | 2) GHC _change its code_ so that `ghc -Wno-wat` yields a _warning_ rather
> | than an _error_ on `-W` followed by an unrecognized string.
> |
> | 3) No warning flags be introduced into the _default_ set without at least a
> | few releases in some other set such as `-Wall`.
> |
> | We may also want to try to maintain a ?best practices? example cabal file
> | that shows how one can build with additional warnings under a ?dev? flag, and
> | with fewer warnings otherwise ? so that the noise inflicted on package devs
> | under their builds doesn?t get inflicted on all end users, and even perhaps
> | with different warning flags per ghc version flag.
> |
> | I think this will respect the concerns of people that like to use `-Wall`,
> | want to have relatively warning clean code, and want to have some degree of
> | backwards compatibility (which is not an unreasonable combination in my
> | opinion).
> |
> | Some related
> | discussion: https://ghc.haskell.org/trac/ghc/ticket/11370 and https://ghc.has
> | kell.org/trac/ghc/wiki/Design/Warnings
> |
> | Cheers,
> | Gershom
> |
> |
> | On January 12, 2016 at 11:18:57 AM, Simon Marlow (marlowsd at gmail.com) wrote:
> | > Hi folks,
> | >
> | > We haven't described what guarantees GHC provides with respect to -Wall
> | > behaviour across versions, and as a result there are some differing
> | > expectations around this. It came up in this weeks' GHC meeting, so we
> | > thought it would be a good idea to state the policy explicitly. Here it is:
> | >
> | > We guarantee that code that compiles with no warnings with -Wall
> | > ("Wall-clean") and a particular GHC version, on a particular
> | > platform, will be Wall-clean with future minor releases of the same
> | > major GHC version on the same platform.
> | >
> | > (we plan to put this text in the User's Guide for future releases)
> | >
> | > There are no other guarantees. In particular:
> | > - In a new major release, GHC may introduce new warnings into -Wall,
> | > and/or change the meaning of existing warnings such that they trigger
> | > (or not) under different conditions.
> | > - GHC may generate different warnings on different platforms. (examples
> | > of this are -fwarn-overflowed-literals and
> | > -fwarn-unsupported-calling-conventions)
> | >
> | > Some rationale:
> | > - We consider any change to the language that GHC accepts to be a
> | > potentially code-breaking change, and subject to careful scrutiny. To
> | > extend this to warnings would be a *lot* of work, and would make it
> | > really difficult to introduce new warnings and improve the existing ones.
> | > - Warnings can be based on analyses that can change in accuracy over
> | > time. The -fwarn-unused-imports warning has changed a lot in what it
> | > rejects, for example.
> | > - We often introduce new warnings that naturally belong in -Wall. If
> | > -Wall was required to be a fixed point, we would have to start
> | > introducing new flags, and versioning, etc. and even keep the old
> | > implementation of warnings when they change. It would get really messy.
> | >
> | > There are some consequences to this. -Wall -Werror is useful for
> | > keeping your code warning-clean when developing, but shipping code with
> | > these options turned on in the build system is asking for trouble when
> | > building your code with different GHC versions and platforms. Keep
> | > those options for development only. Hackage already rejects packages
> | > that include -Wall for this reason.
> | >
> | > One reason we're raising this now is that it causes problems for the
> | > 3-release policy
> | >
> | (https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fprime.haske
> | ll.org%2fwiki%2fLibraries%2f3-Release-
> | Policy&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c5d13dce17e0b47a80263
> | 08d31bc02832%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=KzdY%2bG8jP8ofztNpN
> | khKGyB5PVW1XUWbw2lCQqdSNmc%3d) which
> | > requires that it be possible to write code that is Wall-clean with 3
> | > major releases of GHC. GHC itself doesn't guarantee this, so it might
> | > be hard for the core libraries committee to provide this guarantee. I
> | > suggest this requirement be dropped from the policy.
> | >
> | > Cheers,
> | > Simon
> | > _______________________________________________
> | > Glasgow-haskell-users mailing list
> | > Glasgow-haskell-users at haskell.org
> | >
> | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.
> | org%2fcgi-bin%2fmailman%2flistinfo%2fglasgow-haskell-
> | users&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c5d13dce17e0b47a802630
> | 8d31bc02832%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=f395AsIaHpKb8S9z4CAo
> | qfGhiDxa5tzQUo8Sm5%2bgKPQ%3d
> | >
> |
> | _______________________________________________
> | Glasgow-haskell-users mailing list
> | Glasgow-haskell-users at haskell.org
> | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.
> | org%2fcgi-bin%2fmailman%2flistinfo%2fglasgow-haskell-
> | users%0a&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c5d13dce17e0b47a802
> | 6308d31bc02832%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=6snGzNQuPSFVsZ2SY
> | fAxdSvo%2fjCOXvlq6cwzQM0L6iY%3d

From simonpj at microsoft.com  Wed Jan 13 21:42:11 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 13 Jan 2016 21:42:11 +0000
Subject: Warnings, -Wall, and versioning policy
In-Reply-To: <CAM8RHpELBHbsuif+qZerQYRPrcjRaRB74cviOnCFUybLqr5QSA@mail.gmail.com>
References: <56952766.2000505@gmail.com>
 <etPan.5695b47e.25d11c39.241@mbp.local>
 <f38ee6ffa3bb4fa0b4b986150ffab707@DB4PR30MB030.064d.mgd.msft.net>
 <CAM8RHpELBHbsuif+qZerQYRPrcjRaRB74cviOnCFUybLqr5QSA@mail.gmail.com>
Message-ID: <9058175ec0b04d75bf896bc98da524a8@DB4PR30MB030.064d.mgd.msft.net>

OK.  When this thread comes to a conclusion, can someone write it down; update the 3-release policy; and say what changes you want in GHC?

Thanks

Simon

| -----Original Message-----
| From: Gershom B [mailto:gershomb at gmail.com]
| Sent: 13 January 2016 18:18
| To: Simon Peyton Jones <simonpj at microsoft.com>
| Cc: GHC users <glasgow-haskell-users at haskell.org>; ghc-devs at haskell.org;
| Edward Kmett <ekmett at gmail.com>; Herbert Valerio Riedel <hvr at gnu.org>; Simon
| Marlow <marlowsd at gmail.com>
| Subject: Re: Warnings, -Wall, and versioning policy
| 
| On Wed, Jan 13, 2016 at 7:43 AM, Simon Peyton Jones
| <simonpj at microsoft.com> wrote:
| 
| > An implication is that GHC is free to introduce new warnings X into -Wall.
| Indeed doing so would be good, because the warning X might later move into
| the default set.  Indeed for such warnings, adding a "PS: this warning will
| become the default in GHC 9.2" might be a useful way to signal the upcoming
| change.  Then you can use -Wall and look for any "PS" indicators.
| 
| Yep. In general I think we don't know how _much_ noise a warning will
| create until it makes it into the wild, so just as with other new
| features its good to give them a bit of a "dry run" before deciding
| that they come "by default."
| 
| > You don?t give a rationale for (2) but I think you intend that if someone
| wants to add -Wno-X when GHC introduces X in 9.0, you don't want GHC 8.6 to
| fall over.  Worth articulating the rationale.
| 
| Yes, that's exactly the rationale. It doesn't help us short term, but
| longer term it should let users fiddle with warning flags more freely.
| 
| I think the general issue with three releases is not whether or not
| GHC introduces warnings and at what pace, but that certain _types_ of
| warnings (in particular redundancies, be they constraints, imports,
| etc) will fire on entirely desirable code due to certain migration
| paths. Most of the tricks we developed for backwards-compatible
| migrations essentially depend on certain redundancies in code for a
| period. Those can't be removed without hurting backwards-compatibility
| of code, but their presence also induces warnings.
| 
| So as a whole "warning freeness" and "backwards compatible migrations"
| become increasingly at odds with one another.
| 
| A full refactor of our warning sets would probably help in this
| regard, so that the default advice could be "good code is -Wlint clean
| but not necessarily -Wpedantic clean". Or even "is clean under
| -Wpedantic -Wno-redundancies".
| 
| --Gershom
| 
| >
| > | -----Original Message-----
| > | From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
| > | bounces at haskell.org] On Behalf Of Gershom B
| > | Sent: 13 January 2016 02:20
| > | To: GHC users <glasgow-haskell-users at haskell.org>; ghc-devs at haskell.org;
| > | Edward Kmett <ekmett at gmail.com>; Herbert Valerio Riedel <hvr at gnu.org>;
| Simon
| > | Marlow <marlowsd at gmail.com>
| > | Subject: Re: Warnings, -Wall, and versioning policy
| > |
| > | Hi Simon. I think you raise important issues here, although I believe
| you?re
| > | mistaken in one regard. Hackage rejects -Werror but I don?t think it
| rejects
| > | -Wall.
| > |
| > |  What I?d suggest is perhaps the following.
| > |
| > | 1) The libraries committee put forward -Wall cleanliness as an
| _aspirational
| > | goal_ rather than a final product, noting that the actual cleanliness
| might
| > | be with regards to `-Wall -Wno-foo -Wno-bar``.
| > |
| > | 2) GHC _change its code_ so that `ghc -Wno-wat` yields a _warning_ rather
| > | than an _error_ on `-W` followed by an unrecognized string.
| > |
| > | 3) No warning flags be introduced into the _default_ set without at least
| a
| > | few releases in some other set such as `-Wall`.
| > |
| > | We may also want to try to maintain a ?best practices? example cabal file
| > | that shows how one can build with additional warnings under a ?dev? flag,
| and
| > | with fewer warnings otherwise ? so that the noise inflicted on package
| devs
| > | under their builds doesn?t get inflicted on all end users, and even
| perhaps
| > | with different warning flags per ghc version flag.
| > |
| > | I think this will respect the concerns of people that like to use `-
| Wall`,
| > | want to have relatively warning clean code, and want to have some degree
| of
| > | backwards compatibility (which is not an unreasonable combination in my
| > | opinion).
| > |
| > | Some related
| > | discussion: https://ghc.haskell.org/trac/ghc/ticket/11370 and
| https://ghc.has
| > |
| https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fkell.org%2ft
| rac%2fghc%2fwiki%2fDesign%2fWarnings&data=01%7c01%7csimonpj%40064d.mgd.micros
| oft.com%7c9de7c65d89a84408f00808d31c45e258%7c72f988bf86f141af91ab2d7cd011db47
| %7c1&sdata=BE9pq5knT%2fWTxOfrtEYefqDC2qMEQP%2b9fbcgvs%2f2qr0%3d | Cheers,
| > | Gershom
| > |
| > |
| > | On January 12, 2016 at 11:18:57 AM, Simon Marlow (marlowsd at gmail.com)
| wrote:
| > | > Hi folks,
| > | >
| > | > We haven't described what guarantees GHC provides with respect to -Wall
| > | > behaviour across versions, and as a result there are some differing
| > | > expectations around this. It came up in this weeks' GHC meeting, so we
| > | > thought it would be a good idea to state the policy explicitly. Here it
| is:
| > | >
| > | > We guarantee that code that compiles with no warnings with -Wall
| > | > ("Wall-clean") and a particular GHC version, on a particular
| > | > platform, will be Wall-clean with future minor releases of the same
| > | > major GHC version on the same platform.
| > | >
| > | > (we plan to put this text in the User's Guide for future releases)
| > | >
| > | > There are no other guarantees. In particular:
| > | > - In a new major release, GHC may introduce new warnings into -Wall,
| > | > and/or change the meaning of existing warnings such that they trigger
| > | > (or not) under different conditions.
| > | > - GHC may generate different warnings on different platforms. (examples
| > | > of this are -fwarn-overflowed-literals and
| > | > -fwarn-unsupported-calling-conventions)
| > | >
| > | > Some rationale:
| > | > - We consider any change to the language that GHC accepts to be a
| > | > potentially code-breaking change, and subject to careful scrutiny. To
| > | > extend this to warnings would be a *lot* of work, and would make it
| > | > really difficult to introduce new warnings and improve the existing
| ones.
| > | > - Warnings can be based on analyses that can change in accuracy over
| > | > time. The -fwarn-unused-imports warning has changed a lot in what it
| > | > rejects, for example.
| > | > - We often introduce new warnings that naturally belong in -Wall. If
| > | > -Wall was required to be a fixed point, we would have to start
| > | > introducing new flags, and versioning, etc. and even keep the old
| > | > implementation of warnings when they change. It would get really messy.
| > | >
| > | > There are some consequences to this. -Wall -Werror is useful for
| > | > keeping your code warning-clean when developing, but shipping code with
| > | > these options turned on in the build system is asking for trouble when
| > | > building your code with different GHC versions and platforms. Keep
| > | > those options for development only. Hackage already rejects packages
| > | > that include -Wall for this reason.
| > | >
| > | > One reason we're raising this now is that it causes problems for the
| > | > 3-release policy
| > | >
| > |
| (https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fprime.haske
| > | ll.org%2fwiki%2fLibraries%2f3-Release-
| > |
| Policy&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c5d13dce17e0b47a80263
| > |
| 08d31bc02832%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=KzdY%2bG8jP8ofztNpN
| > | khKGyB5PVW1XUWbw2lCQqdSNmc%3d) which
| > | > requires that it be possible to write code that is Wall-clean with 3
| > | > major releases of GHC. GHC itself doesn't guarantee this, so it might
| > | > be hard for the core libraries committee to provide this guarantee. I
| > | > suggest this requirement be dropped from the policy.
| > | >
| > | > Cheers,
| > | > Simon
| > | > _______________________________________________
| > | > Glasgow-haskell-users mailing list
| > | > Glasgow-haskell-users at haskell.org
| > | >
| > |
| https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.
| > | org%2fcgi-bin%2fmailman%2flistinfo%2fglasgow-haskell-
| > |
| users&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c5d13dce17e0b47a802630
| > |
| 8d31bc02832%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=f395AsIaHpKb8S9z4CAo
| > | qfGhiDxa5tzQUo8Sm5%2bgKPQ%3d
| > | >
| > |
| > | _______________________________________________
| > | Glasgow-haskell-users mailing list
| > | Glasgow-haskell-users at haskell.org
| > |
| https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.
| > | org%2fcgi-bin%2fmailman%2flistinfo%2fglasgow-haskell-
| > |
| users%0a&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c5d13dce17e0b47a802
| > |
| 6308d31bc02832%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=6snGzNQuPSFVsZ2SY
| > | fAxdSvo%2fjCOXvlq6cwzQM0L6iY%3d

From ekmett at gmail.com  Sun Jan 17 05:24:48 2016
From: ekmett at gmail.com (Edward Kmett)
Date: Sun, 17 Jan 2016 00:24:48 -0500
Subject: =?UTF-8?Q?Re=3A_suppress_warning_=22Defined_but_not_used=3A_type_var?=
 =?UTF-8?Q?iable_=E2=80=98x=E2=80=99=22_in_GHC=2D8=2E0?=
In-Reply-To: <alpine.DEB.2.02.1601112011410.8884@sputnik>
References: <alpine.DEB.2.02.1601092352010.8054@sputnik>
 <CAHYVw0w7R28G+BTUZXHEUrj1xYAu+ywsY_a1haPNQY=3sy3FCA@mail.gmail.com>
 <alpine.DEB.2.02.1601100031270.8054@sputnik>
 <DCB10CB2-ABBA-42B0-B1AE-16B986233FC1@cis.upenn.edu>
 <alpine.DEB.2.02.1601112011410.8884@sputnik>
Message-ID: <CAJumaK_Jp4B3NRbfLTwwJ6J9UWVN-d0bQYcs-eAwvkuzkOiL+w@mail.gmail.com>

As a data point I now get thousands of occurrences of this warning across
my packages.

It is quite annoying.

class Foo a where
  type Bar a

instance Foo [a] where
  type Bar [a] = Int

is enough to trigger it.

And you can't turn it off by using _ as

instance Foo [_] where
  type Bar [_] = Int

isn't legal.

I've been avoiding it for now by using

  if impl(ghc >= 8)

    ghc-options: -fno-warn-unused-matches

but this is a pretty awful addition to this warning as it stands.
-Edward

On Mon, Jan 11, 2016 at 2:12 PM, Henning Thielemann <
lemming at henning-thielemann.de> wrote:

>
> On Mon, 11 Jan 2016, Richard Eisenberg wrote:
>
> On Jan 9, 2016, at 6:44 PM, Henning Thielemann <
>> lemming at henning-thielemann.de> wrote:
>>
>>>
>>> instance (Natural n) => Num.Integer (Un n) where
>>>    type Repr (Un _n) = Unary
>>>
>>>
>>> GHC-7.6.3 and GHC-7.4.2 complain:
>>>    Type indexes must match class instance head
>>>    Found `Un _n' but expected `Un n'
>>>    In the type synonym instance declaration for `Num.Repr'
>>>    In the instance declaration for `Num.Integer (Un n)'
>>>
>>>
>>> GHC-7.8.4, GHC-7.10.3 and GHC-8.0 are happy with the difference.
>>>
>>
>> I'm surprised this is accepted at all. Looks like hogwash to me. I think
>> you should post a bug report.
>>
>
> Ok, but then GHC must not warn about the unused argument of Repr.
>
> _______________________________________________
> 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/20160117/00911c61/attachment.html>

From xichekolas at gmail.com  Sun Jan 17 08:16:09 2016
From: xichekolas at gmail.com (Andrew Farmer)
Date: Sun, 17 Jan 2016 00:16:09 -0800
Subject: =?UTF-8?Q?Re=3A_suppress_warning_=22Defined_but_not_used=3A_type_var?=
 =?UTF-8?Q?iable_=E2=80=98x=E2=80=99=22_in_GHC=2D8=2E0?=
In-Reply-To: <CAJumaK_Jp4B3NRbfLTwwJ6J9UWVN-d0bQYcs-eAwvkuzkOiL+w@mail.gmail.com>
References: <alpine.DEB.2.02.1601092352010.8054@sputnik>
 <CAHYVw0w7R28G+BTUZXHEUrj1xYAu+ywsY_a1haPNQY=3sy3FCA@mail.gmail.com>
 <alpine.DEB.2.02.1601100031270.8054@sputnik>
 <DCB10CB2-ABBA-42B0-B1AE-16B986233FC1@cis.upenn.edu>
 <alpine.DEB.2.02.1601112011410.8884@sputnik>
 <CAJumaK_Jp4B3NRbfLTwwJ6J9UWVN-d0bQYcs-eAwvkuzkOiL+w@mail.gmail.com>
Message-ID: <CAJ14jR_sQ5Sab=pfSdH=zVbCBcq_oJ1_tY3D+E+5OuzSgu_1rw@mail.gmail.com>

Can't you just:

instance Foo [a] where
  type Bar [_a] = Int

(At least I think I did that somewhere...)
On Jan 16, 2016 9:24 PM, "Edward Kmett" <ekmett at gmail.com> wrote:

> As a data point I now get thousands of occurrences of this warning across
> my packages.
>
> It is quite annoying.
>
> class Foo a where
>   type Bar a
>
> instance Foo [a] where
>   type Bar [a] = Int
>
> is enough to trigger it.
>
> And you can't turn it off by using _ as
>
> instance Foo [_] where
>   type Bar [_] = Int
>
> isn't legal.
>
> I've been avoiding it for now by using
>
>   if impl(ghc >= 8)
>
>     ghc-options: -fno-warn-unused-matches
>
> but this is a pretty awful addition to this warning as it stands.
> -Edward
>
> On Mon, Jan 11, 2016 at 2:12 PM, Henning Thielemann <
> lemming at henning-thielemann.de> wrote:
>
>>
>> On Mon, 11 Jan 2016, Richard Eisenberg wrote:
>>
>> On Jan 9, 2016, at 6:44 PM, Henning Thielemann <
>>> lemming at henning-thielemann.de> wrote:
>>>
>>>>
>>>> instance (Natural n) => Num.Integer (Un n) where
>>>>    type Repr (Un _n) = Unary
>>>>
>>>>
>>>> GHC-7.6.3 and GHC-7.4.2 complain:
>>>>    Type indexes must match class instance head
>>>>    Found `Un _n' but expected `Un n'
>>>>    In the type synonym instance declaration for `Num.Repr'
>>>>    In the instance declaration for `Num.Integer (Un n)'
>>>>
>>>>
>>>> GHC-7.8.4, GHC-7.10.3 and GHC-8.0 are happy with the difference.
>>>>
>>>
>>> I'm surprised this is accepted at all. Looks like hogwash to me. I think
>>> you should post a bug report.
>>>
>>
>> Ok, but then GHC must not warn about the unused argument of Repr.
>>
>> _______________________________________________
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20160117/73217512/attachment.html>

From ekmett at gmail.com  Sun Jan 17 14:44:12 2016
From: ekmett at gmail.com (Edward Kmett)
Date: Sun, 17 Jan 2016 09:44:12 -0500
Subject: =?UTF-8?Q?Re=3A_suppress_warning_=22Defined_but_not_used=3A_type_var?=
 =?UTF-8?Q?iable_=E2=80=98x=E2=80=99=22_in_GHC=2D8=2E0?=
In-Reply-To: <CAJ14jR_sQ5Sab=pfSdH=zVbCBcq_oJ1_tY3D+E+5OuzSgu_1rw@mail.gmail.com>
References: <alpine.DEB.2.02.1601092352010.8054@sputnik>
 <CAHYVw0w7R28G+BTUZXHEUrj1xYAu+ywsY_a1haPNQY=3sy3FCA@mail.gmail.com>
 <alpine.DEB.2.02.1601100031270.8054@sputnik>
 <DCB10CB2-ABBA-42B0-B1AE-16B986233FC1@cis.upenn.edu>
 <alpine.DEB.2.02.1601112011410.8884@sputnik>
 <CAJumaK_Jp4B3NRbfLTwwJ6J9UWVN-d0bQYcs-eAwvkuzkOiL+w@mail.gmail.com>
 <CAJ14jR_sQ5Sab=pfSdH=zVbCBcq_oJ1_tY3D+E+5OuzSgu_1rw@mail.gmail.com>
Message-ID: <CAJumaK9Ba8-Jqu-q7ypc8Qc1aDni6D4pnMTCA8_ZSDEiEDo4Dg@mail.gmail.com>

No, the type instance must match the class heading.

I *can* use

instance Foo [_a] where
  type Bar [_a] = Int
  whatever = ... where
    bar :: _a -> Int
    bar = ...

but that is a needlessly messy thing to request of every package everywhere.

The arguments being pattern matched in a class associated type aren't
really just bindings, they reference the surrounding context and so
shouldn't be treated the same as the basic type family case.

It isn't just the class associated type being mangled, it is every type
variable that comes from the instance head in the entire body of every
instance that happens to have a class associated type in it.

Note that in the example above I added another ScopedTypeVariables
reference to the same parameter, but it _also_ must be mangled despite
having absolutely nothing to do with the class associated type.

The existing convention has worked since 6.10 or so, when all of this stuff
was invented in the first place, and the new state of affairs is clearly
worse.

-Edward

On Sun, Jan 17, 2016 at 3:16 AM, Andrew Farmer <xichekolas at gmail.com> wrote:

> Can't you just:
>
> instance Foo [a] where
>   type Bar [_a] = Int
>
> (At least I think I did that somewhere...)
> On Jan 16, 2016 9:24 PM, "Edward Kmett" <ekmett at gmail.com> wrote:
>
>> As a data point I now get thousands of occurrences of this warning across
>> my packages.
>>
>> It is quite annoying.
>>
>> class Foo a where
>>   type Bar a
>>
>> instance Foo [a] where
>>   type Bar [a] = Int
>>
>> is enough to trigger it.
>>
>> And you can't turn it off by using _ as
>>
>> instance Foo [_] where
>>   type Bar [_] = Int
>>
>> isn't legal.
>>
>> I've been avoiding it for now by using
>>
>>   if impl(ghc >= 8)
>>
>>     ghc-options: -fno-warn-unused-matches
>>
>> but this is a pretty awful addition to this warning as it stands.
>> -Edward
>>
>> On Mon, Jan 11, 2016 at 2:12 PM, Henning Thielemann <
>> lemming at henning-thielemann.de> wrote:
>>
>>>
>>> On Mon, 11 Jan 2016, Richard Eisenberg wrote:
>>>
>>> On Jan 9, 2016, at 6:44 PM, Henning Thielemann <
>>>> lemming at henning-thielemann.de> wrote:
>>>>
>>>>>
>>>>> instance (Natural n) => Num.Integer (Un n) where
>>>>>    type Repr (Un _n) = Unary
>>>>>
>>>>>
>>>>> GHC-7.6.3 and GHC-7.4.2 complain:
>>>>>    Type indexes must match class instance head
>>>>>    Found `Un _n' but expected `Un n'
>>>>>    In the type synonym instance declaration for `Num.Repr'
>>>>>    In the instance declaration for `Num.Integer (Un n)'
>>>>>
>>>>>
>>>>> GHC-7.8.4, GHC-7.10.3 and GHC-8.0 are happy with the difference.
>>>>>
>>>>
>>>> I'm surprised this is accepted at all. Looks like hogwash to me. I
>>>> think you should post a bug report.
>>>>
>>>
>>> Ok, but then GHC must not warn about the unused argument of Repr.
>>>
>>> _______________________________________________
>>> 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
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20160117/0b769f0d/attachment.html>

From ekmett at gmail.com  Sun Jan 17 14:45:01 2016
From: ekmett at gmail.com (Edward Kmett)
Date: Sun, 17 Jan 2016 09:45:01 -0500
Subject: =?UTF-8?Q?Re=3A_suppress_warning_=22Defined_but_not_used=3A_type_var?=
 =?UTF-8?Q?iable_=E2=80=98x=E2=80=99=22_in_GHC=2D8=2E0?=
In-Reply-To: <CAJumaK9Ba8-Jqu-q7ypc8Qc1aDni6D4pnMTCA8_ZSDEiEDo4Dg@mail.gmail.com>
References: <alpine.DEB.2.02.1601092352010.8054@sputnik>
 <CAHYVw0w7R28G+BTUZXHEUrj1xYAu+ywsY_a1haPNQY=3sy3FCA@mail.gmail.com>
 <alpine.DEB.2.02.1601100031270.8054@sputnik>
 <DCB10CB2-ABBA-42B0-B1AE-16B986233FC1@cis.upenn.edu>
 <alpine.DEB.2.02.1601112011410.8884@sputnik>
 <CAJumaK_Jp4B3NRbfLTwwJ6J9UWVN-d0bQYcs-eAwvkuzkOiL+w@mail.gmail.com>
 <CAJ14jR_sQ5Sab=pfSdH=zVbCBcq_oJ1_tY3D+E+5OuzSgu_1rw@mail.gmail.com>
 <CAJumaK9Ba8-Jqu-q7ypc8Qc1aDni6D4pnMTCA8_ZSDEiEDo4Dg@mail.gmail.com>
Message-ID: <CAJumaK87VqS6cXGPkF1zAVrLYUYG7uZ1MAfL8GuoFk8ytM5-MQ@mail.gmail.com>

Moreover those _'d type variables would infect all of our haddocks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20160117/22d4f908/attachment.html>

From ollie at ocharles.org.uk  Sun Jan 17 22:20:08 2016
From: ollie at ocharles.org.uk (Oliver Charles)
Date: Sun, 17 Jan 2016 22:20:08 +0000
Subject: =?UTF-8?Q?Re=3A_suppress_warning_=22Defined_but_not_used=3A_type_var?=
 =?UTF-8?Q?iable_=E2=80=98x=E2=80=99=22_in_GHC=2D8=2E0?=
In-Reply-To: <CAJumaK87VqS6cXGPkF1zAVrLYUYG7uZ1MAfL8GuoFk8ytM5-MQ@mail.gmail.com>
References: <alpine.DEB.2.02.1601092352010.8054@sputnik>
 <CAHYVw0w7R28G+BTUZXHEUrj1xYAu+ywsY_a1haPNQY=3sy3FCA@mail.gmail.com>
 <alpine.DEB.2.02.1601100031270.8054@sputnik>
 <DCB10CB2-ABBA-42B0-B1AE-16B986233FC1@cis.upenn.edu>
 <alpine.DEB.2.02.1601112011410.8884@sputnik>
 <CAJumaK_Jp4B3NRbfLTwwJ6J9UWVN-d0bQYcs-eAwvkuzkOiL+w@mail.gmail.com>
 <CAJ14jR_sQ5Sab=pfSdH=zVbCBcq_oJ1_tY3D+E+5OuzSgu_1rw@mail.gmail.com>
 <CAJumaK9Ba8-Jqu-q7ypc8Qc1aDni6D4pnMTCA8_ZSDEiEDo4Dg@mail.gmail.com>
 <CAJumaK87VqS6cXGPkF1zAVrLYUYG7uZ1MAfL8GuoFk8ytM5-MQ@mail.gmail.com>
Message-ID: <CAGRp5RkcSoDS728Zit6P+Y7m6NQmHwbyCO-5rvV_5-2_4k7qjQ@mail.gmail.com>

Inferred types and errors too, I would imagine.

On Sun, 17 Jan 2016 2:45 pm Edward Kmett <ekmett at gmail.com> wrote:

> Moreover those _'d type variables would infect all of our haddocks.
> _______________________________________________
> 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/20160117/e396d068/attachment.html>

From simonpj at microsoft.com  Mon Jan 18 09:57:21 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 18 Jan 2016 09:57:21 +0000
Subject: =?utf-8?B?UkU6IHN1cHByZXNzIHdhcm5pbmcgIkRlZmluZWQgYnV0IG5vdCB1c2VkOiB0?=
 =?utf-8?B?eXBlIHZhcmlhYmxlIOKAmHjigJkiIGluIEdIQy04LjA=?=
In-Reply-To: <CAJumaK9Ba8-Jqu-q7ypc8Qc1aDni6D4pnMTCA8_ZSDEiEDo4Dg@mail.gmail.com>
References: <alpine.DEB.2.02.1601092352010.8054@sputnik>
 <CAHYVw0w7R28G+BTUZXHEUrj1xYAu+ywsY_a1haPNQY=3sy3FCA@mail.gmail.com>
 <alpine.DEB.2.02.1601100031270.8054@sputnik>
 <DCB10CB2-ABBA-42B0-B1AE-16B986233FC1@cis.upenn.edu>
 <alpine.DEB.2.02.1601112011410.8884@sputnik>
 <CAJumaK_Jp4B3NRbfLTwwJ6J9UWVN-d0bQYcs-eAwvkuzkOiL+w@mail.gmail.com>
 <CAJ14jR_sQ5Sab=pfSdH=zVbCBcq_oJ1_tY3D+E+5OuzSgu_1rw@mail.gmail.com>
 <CAJumaK9Ba8-Jqu-q7ypc8Qc1aDni6D4pnMTCA8_ZSDEiEDo4Dg@mail.gmail.com>
Message-ID: <874e9f4bcce14e39a5aebbe8d7aa3949@AM3PR30MB019.064d.mgd.msft.net>

I have created not one but three tickets arising from this thread:


?         https://ghc.haskell.org/trac/ghc/ticket/11449

?         https://ghc.haskell.org/trac/ghc/ticket/11450

?         https://ghc.haskell.org/trac/ghc/ticket/11451

I?d love comments on them: which of the three matter most to you folk?  The first also involves a flag-naming question.

Simon

From: Glasgow-haskell-users [mailto:glasgow-haskell-users-bounces at haskell.org] On Behalf Of Edward Kmett
Sent: 17 January 2016 14:44
To: Andrew Farmer <xichekolas at gmail.com>
Cc: Henning Thielemann <lemming at henning-thielemann.de>; glasgow-haskell-users at haskell.org
Subject: Re: suppress warning "Defined but not used: type variable ?x?" in GHC-8.0

No, the type instance must match the class heading.

I can use

instance Foo [_a] where
  type Bar [_a] = Int
  whatever = ... where
    bar :: _a -> Int
    bar = ...

but that is a needlessly messy thing to request of every package everywhere.

The arguments being pattern matched in a class associated type aren't really just bindings, they reference the surrounding context and so shouldn't be treated the same as the basic type family case.

It isn't just the class associated type being mangled, it is every type variable that comes from the instance head in the entire body of every instance that happens to have a class associated type in it.

Note that in the example above I added another ScopedTypeVariables reference to the same parameter, but it _also_ must be mangled despite having absolutely nothing to do with the class associated type.

The existing convention has worked since 6.10 or so, when all of this stuff was invented in the first place, and the new state of affairs is clearly worse.

-Edward

On Sun, Jan 17, 2016 at 3:16 AM, Andrew Farmer <xichekolas at gmail.com<mailto:xichekolas at gmail.com>> wrote:

Can't you just:

instance Foo [a] where
  type Bar [_a] = Int

(At least I think I did that somewhere...)
On Jan 16, 2016 9:24 PM, "Edward Kmett" <ekmett at gmail.com<mailto:ekmett at gmail.com>> wrote:
As a data point I now get thousands of occurrences of this warning across my packages.

It is quite annoying.

class Foo a where
  type Bar a

instance Foo [a] where
  type Bar [a] = Int

is enough to trigger it.

And you can't turn it off by using _ as

instance Foo [_] where
  type Bar [_] = Int

isn't legal.

I've been avoiding it for now by using

  if impl(ghc >= 8)

    ghc-options: -fno-warn-unused-matches

but this is a pretty awful addition to this warning as it stands.
-Edward

On Mon, Jan 11, 2016 at 2:12 PM, Henning Thielemann <lemming at henning-thielemann.de<mailto:lemming at henning-thielemann.de>> wrote:

On Mon, 11 Jan 2016, Richard Eisenberg wrote:
On Jan 9, 2016, at 6:44 PM, Henning Thielemann <lemming at henning-thielemann.de<mailto:lemming at henning-thielemann.de>> wrote:

instance (Natural n) => Num.Integer (Un n) where
   type Repr (Un _n) = Unary


GHC-7.6.3 and GHC-7.4.2 complain:
   Type indexes must match class instance head
   Found `Un _n' but expected `Un n'
   In the type synonym instance declaration for `Num.Repr'
   In the instance declaration for `Num.Integer (Un n)'


GHC-7.8.4, GHC-7.10.3 and GHC-8.0 are happy with the difference.

I'm surprised this is accepted at all. Looks like hogwash to me. I think you should post a bug report.

Ok, but then GHC must not warn about the unused argument of Repr.

_______________________________________________
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://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.org%2fcgi-bin%2fmailman%2flistinfo%2fglasgow-haskell-users&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c560da21ad3be4ab474ca08d31f4cab95%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=SUPkAvfyDQt84m9WwO%2b0z%2fDVA5nWDp7u28%2bkOXt0d94%3d>


_______________________________________________
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://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.org%2fcgi-bin%2fmailman%2flistinfo%2fglasgow-haskell-users&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c560da21ad3be4ab474ca08d31f4cab95%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=SUPkAvfyDQt84m9WwO%2b0z%2fDVA5nWDp7u28%2bkOXt0d94%3d>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20160118/846354ab/attachment-0001.html>

From philip.dexter at gmail.com  Thu Jan 21 23:14:57 2016
From: philip.dexter at gmail.com (Philip Dexter)
Date: Thu, 21 Jan 2016 18:14:57 -0500 (EST)
Subject: Were usage types ever in GHC
Message-ID: <alpine.LNX.2.20.1601211802030.27052@arch-satellite>

I've recently been digging around to see if there has ever been any 
attempt to perform any sort of data reuse optimization in functional 
languages.

Along with many other papers, I've come across `Once upon a type' as well 
as `Once upon a polymorphic type'. They both mention a desire to include a 
similar system in GHC.

Then in `Playing by the rules: rewriting as a practical optimization 
technique in GHC' I see usage types mentioned in section 5.3:

"""
To express this, GHC adds extra usage type arguments to map, both at its 
definition and at its call sites. Once this is done, a specialised version 
of map can be compiled for the case when the usage-type argument is 
?once?, and a rule generated to match such calls, in exactly the same way 
as for specialising overloading.
"""

I can't tell if this is simply a hypothetical optimization or if this 
really happened at one point in the history of GHC.

I was hoping somebody could shed some light on this topic

Was a usage type system or something similar (e.g. linear type system) 
ever present in GHC?

If it was then why was it taken out (unless I'm missing something, this 
optimization is not happening today)? I could guess at this and say that 
the gains weren't worth the overhead, but perhaps there's another reason.

If it was never present, why not? There was obviously at least some 
interest in this sort of optimization at some point in the Haskell 
community and I'd be curious as to why it was never tested in GHC.

Thanks!

Philip Dexter

From simonpj at microsoft.com  Fri Jan 22 17:01:22 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 22 Jan 2016 17:01:22 +0000
Subject: Were usage types ever in GHC
In-Reply-To: <alpine.LNX.2.20.1601211802030.27052@arch-satellite>
References: <alpine.LNX.2.20.1601211802030.27052@arch-satellite>
Message-ID: <9f1328cdfbf64606bffc15a10dff5e77@DB4PR30MB030.064d.mgd.msft.net>

Keith Wansbrough did implement his thesis work in a fork of GHC.  But (a) it was jolly complicated and pervasive, and (b) the performance improvements were not great.  It didn't pay its way. So we dropped it.  See his thesis, available here http://research.microsoft.com/en-us/um/people/simonpj/papers/papers.html

What we HAVE done (and is in GHC) is cardinality analysis. See "Higher order cardinality analysis in theory and practice"
http://research.microsoft.com/en-us/um/people/simonpj/papers/usage-types/usage.htm

Enjoy!

Simon
| -----Original Message-----
| From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
| bounces at haskell.org] On Behalf Of Philip Dexter
| Sent: 21 January 2016 23:15
| To: GHC Users List <glasgow-haskell-users at haskell.org>
| Subject: Were usage types ever in GHC
| 
| I've recently been digging around to see if there has ever been any
| attempt to perform any sort of data reuse optimization in functional
| languages.
| 
| Along with many other papers, I've come across `Once upon a type' as well
| as `Once upon a polymorphic type'. They both mention a desire to include a
| similar system in GHC.
| 
| Then in `Playing by the rules: rewriting as a practical optimization
| technique in GHC' I see usage types mentioned in section 5.3:
| 
| """
| To express this, GHC adds extra usage type arguments to map, both at its
| definition and at its call sites. Once this is done, a specialised version
| of map can be compiled for the case when the usage-type argument is
| ?once?, and a rule generated to match such calls, in exactly the same way
| as for specialising overloading.
| """
| 
| I can't tell if this is simply a hypothetical optimization or if this
| really happened at one point in the history of GHC.
| 
| I was hoping somebody could shed some light on this topic
| 
| Was a usage type system or something similar (e.g. linear type system)
| ever present in GHC?
| 
| If it was then why was it taken out (unless I'm missing something, this
| optimization is not happening today)? I could guess at this and say that
| the gains weren't worth the overhead, but perhaps there's another reason.
| 
| If it was never present, why not? There was obviously at least some
| interest in this sort of optimization at some point in the Haskell
| community and I'd be curious as to why it was never tested in GHC.
| 
| Thanks!
| 
| Philip Dexter

From ben at well-typed.com  Wed Jan 27 13:02:13 2016
From: ben at well-typed.com (Ben Gamari)
Date: Wed, 27 Jan 2016 14:02:13 +0100
Subject: GHC 8.0.1 plans
In-Reply-To: <874mdzdzn3.fsf@smart-cactus.org>
References: <874mdzdzn3.fsf@smart-cactus.org>
Message-ID: <87r3h3ch0q.fsf@smart-cactus.org>


tl;dr: The march towards 8.0.1 continues. Release candidate 2 will likely
       be cut late next week. If you have a ticket which you'd like to
       see addressed but suspect we aren't working on then please say so.


Hello again GHC-ers,

As you likely know, we are currently in the stabilization period of
GHC's 8.0.1 release. Release candidate 1 has been out for nearly two
weeks now and issues have been steadily trickling in.

The problems we've heard about thusfar have largely fallen into a few
broad categories,

  * OS X linker issues due to botched preparation of the first binary
    distribution (#11423)

  * pattern match checker performance. These we largely knew about prior
    to the release, although it has been surprising to see how easily
    one can wander into the new checker's performance abyss. (#11374,
    #11276, #11163, #11302, #11303, #11195)

  * Regressions due to visible type applications (#11329, #11458)

  * Issues uncovered by generalizations allowed under TypeInType
    (#11429, #11334, #11473, #11405, #11407, #11399)

  * Trouble caused by new warnings (#11370, #11316, #11474)

Since the release, there has been significant progress on many of these
fronts:

  * George Karachalias has been hard at work further improving the
    pattern checker. The result should have far more predictable
    performance characteristics at less cost in reasoning power.

  * Simon Peyton Jones has been squashing bugs at a furious rate,
    including a variety of long-standing issues (#11248, #11330 and many
    others)

  * Tamar Christina has added support for remote GHCi on Windows
    and resolved a long-standing linking issue (#11223, #11100)

  * A variety of limitations in our implementation of Typeable have been
    fixed (#11120) although there is still more to be done (#11334).

  * InjectiveTypeFamilies has been renamed to TypeFamiliesDependencies

  * Custom type errors are now more robust (#11391)

  * We now have a more conservative default warning set, as well as
    better mechanisms for managing warning changes in the future.
    (#11429, #11370)

  * A wide variety of miscellaneous bug-fixes have also been merged.

Given how much progress has been made, we approaching the point where we
can begin planning the next candidate. At this point the plan is to wait
until we have landed George's pattern checker rework, as this has been
one of the more visible issues in practice. This may be merged as early as
the latter half of next week. If this happens then we hope to have the
next release candidate out late next week.

In the interim we will continue to work on paring down the bug list,
focusing on the highest priority tickets listed on the 8.0.1 status
page. In particular, those with owners are most likely to be dealt with
soon. If you see a ticket which you would like to see addressed in 8.0.1
but is unowned or lower than "highest" priority, please bring this to
our attention.

Given the large amount of churn still being felt in the `ghc-8.0` branch
(with over 150 comments in the two weeks since -rc1) and the size of
some of the patches that have yet to land, it's unclear whether two
release candidates will be sufficient to ensure the stability of the
branch. Consequently, unless -rc2 yields a particularly small number of
new tickets it's likely that it will be followed by a third candidate
before the release.

As always, let us know if you have any questions or concerns about the
release process.

Thanks to everyone who has contributed to -rc1!

Cheers,

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