From yongqli at kerrmetric.com  Wed Apr  1 01:48:32 2015
From: yongqli at kerrmetric.com (Yongqian Li)
Date: Tue, 31 Mar 2015 18:48:32 -0700
Subject: Bug: GHC creates incorrect code which throws <<loop>>
Message-ID: <CAKF_vo7NH0oWd2jyRAUesq4z-PGzFoE2g07BfWW_TNdnYefs5w@mail.gmail.com>

Hi all,

I wanted to bring to your attention this bug,
https://ghc.haskell.org/trac/ghc/ticket/10218 , which I filed about
two days ago but hasn't gotten any replies to yet.


In my opinion, this is a rather serious bug since GHC is producing
incorrect code. While there is a workaround, it makes my program take
about 2 hours to compile.


Since reporting the bug, I've also seen "strange closure type"
exceptions, which I believe are also caused by this bug, although I do
not have a test case. Based on my limited understanding of GHC
internals, I suspect the problem lies in how type class dictionaries
are looked up at run time, as the problem disappears if GHC can fully
resolve the types.


Can others see if they can reproduce this bug? If there is any way I
can help, please let me know.


Sincerely,
Yongqian Li

From svenpanne at gmail.com  Wed Apr  1 06:57:00 2015
From: svenpanne at gmail.com (Sven Panne)
Date: Wed, 1 Apr 2015 08:57:00 +0200
Subject: GHC 7.10.1 html docs all flat?
In-Reply-To: <DUB131-W580CDF93A38CA0EF01E8C0C8F40@phx.gbl>
References: <DUB131-W580CDF93A38CA0EF01E8C0C8F40@phx.gbl>
Message-ID: <CANBN=mv1v0h49a58aaLgEk1YAts+NM1FeCUWNzP_2ZaHzsrwdg@mail.gmail.com>

2015-03-31 20:20 GMT+02:00 Randy Polen <randyhaskell at outlook.com>:
> [...] Just want to make sure this is what is expected, and then change the HP
> build code accordingly. [...]

Hmmm, unless there is a strong reason to change this into a flat
layout, I would propose to keep the docs hierarchical. I could
envision clashes and tooling problems with the flat layout, but I fail
to see why it should be better. To me, it just looks like a bug. If
it's not a bug, could somebody point me to the discussion regarding
the rationale behind the flat layout?

Another related point: All "Source" links on haskell.org are currently
broken, so the docs need to be regenerated an re-uploaded, anyway.

From thomasmiedema at gmail.com  Wed Apr  1 10:34:12 2015
From: thomasmiedema at gmail.com (Thomas Miedema)
Date: Wed, 1 Apr 2015 12:34:12 +0200
Subject: How to better parallelize GHC build.
In-Reply-To: <54FAD7D1.1050101@centrum.cz>
References: <54FAD7D1.1050101@centrum.cz>
Message-ID: <CAD3WKgg-UvhjafE1hYXRUhGmVJ21jk-tWrMXMiyPS6oF3+xQ_Q@mail.gmail.com>

Hi Karel,

could you try adding `-j8` to `SRC_HC_OPTS` for the build flavor you're
using in `mk/build.mk`, and running `gmake -j8` instead of `gmake -j64`. A
graph like the one you attached will likely look even worse, but the
walltime of your build should hopefully be improved.

The build system seems to currently rely entirely on `make` for
parallelism. It doesn't exploit ghc's own parallel `--make` at all, unless
you explictly add `-jn` to SRC_HC_OPTS, with n>1 (which also sets the
number of capabilities for the runtime system, so also adding `+RTS -Nn` is
not needed).

Case study: One of the first things the build system does is build
ghc-cabal and Cabal using the stage 0 compiler, through a single invocation
of `ghc --make`. All the later make targets depend on that step to complete
first. Because `ghc --make` is not instructed to build in parallel, using
`make -j1` or `make -j100000` doesn't make any difference (for that step).
I think your graph shows that there are many of more of such bottlenecks.

You would have to find out empirically how to best divide your number of
threads (32) between `make` and `ghc --make`. From reading this comment
<https://ghc.haskell.org/trac/ghc/ticket/9221#comment:12> by Simon in #9221
I understand it's better not to call `ghc --make -jn` with `n` higher than
the number of physical cores of your machine (8 in your case). Once you get
some better parallelism, other flags like `-A` might also have an effect on
walltime (see that ticket).

-Thomas

On Sat, Mar 7, 2015 at 11:49 AM, Karel Gardas <karel.gardas at centrum.cz>
wrote:

>
> Folks,
>
> first of all, I remember someone already mentioned issue with decreased
> parallelism of the GHC build recently somewhere but I cann't find it now.
> Sorry, for that since otherwise I would use this thread if it was on this
> mailing list.
>
> Anyway, while working on SPARC NCG I'm using T2000 which provides 32
> threads/8 core UltraSPARC T1 CPU. The property of this machine is that it's
> really slow on single-threaded work. To squeeze some perf from it man
> really needs to push 32 threads of work on it. Now, it really hurts my
> nerves to see it's lazy building/running just one or two ghc processes. To
> verify the fact I've created simple script to collect number of ghc
> processes over time and putting this to graph. The result is in the
> attached picture. The graph is result of running:
>
> gmake -j64
>
> anyway, the average number of running ghc processes is 4.4 and the median
> value is 2. IMHO such low number not only hurts build times on something
> like CMT SPARC machine, but also on let say a cluster of ARM machines using
> NFS and also on common engineering workstations which provide these days
> (IMHO!) around 8-16 cores (and double the threads number).
>
> My naive idea(s) for fixing this issue is (I'm assuming no Haskell file
> imports unused imports here, but perhaps this may be also investigated):
>
> 1) provide explicit dependencies which guides make to build in more
> optimal way
>
> 2) hack GHC's make depend to kind of compute explicit dependencies from
> (1) in an optimal way automatically
>
> 3) someone already mentioned using shake for building ghc. I don't know
> shake but perhaps this is the right direction?
>
> 4) hack GHC to compile needed hi file directly in its memory if hi file is
> not (yet!) available (issue how to get compiling options right here). Also
> I don't know hi file semantics yet so bear with me on this.
>
>
> Is there anything else which may be done to fix that issue? Is someone
> already working on some of those? (I mean those reasonable from the list)?
>
> Thanks!
> Karel
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150401/e77d1e16/attachment-0001.html>

From jan.stolarek at p.lodz.pl  Wed Apr  1 10:58:37 2015
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Wed, 1 Apr 2015 12:58:37 +0200
Subject: Bug: GHC creates incorrect code which throws <<loop>>
In-Reply-To: <CAKF_vo7NH0oWd2jyRAUesq4z-PGzFoE2g07BfWW_TNdnYefs5w@mail.gmail.com>
References: <CAKF_vo7NH0oWd2jyRAUesq4z-PGzFoE2g07BfWW_TNdnYefs5w@mail.gmail.com>
Message-ID: <201504011258.37170.jan.stolarek@p.lodz.pl>

Hi,

I can confirm that the bug is reproducable on my system as well (64bit Debian Wheezy).

Janek

Dnia ?roda, 1 kwietnia 2015, Yongqian Li napisa?:
> Hi all,
>
> I wanted to bring to your attention this bug,
> https://ghc.haskell.org/trac/ghc/ticket/10218 , which I filed about
> two days ago but hasn't gotten any replies to yet.
>
>
> In my opinion, this is a rather serious bug since GHC is producing
> incorrect code. While there is a workaround, it makes my program take
> about 2 hours to compile.
>
>
> Since reporting the bug, I've also seen "strange closure type"
> exceptions, which I believe are also caused by this bug, although I do
> not have a test case. Based on my limited understanding of GHC
> internals, I suspect the problem lies in how type class dictionaries
> are looked up at run time, as the problem disappears if GHC can fully
> resolve the types.
>
>
> Can others see if they can reproduce this bug? If there is any way I
> can help, please let me know.
>
>
> Sincerely,
> Yongqian Li
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



---
Politechnika ??dzka
Lodz University of Technology

Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata.
Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k?
prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie.

This email contains information intended solely for the use of the individual to whom it is addressed.
If you are not the intended recipient or if you have received this message in error,
please notify the sender and delete it from your system.

From jan.stolarek at p.lodz.pl  Wed Apr  1 12:26:06 2015
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Wed, 1 Apr 2015 14:26:06 +0200
Subject: Increased memory usage with GHC 7.10.1
Message-ID: <201504011426.06628.jan.stolarek@p.lodz.pl>

Forall hi,

I just uprgaded both of my machines to use GHC 7.10.1. I keep sandboxed installations of GHC and 
this means I had to rebuild Agda and Idris because the binaries built with GHC 7.8.4 were stored 
inside deactivated 7.8.4 sandbox. Sadly, I had problems building both Agda and Idris due to GHC 
taking up all of available memory.

With Idris the problematic module was Idris.ElabTerm (~2900LOC). The interesting part of the story 
is that when I do a clean build of Idris GHC consumes all of memory when compiling that module 
and I have to kill the build. But when I restart the build after killing GHC the module is 
compiled using a reasonable amount of memory and within reasonable time.

With Agda the problematic module is Agda.TypeChecking.Serialise (~2000LOC). The trick with killing 
the build and restarting it didn't work in this case. I had to compile Agda with GHC 7.8.4 (which 
works without problems though the mentioned module still requires a lot of memory) and alter my 
setup so that Agda binary is not stored inside GHC sandbox.

I wonder if any of you came across similar issues with GHC 7.10.1? Do we have any performance data 
that allows to compare memory usage and performance of GHC 7.10.1 with previous stable releases?

All of the above happened on 64bit Debian Wheezy with 2GB of RAM.

Janek

---
Politechnika ??dzka
Lodz University of Technology

Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata.
Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k?
prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie.

This email contains information intended solely for the use of the individual to whom it is addressed.
If you are not the intended recipient or if you have received this message in error,
please notify the sender and delete it from your system.

From karel.gardas at centrum.cz  Wed Apr  1 21:17:01 2015
From: karel.gardas at centrum.cz (Karel Gardas)
Date: Wed, 01 Apr 2015 23:17:01 +0200
Subject: How to better parallelize GHC build.
In-Reply-To: <CAD3WKgg-UvhjafE1hYXRUhGmVJ21jk-tWrMXMiyPS6oF3+xQ_Q@mail.gmail.com>
References: <54FAD7D1.1050101@centrum.cz>
 <CAD3WKgg-UvhjafE1hYXRUhGmVJ21jk-tWrMXMiyPS6oF3+xQ_Q@mail.gmail.com>
Message-ID: <551C604D.7050205@centrum.cz>


Hi Thomas,

thanks for your suggestion. Also thanks for the PR number. I've tried 
with quick way (build.mk) and benchmarking ghc while compiling ghc-cabal 
manually and here are the results:

-j1: 45s
-j2: 28s
-j3: 26s
-j4: 24s
-j5: 24s
-j6: 25s
-j6 -A32m: 23s
-j6 -A64m: 21s
-j6 -A128m: 23s

real time is reported, GHC compiles into i386 code on Solaris 11. GHC is 
located in /tmp hence basically in RAM. CPU is 6c/12ht E5-2620.

So not that bad, but on the other hand also not that good result. 
Anyway, unfortunately on my niagara this will probably not help me, 
since I guess --make -jX is recent addition probably not presented in 
7.6.x, right? If so, then I'm afraid this will not help me since on 
niagara I'm using patched 7.6.x with fixed SPARC NCG and this 
single-threaded will be probably faster than 7.10.1 multithreaded but 
building unregisterised (hence with C compiler...). Anyway, I'll try to 
benchmark this tomorrow and will keep you posted.

Thanks!
Karel

On 04/ 1/15 12:34 PM, Thomas Miedema wrote:
> Hi Karel,
>
> could you try adding `-j8` to `SRC_HC_OPTS` for the build flavor you're
> using in `mk/build.mk <http://build.mk>`, and running `gmake -j8`
> instead of `gmake -j64`. A graph like the one you attached will likely
> look even worse, but the walltime of your build should hopefully be
> improved.
>
> The build system seems to currently rely entirely on `make` for
> parallelism. It doesn't exploit ghc's own parallel `--make` at all,
> unless you explictly add `-jn` to SRC_HC_OPTS, with n>1 (which also sets
> the number of capabilities for the runtime system, so also adding `+RTS
> -Nn` is not needed).
>
> Case study: One of the first things the build system does is build
> ghc-cabal and Cabal using the stage 0 compiler, through a single
> invocation of `ghc --make`. All the later make targets depend on that
> step to complete first. Because `ghc --make` is not instructed to build
> in parallel, using `make -j1` or `make -j100000` doesn't make any
> difference (for that step). I think your graph shows that there are many
> of more of such bottlenecks.
>
> You would have to find out empirically how to best divide your number of
> threads (32) between `make` and `ghc --make`. From reading this comment
> <https://ghc.haskell.org/trac/ghc/ticket/9221#comment:12> by Simon in
> #9221 I understand it's better not to call `ghc --make -jn` with `n`
> higher than the number of physical cores of your machine (8 in your
> case). Once you get some better parallelism, other flags like `-A` might
> also have an effect on walltime (see that ticket).
>
> -Thomas
>
> On Sat, Mar 7, 2015 at 11:49 AM, Karel Gardas <karel.gardas at centrum.cz
> <mailto:karel.gardas at centrum.cz>> wrote:
>
>
>     Folks,
>
>     first of all, I remember someone already mentioned issue with
>     decreased parallelism of the GHC build recently somewhere but I
>     cann't find it now. Sorry, for that since otherwise I would use this
>     thread if it was on this mailing list.
>
>     Anyway, while working on SPARC NCG I'm using T2000 which provides 32
>     threads/8 core UltraSPARC T1 CPU. The property of this machine is
>     that it's really slow on single-threaded work. To squeeze some perf
>     from it man really needs to push 32 threads of work on it. Now, it
>     really hurts my nerves to see it's lazy building/running just one or
>     two ghc processes. To verify the fact I've created simple script to
>     collect number of ghc processes over time and putting this to graph.
>     The result is in the attached picture. The graph is result of running:
>
>     gmake -j64
>
>     anyway, the average number of running ghc processes is 4.4 and the
>     median value is 2. IMHO such low number not only hurts build times
>     on something like CMT SPARC machine, but also on let say a cluster
>     of ARM machines using NFS and also on common engineering
>     workstations which provide these days (IMHO!) around 8-16 cores (and
>     double the threads number).
>
>     My naive idea(s) for fixing this issue is (I'm assuming no Haskell
>     file imports unused imports here, but perhaps this may be also
>     investigated):
>
>     1) provide explicit dependencies which guides make to build in more
>     optimal way
>
>     2) hack GHC's make depend to kind of compute explicit dependencies
>     from (1) in an optimal way automatically
>
>     3) someone already mentioned using shake for building ghc. I don't
>     know shake but perhaps this is the right direction?
>
>     4) hack GHC to compile needed hi file directly in its memory if hi
>     file is not (yet!) available (issue how to get compiling options
>     right here). Also I don't know hi file semantics yet so bear with me
>     on this.
>
>
>     Is there anything else which may be done to fix that issue? Is
>     someone already working on some of those? (I mean those reasonable
>     from the list)?
>
>     Thanks!
>     Karel
>
>
>     _______________________________________________
>     ghc-devs mailing list
>     ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
>     http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>


From eir at cis.upenn.edu  Thu Apr  2 04:15:28 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Thu, 2 Apr 2015 00:15:28 -0400
Subject: Typeable
In-Reply-To: <C5025B7F-F313-49A9-940E-9927015F90A2@cis.upenn.edu>
References: <e1324de2fd8b4b24b25205f21c8976d3@DB4PR30MB030.064d.mgd.msft.net>
 <E718180A-E7BB-4E69-ABF0-DB8848F6B144@cis.upenn.edu>
 <C5025B7F-F313-49A9-940E-9927015F90A2@cis.upenn.edu>
Message-ID: <6D9D31EE-F4C8-479A-88B4-5554D215BCEA@cis.upenn.edu>


On Mar 26, 2015, at 10:50 AM, Richard Eisenberg <eir at cis.upenn.edu> wrote:

> This is now on Phab as https://phabricator.haskell.org/D757
> 
> I'll be making some comments there.

Comments made.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150402/d5480fd5/attachment.html>

From jan.stolarek at p.lodz.pl  Thu Apr  2 12:19:20 2015
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Thu, 2 Apr 2015 13:19:20 +0100
Subject: Increased memory usage with GHC 7.10.1
In-Reply-To: <201504011426.06628.jan.stolarek@p.lodz.pl>
References: <201504011426.06628.jan.stolarek@p.lodz.pl>
Message-ID: <201504021419.21520.jan.stolarek@p.lodz.pl>

An update frrom my second machine, this time with 4GB of RAM. Compiling Agda ran out of memory 
(again Agda.TypeChecking.Serialise module) and I had to kill the build. But once I restarted the 
build the module was compiled succesfully in a matter of minutes and using around 50% of memory. 
This looks like some kind of memory leak in GHC.

Janek

Dnia ?roda, 1 kwietnia 2015, Jan Stolarek napisa?:
> Forall hi,
>
> I just uprgaded both of my machines to use GHC 7.10.1. I keep sandboxed
> installations of GHC and this means I had to rebuild Agda and Idris because
> the binaries built with GHC 7.8.4 were stored inside deactivated 7.8.4
> sandbox. Sadly, I had problems building both Agda and Idris due to GHC
> taking up all of available memory.
>
> With Idris the problematic module was Idris.ElabTerm (~2900LOC). The
> interesting part of the story is that when I do a clean build of Idris GHC
> consumes all of memory when compiling that module and I have to kill the
> build. But when I restart the build after killing GHC the module is
> compiled using a reasonable amount of memory and within reasonable time.
>
> With Agda the problematic module is Agda.TypeChecking.Serialise (~2000LOC).
> The trick with killing the build and restarting it didn't work in this
> case. I had to compile Agda with GHC 7.8.4 (which works without problems
> though the mentioned module still requires a lot of memory) and alter my
> setup so that Agda binary is not stored inside GHC sandbox.
>
> I wonder if any of you came across similar issues with GHC 7.10.1? Do we
> have any performance data that allows to compare memory usage and
> performance of GHC 7.10.1 with previous stable releases?
>
> All of the above happened on 64bit Debian Wheezy with 2GB of RAM.
>
> Janek
>
> ---
> Politechnika ??dzka
> Lodz University of Technology
>
> Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata.
> Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez
> pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie.
>
> This email contains information intended solely for the use of the
> individual to whom it is addressed. If you are not the intended recipient
> or if you have received this message in error, please notify the sender and
> delete it from your system.
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users



---
Politechnika ??dzka
Lodz University of Technology

Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata.
Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k?
prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie.

This email contains information intended solely for the use of the individual to whom it is addressed.
If you are not the intended recipient or if you have received this message in error,
please notify the sender and delete it from your system.

From eir at cis.upenn.edu  Thu Apr  2 12:29:55 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Thu, 2 Apr 2015 08:29:55 -0400
Subject: Increased memory usage with GHC 7.10.1
In-Reply-To: <201504021419.21520.jan.stolarek@p.lodz.pl>
References: <201504011426.06628.jan.stolarek@p.lodz.pl>
 <201504021419.21520.jan.stolarek@p.lodz.pl>
Message-ID: <93A36B72-4F95-4DD8-8A05-4B12494F6971@cis.upenn.edu>

Post a bug report! :)

On Apr 2, 2015, at 8:19 AM, Jan Stolarek <jan.stolarek at p.lodz.pl> wrote:

> An update frrom my second machine, this time with 4GB of RAM. Compiling Agda ran out of memory 
> (again Agda.TypeChecking.Serialise module) and I had to kill the build. But once I restarted the 
> build the module was compiled succesfully in a matter of minutes and using around 50% of memory. 
> This looks like some kind of memory leak in GHC.
> 
> Janek
> 
> Dnia ?roda, 1 kwietnia 2015, Jan Stolarek napisa?:
>> Forall hi,
>> 
>> I just uprgaded both of my machines to use GHC 7.10.1. I keep sandboxed
>> installations of GHC and this means I had to rebuild Agda and Idris because
>> the binaries built with GHC 7.8.4 were stored inside deactivated 7.8.4
>> sandbox. Sadly, I had problems building both Agda and Idris due to GHC
>> taking up all of available memory.
>> 
>> With Idris the problematic module was Idris.ElabTerm (~2900LOC). The
>> interesting part of the story is that when I do a clean build of Idris GHC
>> consumes all of memory when compiling that module and I have to kill the
>> build. But when I restart the build after killing GHC the module is
>> compiled using a reasonable amount of memory and within reasonable time.
>> 
>> With Agda the problematic module is Agda.TypeChecking.Serialise (~2000LOC).
>> The trick with killing the build and restarting it didn't work in this
>> case. I had to compile Agda with GHC 7.8.4 (which works without problems
>> though the mentioned module still requires a lot of memory) and alter my
>> setup so that Agda binary is not stored inside GHC sandbox.
>> 
>> I wonder if any of you came across similar issues with GHC 7.10.1? Do we
>> have any performance data that allows to compare memory usage and
>> performance of GHC 7.10.1 with previous stable releases?
>> 
>> All of the above happened on 64bit Debian Wheezy with 2GB of RAM.
>> 
>> Janek
>> 
>> ---
>> Politechnika ??dzka
>> Lodz University of Technology
>> 
>> Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata.
>> Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez
>> pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie.
>> 
>> This email contains information intended solely for the use of the
>> individual to whom it is addressed. If you are not the intended recipient
>> or if you have received this message in error, please notify the sender and
>> delete it from your system.
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
> 
> 
> 
> ---
> Politechnika ??dzka
> Lodz University of Technology
> 
> Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata.
> Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k?
> prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie.
> 
> This email contains information intended solely for the use of the individual to whom it is addressed.
> If you are not the intended recipient or if you have received this message in error,
> please notify the sender and delete it from your system.
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
> 


From jan.stolarek at p.lodz.pl  Thu Apr  2 12:47:25 2015
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Thu, 2 Apr 2015 13:47:25 +0100
Subject: Increased memory usage with GHC 7.10.1
In-Reply-To: <93A36B72-4F95-4DD8-8A05-4B12494F6971@cis.upenn.edu>
References: <201504011426.06628.jan.stolarek@p.lodz.pl>
 <201504021419.21520.jan.stolarek@p.lodz.pl>
 <93A36B72-4F95-4DD8-8A05-4B12494F6971@cis.upenn.edu>
Message-ID: <201504021447.25480.jan.stolarek@p.lodz.pl>

I will. But I was curious whether this is only me or is anyone else seeing similar behaviour. And 
what about performance comparisson between 7.8.4 and 7.10.1? Do we have any numbers?

Janek

Dnia czwartek, 2 kwietnia 2015, Richard Eisenberg napisa?:
> Post a bug report! :)
>
> On Apr 2, 2015, at 8:19 AM, Jan Stolarek <jan.stolarek at p.lodz.pl> wrote:
> > An update frrom my second machine, this time with 4GB of RAM. Compiling
> > Agda ran out of memory (again Agda.TypeChecking.Serialise module) and I
> > had to kill the build. But once I restarted the build the module was
> > compiled succesfully in a matter of minutes and using around 50% of
> > memory. This looks like some kind of memory leak in GHC.
> >
> > Janek
> >
> > Dnia ?roda, 1 kwietnia 2015, Jan Stolarek napisa?:
> >> Forall hi,
> >>
> >> I just uprgaded both of my machines to use GHC 7.10.1. I keep sandboxed
> >> installations of GHC and this means I had to rebuild Agda and Idris
> >> because the binaries built with GHC 7.8.4 were stored inside deactivated
> >> 7.8.4 sandbox. Sadly, I had problems building both Agda and Idris due to
> >> GHC taking up all of available memory.
> >>
> >> With Idris the problematic module was Idris.ElabTerm (~2900LOC). The
> >> interesting part of the story is that when I do a clean build of Idris
> >> GHC consumes all of memory when compiling that module and I have to kill
> >> the build. But when I restart the build after killing GHC the module is
> >> compiled using a reasonable amount of memory and within reasonable time.
> >>
> >> With Agda the problematic module is Agda.TypeChecking.Serialise
> >> (~2000LOC). The trick with killing the build and restarting it didn't
> >> work in this case. I had to compile Agda with GHC 7.8.4 (which works
> >> without problems though the mentioned module still requires a lot of
> >> memory) and alter my setup so that Agda binary is not stored inside GHC
> >> sandbox.
> >>
> >> I wonder if any of you came across similar issues with GHC 7.10.1? Do we
> >> have any performance data that allows to compare memory usage and
> >> performance of GHC 7.10.1 with previous stable releases?
> >>
> >> All of the above happened on 64bit Debian Wheezy with 2GB of RAM.
> >>
> >> Janek
> >>
> >> ---
> >> Politechnika ??dzka
> >> Lodz University of Technology
> >>
> >> Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata.
> >> Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez
> >> pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie.
> >>
> >> This email contains information intended solely for the use of the
> >> individual to whom it is addressed. If you are not the intended
> >> recipient or if you have received this message in error, please notify
> >> the sender and delete it from your system.
> >> _______________________________________________
> >> Glasgow-haskell-users mailing list
> >> Glasgow-haskell-users at haskell.org
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
> >
> > ---
> > Politechnika ??dzka
> > Lodz University of Technology
> >
> > Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata.
> > Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez
> > pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie.
> >
> > This email contains information intended solely for the use of the
> > individual to whom it is addressed. If you are not the intended recipient
> > or if you have received this message in error, please notify the sender
> > and delete it from your system.
> > _______________________________________________
> > Glasgow-haskell-users mailing list
> > Glasgow-haskell-users at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users



---
Politechnika ??dzka
Lodz University of Technology

Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata.
Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k?
prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie.

This email contains information intended solely for the use of the individual to whom it is addressed.
If you are not the intended recipient or if you have received this message in error,
please notify the sender and delete it from your system.

From mail at joachim-breitner.de  Thu Apr  2 12:53:46 2015
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 02 Apr 2015 14:53:46 +0200
Subject: Increased memory usage with GHC 7.10.1
In-Reply-To: <201504021447.25480.jan.stolarek@p.lodz.pl>
References: <201504011426.06628.jan.stolarek@p.lodz.pl>
 <201504021419.21520.jan.stolarek@p.lodz.pl>
 <93A36B72-4F95-4DD8-8A05-4B12494F6971@cis.upenn.edu>
 <201504021447.25480.jan.stolarek@p.lodz.pl>
Message-ID: <1427979226.1578.19.camel@joachim-breitner.de>

Hi,

Am Donnerstag, den 02.04.2015, 13:47 +0100 schrieb Jan Stolarek:
> I will. But I was curious whether this is only me or is anyone else seeing similar behaviour. And 
> what about performance comparisson between 7.8.4 and 7.10.1? Do we have any numbers?

we have a few numbers between 7.8.3 and HEAD, on
http://ghcspeed-nomeata.rhcloud.com/comparison/
e.g.
http://ghcspeed-nomeata.rhcloud.com/comparison/?exe=2%2B68%2C2%2BL%2Bdefault&ben=320%2C321%2C322%2C323%2C324%2C325%2C326%2C327%2C328%2C329%2C330%2C331%2C332%2C333%2C334%2C335%2C336%2C337%2C338%2C339%2C340%2C341%2C342%2C343%2C344%2C345%2C346%2C347%2C348%2C349%2C350%2C351%2C352%2C353%2C354%2C355%2C356%2C357%2C358%2C359%2C360%2C361%2C362%2C363%2C364%2C365%2C366%2C367%2C368%2C369%2C370%2C371%2C372%2C373%2C374%2C375%2C376%2C377%2C378%2C379%2C380%2C381%2C382%2C383%2C384%2C385%2C386%2C387%2C388%2C389%2C390%2C391%2C392%2C393%2C394%2C395%2C396%2C397%2C398%2C399%2C400%2C401%2C402%2C403%2C404%2C405%2C406%2C407%2C408%2C409%2C410%2C411%2C412%2C413%2C414%2C415%2C416%2C417%2C418%2C419&env=1&hor=false&bas=none&chart=normal+bars
but it does not have numbers on binary size for 7.8.3.

http://ghcspeed-nomeata.rhcloud.com/timeline/#/?exe=2&base=2+68&ben=nofib/size/anna&env=1&revs=1000&equid=on
does not show anything worrying (but only goes back to last October).


Greetings,
Joachim

-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150402/ce19fc1b/attachment.sig>

From dan.doel at gmail.com  Thu Apr  2 14:00:08 2015
From: dan.doel at gmail.com (Dan Doel)
Date: Thu, 2 Apr 2015 10:00:08 -0400
Subject: Increased memory usage with GHC 7.10.1
In-Reply-To: <201504021447.25480.jan.stolarek@p.lodz.pl>
References: <201504011426.06628.jan.stolarek@p.lodz.pl>
 <201504021419.21520.jan.stolarek@p.lodz.pl>
 <93A36B72-4F95-4DD8-8A05-4B12494F6971@cis.upenn.edu>
 <201504021447.25480.jan.stolarek@p.lodz.pl>
Message-ID: <CAHEA9tOe0pijmhQz=FphzgQvMyVvZRAwhi1+eNZANhdy6c8T7Q@mail.gmail.com>

You aren't the only one. The vector test suite also has these kind of
issues. In its case, it's hard for me to tell how big the code is, because
template haskell is being used to generate it. However, I don't think the
template haskell is what's using the additional performance, because the
test suite is compiled with both -O0 and -O2, and only the latter runs into
performance issues.

In vector's case, 7.6.3 compiles significantly faster than 7.8.4, which is
in turn significantly faster than 7.10.1. And memory usage follows the same
pattern (with -O2 at least). 7.6.3 uses ~400MB of memory, 7.8.4 1-2GB and
7.10.1 3-4GB (if I'm remembering correctly). And while I can build the
tests on 7.10 in around 5 minutes, travis times out building them after
around half an hour.

On Thu, Apr 2, 2015 at 8:47 AM, Jan Stolarek <jan.stolarek at p.lodz.pl> wrote:

> I will. But I was curious whether this is only me or is anyone else seeing
> similar behaviour. And
> what about performance comparisson between 7.8.4 and 7.10.1? Do we have
> any numbers?
>
> Janek
>
> Dnia czwartek, 2 kwietnia 2015, Richard Eisenberg napisa?:
> > Post a bug report! :)
> >
> > On Apr 2, 2015, at 8:19 AM, Jan Stolarek <jan.stolarek at p.lodz.pl> wrote:
> > > An update frrom my second machine, this time with 4GB of RAM. Compiling
> > > Agda ran out of memory (again Agda.TypeChecking.Serialise module) and I
> > > had to kill the build. But once I restarted the build the module was
> > > compiled succesfully in a matter of minutes and using around 50% of
> > > memory. This looks like some kind of memory leak in GHC.
> > >
> > > Janek
> > >
> > > Dnia ?roda, 1 kwietnia 2015, Jan Stolarek napisa?:
> > >> Forall hi,
> > >>
> > >> I just uprgaded both of my machines to use GHC 7.10.1. I keep
> sandboxed
> > >> installations of GHC and this means I had to rebuild Agda and Idris
> > >> because the binaries built with GHC 7.8.4 were stored inside
> deactivated
> > >> 7.8.4 sandbox. Sadly, I had problems building both Agda and Idris due
> to
> > >> GHC taking up all of available memory.
> > >>
> > >> With Idris the problematic module was Idris.ElabTerm (~2900LOC). The
> > >> interesting part of the story is that when I do a clean build of Idris
> > >> GHC consumes all of memory when compiling that module and I have to
> kill
> > >> the build. But when I restart the build after killing GHC the module
> is
> > >> compiled using a reasonable amount of memory and within reasonable
> time.
> > >>
> > >> With Agda the problematic module is Agda.TypeChecking.Serialise
> > >> (~2000LOC). The trick with killing the build and restarting it didn't
> > >> work in this case. I had to compile Agda with GHC 7.8.4 (which works
> > >> without problems though the mentioned module still requires a lot of
> > >> memory) and alter my setup so that Agda binary is not stored inside
> GHC
> > >> sandbox.
> > >>
> > >> I wonder if any of you came across similar issues with GHC 7.10.1? Do
> we
> > >> have any performance data that allows to compare memory usage and
> > >> performance of GHC 7.10.1 with previous stable releases?
> > >>
> > >> All of the above happened on 64bit Debian Wheezy with 2GB of RAM.
> > >>
> > >> Janek
> > >>
> > >> ---
> > >> Politechnika ??dzka
> > >> Lodz University of Technology
> > >>
> > >> Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla
> adresata.
> > >> Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j?
> przez
> > >> pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej
> usuni?cie.
> > >>
> > >> This email contains information intended solely for the use of the
> > >> individual to whom it is addressed. If you are not the intended
> > >> recipient or if you have received this message in error, please notify
> > >> the sender and delete it from your system.
> > >> _______________________________________________
> > >> Glasgow-haskell-users mailing list
> > >> Glasgow-haskell-users at haskell.org
> > >>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
> > >
> > > ---
> > > Politechnika ??dzka
> > > Lodz University of Technology
> > >
> > > Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla
> adresata.
> > > Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez
> > > pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej
> usuni?cie.
> > >
> > > This email contains information intended solely for the use of the
> > > individual to whom it is addressed. If you are not the intended
> recipient
> > > or if you have received this message in error, please notify the sender
> > > and delete it from your system.
> > > _______________________________________________
> > > Glasgow-haskell-users mailing list
> > > Glasgow-haskell-users at haskell.org
> > > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
>
>
> ---
> Politechnika ??dzka
> Lodz University of Technology
>
> Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata.
> Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez
> pomy?k?
> prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie.
>
> This email contains information intended solely for the use of the
> individual to whom it is addressed.
> If you are not the intended recipient or if you have received this message
> in error,
> please notify the sender and delete it from your system.
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150402/d0fafed6/attachment-0001.html>

From george.colpitts at gmail.com  Thu Apr  2 15:08:43 2015
From: george.colpitts at gmail.com (George Colpitts)
Date: Thu, 2 Apr 2015 12:08:43 -0300
Subject: Increased memory usage with GHC 7.10.1
In-Reply-To: <201504021447.25480.jan.stolarek@p.lodz.pl>
References: <201504011426.06628.jan.stolarek@p.lodz.pl>
 <201504021419.21520.jan.stolarek@p.lodz.pl>
 <93A36B72-4F95-4DD8-8A05-4B12494F6971@cis.upenn.edu>
 <201504021447.25480.jan.stolarek@p.lodz.pl>
Message-ID: <CAB-d4A4eML4DkJAFtpbjAAPPGdVcGHyD6dafy6g70ut+9kwDQw@mail.gmail.com>

I'm curious why the amount of RAM is relevant as all of our OS have virtual
memory so it is only the size of the heap and the amount of swap that
should be relevant for an Out Of Memory error, right? How big is your heap?
Amount of RAM should only affect speed (i.e. if there is excessive paging)
but should not affect Out Of Memory right?

On Thu, Apr 2, 2015 at 9:47 AM, Jan Stolarek <jan.stolarek at p.lodz.pl> wrote:

> I will. But I was curious whether this is only me or is anyone else seeing
> similar behaviour. And
> what about performance comparisson between 7.8.4 and 7.10.1? Do we have
> any numbers?
>
> Janek
>
> Dnia czwartek, 2 kwietnia 2015, Richard Eisenberg napisa?:
> > Post a bug report! :)
> >
> > On Apr 2, 2015, at 8:19 AM, Jan Stolarek <jan.stolarek at p.lodz.pl> wrote:
> > > An update frrom my second machine, this time with 4GB of RAM. Compiling
> > > Agda ran out of memory (again Agda.TypeChecking.Serialise module) and I
> > > had to kill the build. But once I restarted the build the module was
> > > compiled succesfully in a matter of minutes and using around 50% of
> > > memory. This looks like some kind of memory leak in GHC.
> > >
> > > Janek
> > >
> > > Dnia ?roda, 1 kwietnia 2015, Jan Stolarek napisa?:
> > >> Forall hi,
> > >>
> > >> I just uprgaded both of my machines to use GHC 7.10.1. I keep
> sandboxed
> > >> installations of GHC and this means I had to rebuild Agda and Idris
> > >> because the binaries built with GHC 7.8.4 were stored inside
> deactivated
> > >> 7.8.4 sandbox. Sadly, I had problems building both Agda and Idris due
> to
> > >> GHC taking up all of available memory.
> > >>
> > >> With Idris the problematic module was Idris.ElabTerm (~2900LOC). The
> > >> interesting part of the story is that when I do a clean build of Idris
> > >> GHC consumes all of memory when compiling that module and I have to
> kill
> > >> the build. But when I restart the build after killing GHC the module
> is
> > >> compiled using a reasonable amount of memory and within reasonable
> time.
> > >>
> > >> With Agda the problematic module is Agda.TypeChecking.Serialise
> > >> (~2000LOC). The trick with killing the build and restarting it didn't
> > >> work in this case. I had to compile Agda with GHC 7.8.4 (which works
> > >> without problems though the mentioned module still requires a lot of
> > >> memory) and alter my setup so that Agda binary is not stored inside
> GHC
> > >> sandbox.
> > >>
> > >> I wonder if any of you came across similar issues with GHC 7.10.1? Do
> we
> > >> have any performance data that allows to compare memory usage and
> > >> performance of GHC 7.10.1 with previous stable releases?
> > >>
> > >> All of the above happened on 64bit Debian Wheezy with 2GB of RAM.
> > >>
> > >> Janek
> > >>
> > >> ---
> > >> Politechnika ??dzka
> > >> Lodz University of Technology
> > >>
> > >> Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla
> adresata.
> > >> Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j?
> przez
> > >> pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej
> usuni?cie.
> > >>
> > >> This email contains information intended solely for the use of the
> > >> individual to whom it is addressed. If you are not the intended
> > >> recipient or if you have received this message in error, please notify
> > >> the sender and delete it from your system.
> > >> _______________________________________________
> > >> Glasgow-haskell-users mailing list
> > >> Glasgow-haskell-users at haskell.org
> > >>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
> > >
> > > ---
> > > Politechnika ??dzka
> > > Lodz University of Technology
> > >
> > > Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla
> adresata.
> > > Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez
> > > pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej
> usuni?cie.
> > >
> > > This email contains information intended solely for the use of the
> > > individual to whom it is addressed. If you are not the intended
> recipient
> > > or if you have received this message in error, please notify the sender
> > > and delete it from your system.
> > > _______________________________________________
> > > Glasgow-haskell-users mailing list
> > > Glasgow-haskell-users at haskell.org
> > > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
>
>
> ---
> Politechnika ??dzka
> Lodz University of Technology
>
> Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata.
> Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez
> pomy?k?
> prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie.
>
> This email contains information intended solely for the use of the
> individual to whom it is addressed.
> If you are not the intended recipient or if you have received this message
> in error,
> please notify the sender and delete it from your system.
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150402/fd4625de/attachment.html>

From jan.stolarek at p.lodz.pl  Thu Apr  2 15:21:34 2015
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Thu, 2 Apr 2015 16:21:34 +0100
Subject: Increased memory usage with GHC 7.10.1
In-Reply-To: <CAB-d4A4eML4DkJAFtpbjAAPPGdVcGHyD6dafy6g70ut+9kwDQw@mail.gmail.com>
References: <201504011426.06628.jan.stolarek@p.lodz.pl>
 <201504021447.25480.jan.stolarek@p.lodz.pl>
 <CAB-d4A4eML4DkJAFtpbjAAPPGdVcGHyD6dafy6g70ut+9kwDQw@mail.gmail.com>
Message-ID: <201504021721.35386.jan.stolarek@p.lodz.pl>

> I'm curious why the amount of RAM is relevant as all of our OS have virtual
> memory so it is only the size of the heap and the amount of swap that
> should be relevant for an Out Of Memory error, right? How big is your heap?
> Amount of RAM should only affect speed (i.e. if there is excessive paging)
> but should not affect Out Of Memory right?
Actually, I never allowed GHC to completely run out of memory. I just killed the build process 
when it consumed all of physical RAM memory and started growing into swap. At that point machine 
becomes barely usable and the build practically stalls as CPU usage drops to 0. FYI: both 
machines have size of swap equal to size of RAM.

Janek


---
Politechnika ??dzka
Lodz University of Technology

Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata.
Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k?
prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie.

This email contains information intended solely for the use of the individual to whom it is addressed.
If you are not the intended recipient or if you have received this message in error,
please notify the sender and delete it from your system.

From austin at well-typed.com  Thu Apr  2 18:38:13 2015
From: austin at well-typed.com (Austin Seipp)
Date: Thu, 2 Apr 2015 13:38:13 -0500
Subject: GHC 7.10.1 html docs all flat?
In-Reply-To: <DUB131-W580CDF93A38CA0EF01E8C0C8F40@phx.gbl>
References: <DUB131-W580CDF93A38CA0EF01E8C0C8F40@phx.gbl>
Message-ID: <CAEs96n2vtBMqYKiLtY9GR00wQ__VVYTjr16xLDLCwyiV8sTeBA@mail.gmail.com>

Hi Randy,

This is due to an upstream Haddock bug I didn't manage to fix before
the release; see https://ghc.haskell.org/trac/ghc/ticket/10206 - we
really need to fix this for 7.10.2.

I believe the problem we need to fix is in Haddock. The fact that the
non-hierarchical version appears on the website is just so people can
browse it (and FWIW, the 'correct links' are there, but obviously the
hyperlinks *to* the proper places are broken...)

On Tue, Mar 31, 2015 at 1:20 PM, Randy Polen <randyhaskell at outlook.com> wrote:
> The HP build expects that the html docs for the ghc-bundled packages will be in
> heirarchical directories, based on the package name (e.g., GHC.Magic docs in
> libraries/ghc-prim-0.3.1.0/GHC-Magic.html) which is how it has been for many
> ghc releases.  In 7.10.1, I thought it was an error but it seems the
> haskell.org docs reflect this new, flat way (e.g,. GHC.Magic docs in
> libraries/GHC-Magic.html).
>
>
> Just want to make sure this is what is expected, and then change the HP
> build code accordingly.
>
>
> Follow up question: should the HP-bundled docs do the same thing?  Is the
>
> flat model the way to go for all the docs?  Won't this cause collisions for
>
> updated packages?
>
>
> Randy
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From austin at well-typed.com  Fri Apr  3 11:36:43 2015
From: austin at well-typed.com (Austin Seipp)
Date: Fri, 3 Apr 2015 06:36:43 -0500
Subject: Help wanted: working on the GHC webpage
Message-ID: <CAEs96n303YDnawHbGzretCC24ogxfoo1LmzB4xFyhbDTAidYTQ@mail.gmail.com>

Hello *,

For a while now, I've been wanting to do a facelift on the GHC
homepage, but among many other things it's been a low priority. I'd
like for people to help, so I've tried to get the ball rolling.

The webpages existed in a Darcs repository previously (which wasn't
available online), but earlier today I converted them to a git
repository which you can find here:

https://github.com/haskell-infra/ghc-homepage

The site is currently composed of a set of "server side include" files
that have a crude form of HTML templating. So it's mostly just pretty
verbose to add or refactor anything, and the sites templating and
styling is quite old (it dates back at least 10 years!)

So, I'm making an official call for some help. At the very least, I'd
like to at least end up converting the site to something like Hakyll
which is doable without me causing a lot of damage to the stylesheets,
but for the actual page itself I'd really appreciate it if anyone
could help out! Please send pull requests or file issues, it's much
appreciated.

-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From sergey.bushnyak at sigrlami.eu  Fri Apr  3 13:16:24 2015
From: sergey.bushnyak at sigrlami.eu (Sergey Bushnyak)
Date: Fri, 03 Apr 2015 16:16:24 +0300
Subject: Help wanted: working on the GHC webpage
In-Reply-To: <CAEs96n303YDnawHbGzretCC24ogxfoo1LmzB4xFyhbDTAidYTQ@mail.gmail.com>
References: <CAEs96n303YDnawHbGzretCC24ogxfoo1LmzB4xFyhbDTAidYTQ@mail.gmail.com>
Message-ID: <551E92A8.7020901@sigrlami.eu>

Hi, Austin.

Here is my fork of yours `ghc-homepage' repo 
https://github.com/sigrlami/ghc-homepage. It builds main page with 
Hakyll and overall work could be done in couple of days or week.

But I want to raise couple of issues related to design.

1)The site is built on outdated html markup and not consistent in it's 
structure, a lot of stuff linked to other pages which have different 
design.

2) Could we discuss possibility to make it look more like new 
haskell.org page and update design in general, switch to HTML5/CSS3 .

3) Also, it might be easier to publish blog posts on this site, like 
weekly news, without linking to `track`. I can reuse some code we are 
using for building haskell.od.ua (OdHug, Odessa Haskell User Group)

I can work on this transition.

--
Best regards,
Sergey Bushnyak


On 04/03/2015 02:36 PM, Austin Seipp wrote:
> Hello *,
>
> For a while now, I've been wanting to do a facelift on the GHC
> homepage, but among many other things it's been a low priority. I'd
> like for people to help, so I've tried to get the ball rolling.
>
> The webpages existed in a Darcs repository previously (which wasn't
> available online), but earlier today I converted them to a git
> repository which you can find here:
>
> https://github.com/haskell-infra/ghc-homepage
>
> The site is currently composed of a set of "server side include" files
> that have a crude form of HTML templating. So it's mostly just pretty
> verbose to add or refactor anything, and the sites templating and
> styling is quite old (it dates back at least 10 years!)
>
> So, I'm making an official call for some help. At the very least, I'd
> like to at least end up converting the site to something like Hakyll
> which is doable without me causing a lot of damage to the stylesheets,
> but for the actual page itself I'd really appreciate it if anyone
> could help out! Please send pull requests or file issues, it's much
> appreciated.
>


From hvriedel at gmail.com  Fri Apr  3 13:44:13 2015
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Fri, 03 Apr 2015 15:44:13 +0200
Subject: Help wanted: working on the GHC webpage
In-Reply-To: <551E92A8.7020901@sigrlami.eu> (Sergey Bushnyak's message of
 "Fri, 03 Apr 2015 16:16:24 +0300")
References: <CAEs96n303YDnawHbGzretCC24ogxfoo1LmzB4xFyhbDTAidYTQ@mail.gmail.com>
 <551E92A8.7020901@sigrlami.eu>
Message-ID: <87y4m9conm.fsf@gmail.com>

Hi Sergey,

On 2015-04-03 at 15:16:24 +0200, Sergey Bushnyak wrote:

[...]

> 3) Also, it might be easier to publish blog posts on this site, like
> weekly news, without linking to `track`. I can reuse some code we are
> using for building haskell.od.ua (OdHug, Odessa Haskell User Group)

Why would it be easier? What's difficult about publishing on
https://ghc.haskell.org/trac/ghc/blog?

Moreover, the GHC weekly news are intimately linked to Trac, as they
reference Trac-tickets and Git commits, which Trac is able to annotate
with meta-data (ticket-type, -status, and -title for Ticket references,
as well as part of the Git commit msg for Git-commit refs).

Finally, GHC blog-posts are listed as events on 
https://ghc.haskell.org/trac/ghc/timeline


Cheers,
  hvr

From sergey.bushnyak at sigrlami.eu  Fri Apr  3 14:08:26 2015
From: sergey.bushnyak at sigrlami.eu (Sergey Bushnyak)
Date: Fri, 03 Apr 2015 17:08:26 +0300
Subject: Help wanted: working on the GHC webpage
In-Reply-To: <87y4m9conm.fsf@gmail.com>
References: <CAEs96n303YDnawHbGzretCC24ogxfoo1LmzB4xFyhbDTAidYTQ@mail.gmail.com>	<551E92A8.7020901@sigrlami.eu>
 <87y4m9conm.fsf@gmail.com>
Message-ID: <551E9EDA.40301@sigrlami.eu>


> Why would it be easier? What's difficult about publishing on
> https://ghc.haskell.org/trac/ghc/blog?
I'm actually don't know how it's published on track. From my standpoint 
as newcomer it's better to see what's happening from one place, with one 
design, have some shared git repo where people contribute in markdown.
> Moreover, the GHC weekly news are intimately linked to Trac, as they
> reference Trac-tickets and Git commits, which Trac is able to annotate
> with meta-data (ticket-type, -status, and -title for Ticket references,
> as well as part of the Git commit msg for Git-commit refs).

Ok, it was just a suggestion. Maybe it's a bad idea, doesn't know about annotation.

Anyway, still can help on updating ghc home page.


From ozataman at gmail.com  Sun Apr  5 18:01:06 2015
From: ozataman at gmail.com (Ozgun Ataman)
Date: Sun, 5 Apr 2015 14:01:06 -0400
Subject: Slower Compilation on GHC 7.8.4 (vs. 7.6.3)
Message-ID: <CAGn37G2cTGy88F-cHjFg9XEbDqaYqQetKR4iPqUnzT9DDXdWDQ@mail.gmail.com>

Hello,

Apologies upfront for the long post below, but I thought our experience on
this particular point might be worth sharing. I present some observations
first and then mention the particular problem around "cabal repl"
facilitated development workflow. Any ideas/feedback on the latter point
would be much appreciated and please let me know if there are other
metrics, info or output I can produce here for further
investigation/clarification.

Recently at work, we upgraded a decent size project from GHC 7.6.3 to GHC
7.8.4 and as a result observed a very significant slowdown in compile
times. Code changes were very minimal and should not be a factor. Any
mistakes below are mine, but I can fairly confidently say that there is a
visible-to-the-eye slowdown in compile times.

We made a few measurements to quantify the issue and here is the data:

   - This project has 220 direct modules (non-dependency) that are compiled
   with each "cabal build" and we always use sandboxes
   - Tests were performed on OS X, though we saw similar results on Linux
   - Single threaded (-j=1) wall-clock compile time has gone up by around
   30% for the overall project
   - With O1 and -j=N, the overall wall-clock time is approximately the
   same (around 8 min), but the CPU time spent is a staggering 7.5X higher (!)
   - With O0 and -j=N the overall wall-clock time is 40% higher, but the
   CPU time spent is a staggering 7.5X higher (!)
   - With -O0, "cabal repl" load times have gone up by a staggering 2.5X (!)
      - 7.8.4: 3 min. 35 seconds
      - 7.6.3: 1 min. 2 seconds
   - Measuring compile times for individual modules, we see that those that
   are heavily loaded with lots of types, TH-facilitated type and typeclass
   derivations and those that contain large "blobs" of values directly at the
   top level now take much longer to compile:
      - We have 10 modules that each take over 10 seconds
      - We have 3 modules that each take over 35 seconds
   - Sidenote observation: In general, parallel builds with -j appear to
   cause a very significant overhead under the "system" part of timing:
      - Example with 7.6.3, O0: cabal build  140.57s user 13.25s system
      100% cpu 2:33.70 total
      - Example with 7.8.4, O0: cabal build  507.83s user 655.43s system
      549% cpu 3:31.59 total


The main hurt here has been the infeasibility of using "cabal repl / ghci"
 fast-feedback style development (via emacs, vim, command-line, etc.),
since:

   - Unlike "cabal build", "cabal repl" re-compiles from scratch with every
   invocation ":l App.Foo.Bar", which itself is the necessary first step when
   starting to hack on a module (we can then use :r to somewhat help the
   situation)
   - The slowdown is about 2.5X as stated above: What used to take a minute
   now takes 3.5 minutes.
   - cabal repl does not seem to benefit from -j at all
   - cabal repl 7.8.4 appears to be hurt particularly by the heavier modules
   - The heavier modules are often at the top of the compile tree (types,
   derivations, etc) and are practically loaded on the critical path all the
   time

Let me know if I'm missing anything here and any/all feedback is much
appreciated!

Cheers,
Oz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150405/69542f0f/attachment.html>

From k-bx at k-bx.com  Mon Apr  6 06:52:01 2015
From: k-bx at k-bx.com (Konstantine Rybnikov)
Date: Mon, 6 Apr 2015 09:52:01 +0300
Subject: DPH tests
Message-ID: <CAAbahfTsxKg0QCkLZRN5wTjN9O8s_w5YZBxYj15k98tV7XFUDw@mail.gmail.com>

Hi!

There?s ?Additional Packages? section [0] which lists packages that need to
be installed in order to run full testsuite. But I couldn?t install dph-*
ones, first errors I was getting were regular cabal-constraint ones. I
wrote an author Ben Lippmeier, but he replied that dph-* packages were
obsolete and not maintained anymore. I grepped and saw that all tests are
under testsuite/dph folder. So: does GHC still run them at all? Should we
edit wiki? Or edit test-suite?

Thanks!

[0]:
https://ghc.haskell.org/trac/ghc/wiki/Building/RunningTests/Running#AdditionalPackages
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150406/5a96cbb6/attachment.html>

From thomasmiedema at gmail.com  Mon Apr  6 07:46:09 2015
From: thomasmiedema at gmail.com (Thomas Miedema)
Date: Mon, 6 Apr 2015 09:46:09 +0200
Subject: DPH tests
In-Reply-To: <CAAbahfTsxKg0QCkLZRN5wTjN9O8s_w5YZBxYj15k98tV7XFUDw@mail.gmail.com>
References: <CAAbahfTsxKg0QCkLZRN5wTjN9O8s_w5YZBxYj15k98tV7XFUDw@mail.gmail.com>
Message-ID: <CAD3WKgixWcPyveuiY+MVu8iJh8XOgq+BEnLSkMXNpZT-wc0dQg@mail.gmail.com>

Hi Konstantine,

thanks for investigating this. I updated the wiki by removing those
packages from the list.

The testsuite driver simply skips tests that depend on packages that are
not installed (dph-* in this case). I don't know what to about those tests
though, as dph is unmaintained and not in a working state.

I someone really wanted to, they could try building ghc with
`BUILD_DPH=yes` in build.mk, then `cd testsuite/tests/dph`, remove all
`reqlib` calls to the deprecated dph-* packages in the `.T` files, run
`make test`, and see what happens.

Please note that running the full testsuite in general results in lots of
failed tests. The continuous integration system only runs `make fasttest`.

Thomas

On Mon, Apr 6, 2015 at 8:52 AM, Konstantine Rybnikov <k-bx at k-bx.com> wrote:

> Hi!
>
> There?s ?Additional Packages? section [0] which lists packages that need
> to be installed in order to run full testsuite. But I couldn?t install
> dph-* ones, first errors I was getting were regular cabal-constraint ones.
> I wrote an author Ben Lippmeier, but he replied that dph-* packages were
> obsolete and not maintained anymore. I grepped and saw that all tests are
> under testsuite/dph folder. So: does GHC still run them at all? Should we
> edit wiki? Or edit test-suite?
>
> Thanks!
>
> [0]:
> https://ghc.haskell.org/trac/ghc/wiki/Building/RunningTests/Running#AdditionalPackages
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150406/5ac78dfd/attachment.html>

From simonpj at microsoft.com  Mon Apr  6 07:47:40 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 6 Apr 2015 07:47:40 +0000
Subject: Slower Compilation on GHC 7.8.4 (vs. 7.6.3)
In-Reply-To: <CAGn37G2cTGy88F-cHjFg9XEbDqaYqQetKR4iPqUnzT9DDXdWDQ@mail.gmail.com>
References: <CAGn37G2cTGy88F-cHjFg9XEbDqaYqQetKR4iPqUnzT9DDXdWDQ@mail.gmail.com>
Message-ID: <ed8f9b74b3c04ef0a7aa3baa566082a0@DB4PR30MB030.064d.mgd.msft.net>

Oz, and others,

Thanks for this data point.  Two things:


?         Oz: is there any chance you could boil out a test case that highlights the regression most starkly?  It is sad to know that GHC?s compilation time is increasing, but hard to tackle.  A test case, preferably one that doesn?t rely on zillions of other libraries, increases the chances of something getting done by a factor of 10 or 100.

Do make a ticket for it as well.  Otherwise it just gets lost.


?         Everyone.  It?s really hard to keep focus on keeping GHC?s compilation time and space down.  Everyone is usually focused on bugs and features.  It would be incredibly helpful if someone, or a small group, could build a profiled version of GHC 7.8, 7.10, and HEAD, and track down what is happening.  Usually there are multiple causes, but a factor of 7.5 ought not to be hard to nail down.


Please!

Thanks.

Simon

From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Ozgun Ataman
Sent: 05 April 2015 19:01
To: ghc-devs at haskell.org
Subject: Slower Compilation on GHC 7.8.4 (vs. 7.6.3)

Hello,

Apologies upfront for the long post below, but I thought our experience on this particular point might be worth sharing. I present some observations first and then mention the particular problem around "cabal repl" facilitated development workflow. Any ideas/feedback on the latter point would be much appreciated and please let me know if there are other metrics, info or output I can produce here for further investigation/clarification.

Recently at work, we upgraded a decent size project from GHC 7.6.3 to GHC 7.8.4 and as a result observed a very significant slowdown in compile times. Code changes were very minimal and should not be a factor. Any mistakes below are mine, but I can fairly confidently say that there is a visible-to-the-eye slowdown in compile times.

We made a few measurements to quantify the issue and here is the data:

  *   This project has 220 direct modules (non-dependency) that are compiled with each "cabal build" and we always use sandboxes
  *   Tests were performed on OS X, though we saw similar results on Linux
  *   Single threaded (-j=1) wall-clock compile time has gone up by around 30% for the overall project
  *   With O1 and -j=N, the overall wall-clock time is approximately the same (around 8 min), but the CPU time spent is a staggering 7.5X higher (!)
  *   With O0 and -j=N the overall wall-clock time is 40% higher, but the CPU time spent is a staggering 7.5X higher (!)
  *   With -O0, "cabal repl" load times have gone up by a staggering 2.5X (!)

     *   7.8.4: 3 min. 35 seconds
     *   7.6.3: 1 min. 2 seconds

  *   Measuring compile times for individual modules, we see that those that are heavily loaded with lots of types, TH-facilitated type and typeclass derivations and those that contain large "blobs" of values directly at the top level now take much longer to compile:

     *   We have 10 modules that each take over 10 seconds
     *   We have 3 modules that each take over 35 seconds

  *   Sidenote observation: In general, parallel builds with -j appear to cause a very significant overhead under the "system" part of timing:

     *   Example with 7.6.3, O0: cabal build  140.57s user 13.25s system 100% cpu 2:33.70 total
     *   Example with 7.8.4, O0: cabal build  507.83s user 655.43s system 549% cpu 3:31.59 total

The main hurt here has been the infeasibility of using "cabal repl / ghci"  fast-feedback style development (via emacs, vim, command-line, etc.), since:

  *   Unlike "cabal build", "cabal repl" re-compiles from scratch with every invocation ":l App.Foo.Bar", which itself is the necessary first step when starting to hack on a module (we can then use :r to somewhat help the situation)
  *   The slowdown is about 2.5X as stated above: What used to take a minute now takes 3.5 minutes.
  *   cabal repl does not seem to benefit from -j at all
  *   cabal repl 7.8.4 appears to be hurt particularly by the heavier modules
  *   The heavier modules are often at the top of the compile tree (types, derivations, etc) and are practically loaded on the critical path all the time
Let me know if I'm missing anything here and any/all feedback is much appreciated!

Cheers,
Oz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150406/a7d88c6f/attachment-0001.html>

From simonpj at microsoft.com  Mon Apr  6 09:00:17 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 6 Apr 2015 09:00:17 +0000
Subject: DynFlags.hs
In-Reply-To: <1427722251.1537.16.camel@joachim-breitner.de>
References: <20150330.222155.554427425406328754.kazu@iij.ad.jp>
 <1427722251.1537.16.camel@joachim-breitner.de>
Message-ID: <837be3e6465b4a3f909f7f42d654cc52@DB4PR30MB030.064d.mgd.msft.net>

And #7528 identifies that something non-linear is going on; and gives a test program "W2" to provoke it.

Might anyone be willing to investigate further?

Simon

|  -----Original Message-----
|  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Joachim
|  Breitner
|  Sent: 30 March 2015 14:31
|  To: ghc-devs at haskell.org
|  Subject: Re: DynFlags.hs
|  
|  Hi,
|  
|  Am Montag, den 30.03.2015, 22:21 +0900 schrieb Kazu Yamamoto:
|  > I cannot build GHC 7.10.1 on CentOS 6.5 whose memory is just 1G. This
|  > is because compiler/main/DynFlags.hs is huge. It would be nice if this
|  > file could be split.
|  
|  this has been reported as
|  https://ghc.haskell.org/trac/ghc/ticket/7258
|  
|  It would be great to be able to make the compiler cope with the file
|  gracefully, instead of working around the issue.
|  
|  Greetings,
|  Joachim
|  
|  --
|  Joachim ?nomeata? Breitner
|    mail at joachim-breitner.de ? http://www.joachim-breitner.de/
|    Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
|    Debian Developer: nomeata at debian.org

From eir at cis.upenn.edu  Mon Apr  6 10:39:46 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Mon, 6 Apr 2015 06:39:46 -0400
Subject: Slower Compilation on GHC 7.8.4 (vs. 7.6.3)
In-Reply-To: <ed8f9b74b3c04ef0a7aa3baa566082a0@DB4PR30MB030.064d.mgd.msft.net>
References: <CAGn37G2cTGy88F-cHjFg9XEbDqaYqQetKR4iPqUnzT9DDXdWDQ@mail.gmail.com>
 <ed8f9b74b3c04ef0a7aa3baa566082a0@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <C1EA4822-F84B-4B9D-B983-E5B678A906E8@cis.upenn.edu>

>  
> ?         Everyone.  It?s really hard to keep focus on keeping GHC?s compilation time and space down.  Everyone is usually focused on bugs and features.  It would be incredibly helpful if someone, or a small group, could build a profiled version of GHC 7.8, 7.10, and HEAD, and track down what is happening.  Usually there are multiple causes, but a factor of 7.5 ought not to be hard to nail down.
>  
> Please!

This is a great newcomer-to-ghc-hacking task. It's both relatively easy to do and gives a newcomer a chance to tour the codebase. The person doing the profiling doesn't also have to fix the bug. Just knowing what module or component of GHC is causing the trouble helps immensely.

As a further plug: when a change I made introduced a performance regression, I went into the debugging process very warily, expecting profiling GHC to be painful. It was just the opposite -- remarkably straightforward and able to produce results without terribly much effort. On the other hand, it does generally require having multiple (profiled) builds of GHC to get meaningful comparisons.

Thanks to whoever takes this on!

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150406/11425aac/attachment.html>

From carter.schonwald at gmail.com  Mon Apr  6 11:10:20 2015
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Mon, 6 Apr 2015 07:10:20 -0400
Subject: DPH tests
In-Reply-To: <CAD3WKgixWcPyveuiY+MVu8iJh8XOgq+BEnLSkMXNpZT-wc0dQg@mail.gmail.com>
References: <CAAbahfTsxKg0QCkLZRN5wTjN9O8s_w5YZBxYj15k98tV7XFUDw@mail.gmail.com>
 <CAD3WKgixWcPyveuiY+MVu8iJh8XOgq+BEnLSkMXNpZT-wc0dQg@mail.gmail.com>
Message-ID: <CAHYVw0yONgqXJ9mOTOr8vgWW131PJuCH=omLtnf3k79Ym2iP-g@mail.gmail.com>

Relatedly, might it be a good idea for at least the phab build bot tests to
enable stuff like the tests that use vector and other widely used packages?
On Apr 6, 2015 3:46 AM, "Thomas Miedema" <thomasmiedema at gmail.com> wrote:

> Hi Konstantine,
>
> thanks for investigating this. I updated the wiki by removing those
> packages from the list.
>
> The testsuite driver simply skips tests that depend on packages that are
> not installed (dph-* in this case). I don't know what to about those tests
> though, as dph is unmaintained and not in a working state.
>
> I someone really wanted to, they could try building ghc with
> `BUILD_DPH=yes` in build.mk, then `cd testsuite/tests/dph`, remove all
> `reqlib` calls to the deprecated dph-* packages in the `.T` files, run
> `make test`, and see what happens.
>
> Please note that running the full testsuite in general results in lots of
> failed tests. The continuous integration system only runs `make fasttest`.
>
> Thomas
>
> On Mon, Apr 6, 2015 at 8:52 AM, Konstantine Rybnikov <k-bx at k-bx.com>
> wrote:
>
>> Hi!
>>
>> There?s ?Additional Packages? section [0] which lists packages that need
>> to be installed in order to run full testsuite. But I couldn?t install
>> dph-* ones, first errors I was getting were regular cabal-constraint ones.
>> I wrote an author Ben Lippmeier, but he replied that dph-* packages were
>> obsolete and not maintained anymore. I grepped and saw that all tests are
>> under testsuite/dph folder. So: does GHC still run them at all? Should we
>> edit wiki? Or edit test-suite?
>>
>> Thanks!
>>
>> [0]:
>> https://ghc.haskell.org/trac/ghc/wiki/Building/RunningTests/Running#AdditionalPackages
>>
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150406/1e1fa8c4/attachment.html>

From k-bx at k-bx.com  Mon Apr  6 11:42:27 2015
From: k-bx at k-bx.com (Kostiantyn Rybnikov)
Date: Mon, 6 Apr 2015 14:42:27 +0300
Subject: DPH tests
In-Reply-To: <CAHYVw0yONgqXJ9mOTOr8vgWW131PJuCH=omLtnf3k79Ym2iP-g@mail.gmail.com>
References: <CAAbahfTsxKg0QCkLZRN5wTjN9O8s_w5YZBxYj15k98tV7XFUDw@mail.gmail.com>
 <CAD3WKgixWcPyveuiY+MVu8iJh8XOgq+BEnLSkMXNpZT-wc0dQg@mail.gmail.com>
 <CAHYVw0yONgqXJ9mOTOr8vgWW131PJuCH=omLtnf3k79Ym2iP-g@mail.gmail.com>
Message-ID: <CAAbahfQmLU5H5d4pKAXvL8vwttGZqCTfgRSjNcpG6mFnSWRRug@mail.gmail.com>

Would be a strong +1 from me, since it would mean:

1. We could script in the "Plan B" from here [0] and add it to default
"./validate" to have less work for people to either search via Wiki or get
recommendations in Trac tickets to notice these additional tests
2. We would notice things like currently-broken hmatrix installation and
previously-broken dph- ones immediately.
3. Dead-tests and dead-code is always an unfortunate thing to have.

[0]:
https://ghc.haskell.org/trac/ghc/wiki/Debugging/InstallingPackagesInplace

On Mon, Apr 6, 2015 at 2:10 PM, Carter Schonwald <carter.schonwald at gmail.com
> wrote:

> Relatedly, might it be a good idea for at least the phab build bot tests
> to enable stuff like the tests that use vector and other widely used
> packages?
> On Apr 6, 2015 3:46 AM, "Thomas Miedema" <thomasmiedema at gmail.com> wrote:
>
>> Hi Konstantine,
>>
>> thanks for investigating this. I updated the wiki by removing those
>> packages from the list.
>>
>> The testsuite driver simply skips tests that depend on packages that are
>> not installed (dph-* in this case). I don't know what to about those tests
>> though, as dph is unmaintained and not in a working state.
>>
>> I someone really wanted to, they could try building ghc with
>> `BUILD_DPH=yes` in build.mk, then `cd testsuite/tests/dph`, remove all
>> `reqlib` calls to the deprecated dph-* packages in the `.T` files, run
>> `make test`, and see what happens.
>>
>> Please note that running the full testsuite in general results in lots of
>> failed tests. The continuous integration system only runs `make fasttest`.
>>
>> Thomas
>>
>> On Mon, Apr 6, 2015 at 8:52 AM, Konstantine Rybnikov <k-bx at k-bx.com>
>> wrote:
>>
>>> Hi!
>>>
>>> There?s ?Additional Packages? section [0] which lists packages that need
>>> to be installed in order to run full testsuite. But I couldn?t install
>>> dph-* ones, first errors I was getting were regular cabal-constraint ones.
>>> I wrote an author Ben Lippmeier, but he replied that dph-* packages were
>>> obsolete and not maintained anymore. I grepped and saw that all tests are
>>> under testsuite/dph folder. So: does GHC still run them at all? Should we
>>> edit wiki? Or edit test-suite?
>>>
>>> Thanks!
>>>
>>> [0]:
>>> https://ghc.haskell.org/trac/ghc/wiki/Building/RunningTests/Running#AdditionalPackages
>>>
>>>
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>
>>>
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150406/3e31e7c6/attachment-0001.html>

From dpquigl at tycho.nsa.gov  Mon Apr  6 14:27:36 2015
From: dpquigl at tycho.nsa.gov (dpquigl)
Date: Mon, 06 Apr 2015 10:27:36 -0400
Subject: Use of GHC in Open Embedded Environments
Message-ID: <1428330456.15416.39.camel@tycho.nsa.gov>

Hello Everyone,

I sent a couple of private messages to Simon and he suggested I post to
the list instead to get more eyes on the problem.

I have been working for the better part of 3 days on trying to get GHC
to build within an Open Embedded environment. Open Embedded is used to
set up embedded build environments that are completely isolated from the
build  platform. The problem I'm encountering is due to the way GHC
builds its requiring the build and host platforms to be the same. I want
to create a GHC build where the build and host are different so I can
guarantee the isolation of the Haskell used to build our programs and
libraries on target. I looked extensively through the cross compilation
wiki page and even tried specifying paths into configure script to
specify the tools from within my toolchain to build with and I am still
running into problems. It seems that even if the top level makefile gets
configured properly the build environment for the modules created with
cabal under libraries do not retain any of that configuration
information.

The reason this is important is that I'm working on OpenXT which is a
recently Open Sources version of a product Citrix use to have called Xen
Client XT. The idea of OpenXT is that we use Xen to decompose what is
traditionally a monolithic system into several VMs which serve specific
purposes. For example we have the user interface for the platform which
manages things like sound levels and bringing up and shutting down VMs
into its own domain called the UI domain. We also separate out
networking into its own domain as well where the network card is mapped
exclusively into that domain and it manages creating and running virtual
network adapters for other VMs on the platform.

We use haskell in two different ways in this system. We personally want
to use OpenXT as a research platform and we have special purpose mini
domains for doing things like measurement and attestation and we have
components of these written in Haskell to do formal verification of the
domains. What OpenXT is using Haskell for directly is as part of its
management engine for the platform. We have a haskell and ocaml(just for
glue) based versions of metadata storage and platform management APIs.
Now when we build the platform we want to remove the dependency on the
host platform GHC version. We try to do this by building what would
essentially be a stage 1 compiler which will then be used to build the
runtime and tools used in the final platform VMs. The issue is that the
GHC build does not recognize the use case of host and build machines
being different. They expect host and build to be the same and target to
be different. Because of this even if we specify each component
individually on the configure line for the base GHC build when the build
gets to the point of building the libraries it seems to have this
information completely vanish. I think this is because it is using cabal
to build the libraries and cabal isn't taking into account that GHC is
built for a second platform and we want to build those libraries for
that same platform.

Dave


From rwbarton at gmail.com  Mon Apr  6 18:57:09 2015
From: rwbarton at gmail.com (Reid Barton)
Date: Mon, 6 Apr 2015 14:57:09 -0400
Subject: Use of GHC in Open Embedded Environments
In-Reply-To: <1428330456.15416.39.camel@tycho.nsa.gov>
References: <1428330456.15416.39.camel@tycho.nsa.gov>
Message-ID: <CADmwj44LmeDddLsUcvzQkTsDokX3WQt1GfKV0sCCg_7czDbZ-g@mail.gmail.com>

Hi Dave,

Have you seen https://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling?

In GHC's build system the build, host and target are relative to the stage1
compiler only, which will be a cross-compiler when host /= target.

Since the GHC ABI and interface file format can change arbitrarily between
different versions of GHC, programs built by the stage1 compiler must be
linked against libraries that were also built by the stage1 compiler (since
by definition the stage1 compiler is the first build of the new GHC
version). In order to build those libraries, the build system needs to be
able to run the stage1 compiler, which runs on host. So, either build must
equal host (which is what the GHC build system expects), or the build
system would have to somehow communicate with a second system of platform
host to build the libraries there.

However, if you also build the stage2 compiler, since it was built by the
stage1 compiler, which targets target, the stage2 compiler will be a native
compiler that runs on and targets target, and it will be capable of dynamic
code loading (ghci and Template Haskell). This is the most common thing to
want when building a compiler that runs on a platform other than the build
platform, though other configurations are (at least theoretically) possible.

We use haskell in two different ways in this system. We personally want
> to use OpenXT as a research platform and we have special purpose mini
> domains for doing things like measurement and attestation and we have
> components of these written in Haskell to do formal verification of the
> domains. What OpenXT is using Haskell for directly is as part of its
> management engine for the platform. We have a haskell and ocaml(just for
> glue) based versions of metadata storage and platform management APIs.
> Now when we build the platform we want to remove the dependency on the
> host platform GHC version. We try to do this by building what would
> essentially be a stage 1 compiler which will then be used to build the
> runtime and tools used in the final platform VMs. The issue is that the
> GHC build does not recognize the use case of host and build machines
> being different. They expect host and build to be the same and target to
> be different. Because of this even if we specify each component
> individually on the configure line for the base GHC build when the build
> gets to the point of building the libraries it seems to have this
> information completely vanish. I think this is because it is using cabal
> to build the libraries and cabal isn't taking into account that GHC is
> built for a second platform and we want to build those libraries for
> that same platform.
>

I have to say I don't follow what you are trying to do here. If your
question isn't already answered by now, could you be more specific, e.g. "a
stage-n compiler that is built on X, runs on Y and targets Z"? Even if X, Y
and Z are just opaque strings it would be helpful.

Since you mention removing the dependency on the host GHC version, maybe
you want to do an extra bootstrap stage, where instead of building (maybe
cross-compiling) the eventually desired version V with bootstrap compiler
B, you first build a native V compiler, then use that to bootstrap the
cross-compile. However, in theory the stage2 compiler should not depend at
all on the choice of bootstrap compiler.

Regards,
Reid Barton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150406/950a278d/attachment.html>

From ekmett at gmail.com  Tue Apr  7 00:58:41 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Mon, 6 Apr 2015 20:58:41 -0400
Subject: [haskell.org Google Summer of Code] Call for Mentors
Message-ID: <CAJumaK-w+ifov2KzvZVcfbRQAbiCLCzojODBeBCxA7+bfwGmRA@mail.gmail.com>

We have had a rather large pool of potential students apply for this year's
Google Summer of Code, but, ultimately, Google won't let us ask for a slot
unless we have a potential mentor assigned in advance.

On top of that, one thing we try to do with each project is wherever
possible, assign both a primary and a backup mentor, so the available
mentoring pool is drawn a little thin. Many hands make for light work,
though: If you've mentored or thought about mentoring in years past, I'd
encourage you to sign up on google-melange for the Google Summer of Code at:

https://www.google-melange.com/gsoc/homepage/google/gsoc2015

and request a connection to haskell.org as a Mentor.

Once you've done this you can help us vote on proposals, and should
something seem appropriate to you, you can flag yourself as available as a
potential mentor or backup mentor for one (or more) of the projects.

We have a couple of weeks left to rate proposals and request slots, but
it'd be good to make as much progress as we can this week.

If you have any questions, feel free to reach out to me, or to Shachaf
Ben-Kiki or Gershom Bazerman who have been helping out with organizational
issues this year. We also have a #haskell-gsoc channel on irc.freenode.net
if you have questions about what is involved.

Thank you for your time and consideration,
-Edward Kmett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150406/27e1e531/attachment.html>

From marlowsd at gmail.com  Tue Apr  7 19:39:47 2015
From: marlowsd at gmail.com (Simon Marlow)
Date: Tue, 07 Apr 2015 20:39:47 +0100
Subject: Slower Compilation on GHC 7.8.4 (vs. 7.6.3)
In-Reply-To: <CAGn37G2cTGy88F-cHjFg9XEbDqaYqQetKR4iPqUnzT9DDXdWDQ@mail.gmail.com>
References: <CAGn37G2cTGy88F-cHjFg9XEbDqaYqQetKR4iPqUnzT9DDXdWDQ@mail.gmail.com>
Message-ID: <55243283.3050506@gmail.com>

Just a comment on this one point:

On 05/04/2015 19:01, Ozgun Ataman wrote:
>   * With O0 and -j=N the overall wall-clock time is 40% higher, but the
>     CPU time spent is a staggering 7.5X higher (!)

When looking at Haskell programs executing in parallel, it's normal to 
see a high CPU time, because the GC threads spin looking for work.  The 
extra CPU time is just time spent spinning, it doesn't imply that the 
compiler was doing extra work.  What matters is the overall wall-clock 
time - a worse wall-clock time indicates that something has gone wrong.

We should look at compile-time regression independently of performance 
issues with -j.  Parallel compilation is a new feature and mostly likely 
needs a lot of tuning.  Note that cabal's -j feature is different from 
GHC's (and is likely to give much more reliable improvements) because it 
runs multiple compiler instances in parallel.

Cheers,
Simon


>   * With -O0, "cabal repl" load times have gone up by a staggering 2.5X (!)
>       o 7.8.4: 3 min. 35 seconds
>       o 7.6.3: 1 min. 2 seconds
>   * Measuring compile times for individual modules, we see that those
>     that are heavily loaded with lots of types, TH-facilitated type and
>     typeclass derivations and those that contain large "blobs" of values
>     directly at the top level now take much longer to compile:
>       o We have 10 modules that each take over 10 seconds
>       o We have 3 modules that each take over 35 seconds
>   * Sidenote observation: In general, parallel builds with -j appear to
>     cause a very significant overhead under the "system" part of timing:
>       o Example with 7.6.3, O0: cabal build  140.57s user 13.25s system
>         100% cpu 2:33.70 total
>       o Example with 7.8.4, O0: cabal build  507.83s user 655.43s system
>         549% cpu 3:31.59 total
>
>
> The main hurt here has been the infeasibility of using "cabal repl /
> ghci"  fast-feedback style development (via emacs, vim, command-line,
> etc.), since:
>
>   * Unlike "cabal build", "cabal repl" re-compiles from scratch with
>     every invocation ":l App.Foo.Bar", which itself is the necessary
>     first step when starting to hack on a module (we can then use :r to
>     somewhat help the situation)
>   * The slowdown is about 2.5X as stated above: What used to take a
>     minute now takes 3.5 minutes.
>   * cabal repl does not seem to benefit from -j at all
>   * cabal repl 7.8.4 appears to be hurt particularly by the heavier modules
>   * The heavier modules are often at the top of the compile tree (types,
>     derivations, etc) and are practically loaded on the critical path
>     all the time
>
> Let me know if I'm missing anything here and any/all feedback is much
> appreciated!
>
> Cheers,
> Oz
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>

From dan at kernelim.com  Tue Apr  7 20:33:42 2015
From: dan at kernelim.com (Dan Aloni)
Date: Tue, 7 Apr 2015 23:33:42 +0300
Subject: Toward better syntax errors
Message-ID: <20150407203342.GA12600@gmail.com>

Hello,

Forwarded here is a link to a blog post I authored about improving
GHC's syntax errors:

http://blog.aloni.org/posts/toward-better-ghc-syntax-errors/

In fact, this came about after I started using Happy more extensively,
and at one point thought that GHC could benefit too

The gist of it, is that it was relatively easy to reach an improvement
such as follows (notice 'possible tokens' below):


input:
--
test i = case i of 2
main = return ()


output:
--
example1.hs:2:1: parse error (possibly incorrect indentation or mismatched brackets), possible tokens: '|' '->'


It spawned a more extensive discussion regarding type errors here:

https://www.reddit.com/r/haskell/comments/31m7pc/toward_better_ghc_syntax_errors/

Following to that, it was suggested that a further discussion in the GHC
dev mailing list can continue about this direction (syntax errors,
type errors and whatnot).

--
Dan Aloni

From simonpj at microsoft.com  Tue Apr  7 20:51:47 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 7 Apr 2015 20:51:47 +0000
Subject: Validate problems on Windows
Message-ID: <521bc53b3abc48fb923d26d6f4f3f6d1@DB4PR30MB030.064d.mgd.msft.net>

Folks
I'm getting this stuff at the end of a validate run.
The test failures are at least understandable.  But what's all this "traceback" stuff from Python?  And "Warning:haddock-interfaces"?
Simon


Unexpected failures:

   ../../libraries/array/tests        T9220 [bad stdout] (ghci)

   ../../libraries/base/tests/System  Timeout001 [bad exit code] (normal)

   codeGen/should_compile             debug [bad exit code] (normal)

   ghc-e/should_fail                  T9930fail [bad exit code] (normal)

   ghci/linking                       T1407 [bad stderr] (ghci)

   ghci/scripts                       T5975a [bad stderr] (ghci)

   ghci/scripts                       T9878b [bad exit code] (ghci)

   rts                                T7037 [bad stdout] (normal)

   stranal/should_run                 T10148 [bad stderr] (optasm)



Unexpected stat failures:

   perf/compiler    T5030 [stat too good] (normal)

   perf/compiler    T5837 [stat too good] (normal)

   perf/compiler    T783 [stat not good enough] (normal)

   perf/compiler    T9872d [stat not good enough] (normal)

   perf/should_run  T9203 [stat not good enough] (normal)



Traceback (most recent call last):

  File "C:\code\HEAD\testsuite\driver\testlib.py", line 806, in do_test

    result = func(*[name,way] + args)

  File "C:\code\HEAD\testsuite\driver\testlib.py", line 1121, in stats

    return checkStats(name, way, stats_file, opts.stats_range_fields)

  File "C:\code\HEAD\testsuite\driver\testlib.py", line 1131, in checkStats

    f = open(in_testdir(stats_file))

IOError: [Errno 2] No such file or directory: './perf/haddock/../../../../libraries/base/dist-install/doc/html/base/base.haddock.t'

Traceback (most recent call last):

  File "C:\code\HEAD\testsuite\driver\testlib.py", line 806, in do_test

    result = func(*[name,way] + args)

  File "C:\code\HEAD\testsuite\driver\testlib.py", line 1121, in stats

    return checkStats(name, way, stats_file, opts.stats_range_fields)

  File "C:\code\HEAD\testsuite\driver\testlib.py", line 1131, in checkStats

    f = open(in_testdir(stats_file))

IOError: [Errno 2] No such file or directory: './perf/haddock/../../../../libraries/Cabal/Cabal/dist-install/doc/html/Cabal/Cabal.haddock.t'

Traceback (most recent call last):

  File "C:\code\HEAD\testsuite\driver\testlib.py", line 806, in do_test

    result = func(*[name,way] + args)

  File "C:\code\HEAD\testsuite\driver\testlib.py", line 1121, in stats

    return checkStats(name, way, stats_file, opts.stats_range_fields)

  File "C:\code\HEAD\testsuite\driver\testlib.py", line 1131, in checkStats

    f = open(in_testdir(stats_file))

IOError: [Errno 2] No such file or directory: './perf/haddock/../../../../compiler/stage2/doc/html/ghc/ghc.haddock.t'

make[2]: Leaving directory '/cygdrive/c/code/HEAD/testsuite/tests'

make[1]: Leaving directory '/cygdrive/c/code/HEAD/testsuite/tests'

== Start post-testsuite package check

Timestamp 2015-04-07 18:53:42 UTC for C:/code/HEAD/inplace\lib\package.conf.d\package.cache

Timestamp 2015-04-07 18:53:42 UTC for C:/code/HEAD/inplace\lib\package.conf.d (same as cache)

using cache: C:/code/HEAD/inplace\lib\package.conf.d\package.cache

db stack: ["C:\\Users\\simonpj\\AppData\\Roaming\\ghc\\i386-mingw32-7.11.20150407\\package.conf.d","C:/code/HEAD/inplace\\lib\\package.conf.d"]

modifying: Nothing

flag db stack: ["C:\\Users\\simonpj\\AppData\\Roaming\\ghc\\i386-mingw32-7.11.20150407\\package.conf.d","C:/code/HEAD/inplace\\lib\\package.conf.d"]

Warning: haddock-interfaces: C:\code\HEAD\libraries\stm\dist-install\doc\html\stm\stm.haddock doesn't exist or isn't a file

Warning: haddock-interfaces: C:\code\HEAD\libraries\parallel\dist-install\doc\html\parallel\parallel.haddock doesn't exist or isn't a file

Warning: haddock-interfaces: C:\code\HEAD\compiler\stage2\doc\html\ghc\ghc.haddock doesn't exist or isn't a file

Warning: haddock-interfaces: C:\code\HEAD\libraries\haskeline\dist-install\doc\html\haskeline\haskeline.haddock doesn't exist or isn't a file

Warning: haddock-interfaces: C:\code\HEAD\libraries\transformers\dist-install\doc\html\transformers\transformers.haddock doesn't exist or isn't a file

Warning: haddock-interfaces: C:\code\HEAD\libraries\hoopl\dist-install\doc\html\hoopl\hoopl.haddock doesn't exist or isn't a file

Warning: haddock-interfaces: C:\code\HEAD\libraries\bin-package-db\dist-install\doc\html\bin-package-db\bin-package-db.haddock doesn't exist or isn't a file

Warning: haddock-interfaces: C:\code\HEAD\libraries\Cabal\Cabal\dist-install\doc\html\Cabal\Cabal.haddock doesn't exist or isn't a file

Warning: haddock-interfaces: C:\code\HEAD\libraries\binary\dist-install\doc\html\binary\binary.haddock doesn't exist or isn't a file

Warning: haddock-interfaces: C:\code\HEAD\libraries\template-haskell\dist-install\doc\html\template-haskell\template-haskell.haddock doesn't exist or isn't a file

Warning: haddock-interfaces: C:\code\HEAD\libraries\pretty\dist-install\doc\html\pretty\pretty.haddock doesn't exist or isn't a file

Warning: haddock-interfaces: C:\code\HEAD\libraries\hpc\dist-install\doc\html\hpc\hpc.haddock doesn't exist or isn't a file

Warning: haddock-interfaces: C:\code\HEAD\libraries\process\dist-install\doc\html\process\process.haddock doesn't exist or isn't a file

Warning: haddock-interfaces: C:\code\HEAD\libraries\directory\dist-install\doc\html\directory\directory.haddock doesn't exist or isn't a file

Warning: haddock-interfaces: C:\code\HEAD\libraries\time\dist-install\doc\html\time\time.haddock doesn't exist or isn't a file

Warning: haddock-interfaces: C:\code\HEAD\libraries\Win32\dist-install\doc\html\Win32\Win32.haddock doesn't exist or isn't a file

Warning: haddock-interfaces: C:\code\HEAD\libraries\containers\dist-install\doc\html\containers\containers.haddock doesn't exist or isn't a file

Warning: haddock-interfaces: C:\code\HEAD\libraries\bytestring\dist-install\doc\html\bytestring\bytestring.haddock doesn't exist or isn't a file

Warning: haddock-interfaces: C:\code\HEAD\libraries\deepseq\dist-install\doc\html\deepseq\deepseq.haddock doesn't exist or isn't a file

Warning: haddock-interfaces: C:\code\HEAD\libraries\array\dist-install\doc\html\array\array.haddock doesn't exist or isn't a file

Warning: haddock-interfaces: C:\code\HEAD\libraries\filepath\dist-install\doc\html\filepath\filepath.haddock doesn't exist or isn't a file

Warning: haddock-interfaces: C:\code\HEAD\libraries\base\dist-install\doc\html\base\base.haddock doesn't exist or isn't a file

Warning: haddock-interfaces: C:\code\HEAD\libraries\integer-gmp\dist-install\doc\html\integer-gmp\integer-gmp.haddock doesn't exist or isn't a file

Warning: haddock-interfaces: C:\code\HEAD\libraries\ghc-prim\dist-install\doc\html\ghc-prim\ghc-prim.haddock doesn't exist or isn't a file

== End post-testsuite package check
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150407/b5baa004/attachment-0001.html>

From simonpj at microsoft.com  Tue Apr  7 22:11:07 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 7 Apr 2015 22:11:07 +0000
Subject: Toward better syntax errors
In-Reply-To: <20150407203342.GA12600@gmail.com>
References: <20150407203342.GA12600@gmail.com>
Message-ID: <c36ce9c06bfd4f6e92207e6ff44eaa88@DB4PR30MB030.064d.mgd.msft.net>

Thank Dan.  I'm keen on better error messages.

If you want to change Happy, though, you need talk to Simon Marlow.

Simon

| -----Original Message-----
| From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Dan
| Aloni
| Sent: 07 April 2015 21:34
| To: ghc-devs at haskell.org
| Subject: Toward better syntax errors
| 
| Hello,
| 
| Forwarded here is a link to a blog post I authored about improving
| GHC's syntax errors:
| 
| http://blog.aloni.org/posts/toward-better-ghc-syntax-errors/
| 
| In fact, this came about after I started using Happy more extensively,
| and at one point thought that GHC could benefit too
| 
| The gist of it, is that it was relatively easy to reach an improvement
| such as follows (notice 'possible tokens' below):
| 
| 
| input:
| --
| test i = case i of 2
| main = return ()
| 
| 
| output:
| --
| example1.hs:2:1: parse error (possibly incorrect indentation or
| mismatched brackets), possible tokens: '|' '->'
| 
| 
| It spawned a more extensive discussion regarding type errors here:
| 
| https://www.reddit.com/r/haskell/comments/31m7pc/toward_better_ghc_syntax
| _errors/
| 
| Following to that, it was suggested that a further discussion in the GHC
| dev mailing list can continue about this direction (syntax errors,
| type errors and whatnot).
| 
| --
| Dan Aloni
| _______________________________________________
| ghc-devs mailing list
| ghc-devs at haskell.org
| http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From dan at kernelim.com  Wed Apr  8 04:44:15 2015
From: dan at kernelim.com (Dan Aloni)
Date: Wed, 8 Apr 2015 07:44:15 +0300
Subject: Toward better syntax errors
In-Reply-To: <c36ce9c06bfd4f6e92207e6ff44eaa88@DB4PR30MB030.064d.mgd.msft.net>
References: <20150407203342.GA12600@gmail.com>
 <c36ce9c06bfd4f6e92207e6ff44eaa88@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <20150408044415.GA21744@gmail.com>

On Tue, Apr 07, 2015 at 10:11:07PM +0000, Simon Peyton Jones wrote:
> Thank Dan.  I'm keen on better error messages.
> 
> If you want to change Happy, though, you need talk to Simon Marlow.

Definitely, and there has been already a pull request recently open
inthe Happy github repo. The mailing list is a better platform for
discussions though :)

-- 
Dan Aloni

From alan.zimm at gmail.com  Wed Apr  8 10:10:54 2015
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Wed, 8 Apr 2015 12:10:54 +0200
Subject: Flurry of late patches for 7.10.2
Message-ID: <CANma=H8nk6-BRC4bwTi2gBfmg4i8PgHPObLZLrni5RhtJ61dVg@mail.gmail.com>

You may have noticed that I have submitted a lot of patches for the 7.10.2
release at a very
 late stage.

I apologise for this, but it has been triggered by an exciting test
conducted by Matt Pickering
 using the new ghc-exactprint[1] based on the API Annotations in 7.10.1

He ran it in round-trip mode over all the source files in hackage, with the
following results

Total: 62,741 files.
Parse fails: 6,611
CPP: 4,487 (not currently processed, coming soon)

So the total succesfully processed was 51,643 files.

Of these,  3,042 failed to reproduce the source exactly.

The patches coming in are to bring the 3,042 count down even further.

Regards
  Alan

[1]  https://github.com/alanz/ghc-exactprint
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150408/e5613696/attachment.html>

From simonpj at microsoft.com  Thu Apr  9 07:56:53 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 9 Apr 2015 07:56:53 +0000
Subject: Generalized Newtype Deriving not allowed in Safe	Haskell
In-Reply-To: <CAL2jp559kvXbd3MxEC0Zrg8dzFrUbSYVMwzky3-oHMjKATurDA@mail.gmail.com>
References: <CAL2jp559kvXbd3MxEC0Zrg8dzFrUbSYVMwzky3-oHMjKATurDA@mail.gmail.com>
Message-ID: <0d913dcca48b47abadb7ab6b4125b906@DB4PR30MB030.064d.mgd.msft.net>

There is a long discussion on https://ghc.haskell.org/trac/ghc/ticket/8827 about whether the new Coercible story makes GND ok for Safe Haskell.  At a type-soundness level, definitely yes.  But there are other less-clear-cut issues like ?breaking abstractions? to consider.  The decision on the ticket (comment:36) seems to be: GND stays out of Safe Haskell for now, but there is room for a better proposal.

I don?t have an opinion myself. David Terei and David Mazieres are in the driving seat, but I?m sure they?ll be responsive to user input.

However, I think the user manual may not have kept up with #8827.  The sentence ?GeneralizedNewtypeDeriving ? It can be used to violate constructor access control, by allowing untrusted code to manipulate protected data types in ways the data type author did not intend, breaking invariants they have established.?  vanished from the 7.8 user manual (links below).  Maybe it should be restored.

Safe Haskell aficionados, would you like to offer a patch for the manual?  And maybe also a less drastic remedy than omitting GND altogether?

Simon

From: Omari Norman [mailto:omari at smileystation.com]
Sent: 09 April 2015 02:44
To: haskell Cafe
Subject: Generalized Newtype Deriving not allowed in Safe Haskell

When compiling code with Generalized Newtype Deriving and the -fwarn-unsafe flag, I get


-XGeneralizedNewtypeDeriving is not allowed in Safe Haskell



This happens both in GHC 7.8 and GHC 7.10.



I thought I remembered reading somewhere that GNTD is now part of the safe language?  The GHC manual used to state that GNTD is not allowed in Safe Haskell:



https://downloads.haskell.org/~ghc/7.6.3/docs/html/users_guide/safe-haskell.html#safe-language



But this language on GNTD not being part of the safe language was removed in the 7.8 manual:



https://downloads.haskell.org/~ghc/7.8.2/docs/html/users_guide/safe-haskell.html#safe-language



The GHC release notes don't say anything about this one way or the other.  Thoughts?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150409/74460448/attachment.html>

From alan.zimm at gmail.com  Thu Apr  9 08:30:23 2015
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Thu, 9 Apr 2015 10:30:23 +0200
Subject: Where are the HsTyVarBndrs collapsed in an explicit HsForAllTy?
Message-ID: <CANma=H-1P_gz6r8heK2BzT5KQe730D3Osy_GD=yLCvUf98O5hw@mail.gmail.com>

When parsing

    extremumNewton :: (Eq a, Fractional a) =>
                  (forall tag. forall tag1.
                          Tower tag1 (Tower tag a)
                              -> Tower tag1 (Tower tag a))
                      -> a -> [a]

the nested `forall` declarations are parsed by

    ctypedoc :: { LHsType RdrName }
            : 'forall' tv_bndrs '.' ctypedoc {% hintExplicitForall (getLoc
$1) >>
                                                ams (sLL $1 $> $
mkExplicitHsForAllTy $2

(noLoc []) $4)
                                                    [mj AnnForall $1,mj
AnnDot $3] }

This generates a HsForAllTy for the first forall that simply wraps the
second one, which is also a `ctypedoc`.

But, when looking at the AST provided via ParsedSource, the two `forall`s
are collapsed into a single one, containing both `tag` and `tag1` in the
TyVarBndrs.

In the process the annotation for the second forall loses its anchor, as
that span is no longer in the AST.

I cannot find where this collapsing takes place, can  anyone point me at it?

Thanks
  Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150409/828a830c/attachment.html>

From lonetiger at gmail.com  Thu Apr  9 18:14:26 2015
From: lonetiger at gmail.com (=?utf-8?Q?Tamar_Christina?=)
Date: Thu, 9 Apr 2015 18:14:26 +0000
Subject: =?utf-8?Q?Advice_on_replacing_ghc-split?=
Message-ID: <5526c35e.aa3dc20a.30d8.ffffea11@mx.google.com>

Hi All,


I have been working on creating a Haskell replacement for the perl script ghc-split.


The issue I need some advice on is that the perl script is 280 SLOC primarily because of the use of RegExpr.

The problem I have is that It seems i?m limited to only packages that are available already because GHC needs them (since it seems to compile using the in-place cabal and pkg list, am I correct here?).


So I see my options as follows:


Inline one of the regexp libraries, e.g. pcre-light


Create my own string matching functions (possibly a simple DFA and encode the rexexpr into that)


Use parsec (which I think is available as part of the ghc build no?)



Does anyone have an idea on what the best approach would be?


The regexpr don?t seem to use any perl extensions, so normal posix regex would be fine, I thought Base contained a regexp component. But it seems that?s now a separate library?


Kind Regards,

Tamar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150409/e9a26e23/attachment.html>

From the.dead.shall.rise at gmail.com  Thu Apr  9 20:56:50 2015
From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov)
Date: Thu, 9 Apr 2015 22:56:50 +0200
Subject: Advice on replacing ghc-split
In-Reply-To: <5526c35e.aa3dc20a.30d8.ffffea11@mx.google.com>
References: <5526c35e.aa3dc20a.30d8.ffffea11@mx.google.com>
Message-ID: <CA+tcxkBybhhcTanH1AJrmDHLddUFT8+kSA7qwCqnnNhHeTc3rQ@mail.gmail.com>

Hi,

On 9 April 2015 at 20:14, Tamar Christina <lonetiger at gmail.com> wrote:
> [...]
>
> So I see my options as follows:
>
> Inline one of the regexp libraries, e.g. pcre-light
> [...]

When LLVM developers were faced with a similar issue [1], they decided
to use OpenBSD's regex implementation [2,3].

[1] http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-August/025047.html
[2] http://llvm.org/docs/doxygen/html/regexec_8c_source.html
[3] http://llvm.org/docs/doxygen/html/classllvm_1_1Regex.html

From alan.zimm at gmail.com  Thu Apr  9 21:15:15 2015
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Thu, 9 Apr 2015 23:15:15 +0200
Subject: Collapsing HsForAllTy, again
Message-ID: <CANma=H-o2Po6Y4XHYMLmU7VAAbFWb-jU2nW7O_0D96kDzjcy+A@mail.gmail.com>

With the help of Jan Stolarek I tracked down the HsForAllTy flattening to
 `HsTypes.mk_forall_ty`.

This function takes any nested HsForAllTy's where the top one does not have
a context defined, and collapses them into a single one.

I do not know what the motivation for this is, and if it perhaps speeds up
or simplifies further compilation.

But now that API Annotations have arrived, making sure we do not lose the
annotations for the sub-HsForAllTy  causes significant gymnastics in the
parser [1].

So my question is, is there a good reason to continue doing this, given the
trade-off in parser complexity.

Regards
  Alan

[1]  https://phabricator.haskell.org/D833
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150409/4f9c504d/attachment.html>

From simonpj at microsoft.com  Thu Apr  9 22:14:02 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 9 Apr 2015 22:14:02 +0000
Subject: Collapsing HsForAllTy, again
In-Reply-To: <CANma=H-o2Po6Y4XHYMLmU7VAAbFWb-jU2nW7O_0D96kDzjcy+A@mail.gmail.com>
References: <CANma=H-o2Po6Y4XHYMLmU7VAAbFWb-jU2nW7O_0D96kDzjcy+A@mail.gmail.com>
Message-ID: <1a73fdbf3b174e9381d6c70324eb159c@DB4PR30MB030.064d.mgd.msft.net>

Hmm.  I?m not sure what the motivation is either.  Try dropping it out and see if anything goes wrong.

Simon

From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Alan & Kim Zimmerman
Sent: 09 April 2015 22:15
To: ghc-devs at haskell.org
Subject: Collapsing HsForAllTy, again

With the help of Jan Stolarek I tracked down the HsForAllTy flattening to
 `HsTypes.mk_forall_ty`.
This function takes any nested HsForAllTy's where the top one does not have a context defined, and collapses them into a single one.
I do not know what the motivation for this is, and if it perhaps speeds up or simplifies further compilation.
But now that API Annotations have arrived, making sure we do not lose the annotations for the sub-HsForAllTy  causes significant gymnastics in the parser [1].
So my question is, is there a good reason to continue doing this, given the trade-off in parser complexity.
Regards
  Alan
[1]  https://phabricator.haskell.org/D833

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150409/3426202b/attachment-0001.html>

From lonetiger at gmail.com  Fri Apr 10 03:32:35 2015
From: lonetiger at gmail.com (Tamar Christina)
Date: Thu, 9 Apr 2015 20:32:35 -0700
Subject: Advice on replacing ghc-split
Message-ID: <7940687690104868991@unknownmsgid>

Thanks Mikhail,

I'll read through the threads.

Cheers,
TamarFrom: Mikhail Glushenkov
Sent: ?09/?04/?2015 22:56
To: Tamar Christina
Cc: GHC
Subject: Re: Advice on replacing ghc-split
Hi,

On 9 April 2015 at 20:14, Tamar Christina <lonetiger at gmail.com> wrote:
> [...]
>
> So I see my options as follows:
>
> Inline one of the regexp libraries, e.g. pcre-light
> [...]

When LLVM developers were faced with a similar issue [1], they decided
to use OpenBSD's regex implementation [2,3].

[1] http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-August/025047.html
[2] http://llvm.org/docs/doxygen/html/regexec_8c_source.html
[3] http://llvm.org/docs/doxygen/html/classllvm_1_1Regex.html

From alan.zimm at gmail.com  Fri Apr 10 07:01:52 2015
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Fri, 10 Apr 2015 09:01:52 +0200
Subject: Collapsing HsForAllTy, again
In-Reply-To: <1a73fdbf3b174e9381d6c70324eb159c@DB4PR30MB030.064d.mgd.msft.net>
References: <CANma=H-o2Po6Y4XHYMLmU7VAAbFWb-jU2nW7O_0D96kDzjcy+A@mail.gmail.com>
 <1a73fdbf3b174e9381d6c70324eb159c@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <CANma=H8OSKLTFc+0E10Mkzct8GSwfqGxt5juyifFkP5uOYhNHA@mail.gmail.com>

If I replace it with


mkHsForAllTy :: HsExplicitFlag -> [LHsTyVarBndr RdrName] -> LHsContext
RdrName -> LHsType RdrName -> HsType RdrName
-- Smart constructor for HsForAllTy
-- mkHsForAllTy exp tvs (L _ []) ty = mk_forall_ty exp tvs ty
mkHsForAllTy exp tvs (L _ []) ty = HsForAllTy exp Nothing (mkHsQTvs tvs) (L
noSrcSpan []) ty
mkHsForAllTy exp tvs ctxt     ty = HsForAllTy exp extra   (mkHsQTvs tvs)
cleanCtxt        ty
  where -- Separate the extra-constraints wildcard when present
        (cleanCtxt, extra)
          | (L l HsWildcardTy) <- ignoreParens (last (unLoc ctxt)) = (init
`fmap` ctxt, Just l)
          | otherwise = (ctxt, Nothing)
        ignoreParens (L _ (HsParTy ty)) = ty -- TODO:AZ We lose the
annotation here
        ignoreParens ty                 = ty


I get the following errors in the stage 2 compile (only first 3 shown here)


libraries/ghc-prim/GHC/Classes.hs:52:19:
    Malformed instance: (Eq a, Eq b) => Eq (a, b)

libraries/ghc-prim/GHC/Classes.hs:53:19:
    Malformed instance: (Eq a, Eq b, Eq c) => Eq (a, b, c)

libraries/ghc-prim/GHC/Classes.hs:54:19:
    Malformed instance: (Eq a, Eq b, Eq c, Eq d) => Eq (a, b, c, d)



Alan

On Fri, Apr 10, 2015 at 12:14 AM, Simon Peyton Jones <simonpj at microsoft.com>
wrote:

>  Hmm.  I?m not sure what the motivation is either.  Try dropping it out
> and see if anything goes wrong.
>
>
> Simon
>
>
>
> *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Alan
> & Kim Zimmerman
> *Sent:* 09 April 2015 22:15
> *To:* ghc-devs at haskell.org
> *Subject:* Collapsing HsForAllTy, again
>
>
>
> With the help of Jan Stolarek I tracked down the HsForAllTy flattening to
>  `HsTypes.mk_forall_ty`.
>
> This function takes any nested HsForAllTy's where the top one does not
> have a context defined, and collapses them into a single one.
>
> I do not know what the motivation for this is, and if it perhaps speeds up
> or simplifies further compilation.
>
> But now that API Annotations have arrived, making sure we do not lose the
> annotations for the sub-HsForAllTy  causes significant gymnastics in the
> parser [1].
>
> So my question is, is there a good reason to continue doing this, given
> the trade-off in parser complexity.
>
> Regards
>
>   Alan
>
> [1]  https://phabricator.haskell.org/D833
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150410/87387e56/attachment.html>

From simonpj at microsoft.com  Fri Apr 10 08:13:53 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 10 Apr 2015 08:13:53 +0000
Subject: Collapsing HsForAllTy, again
In-Reply-To: <CANma=H8OSKLTFc+0E10Mkzct8GSwfqGxt5juyifFkP5uOYhNHA@mail.gmail.com>
References: <CANma=H-o2Po6Y4XHYMLmU7VAAbFWb-jU2nW7O_0D96kDzjcy+A@mail.gmail.com>
 <1a73fdbf3b174e9381d6c70324eb159c@DB4PR30MB030.064d.mgd.msft.net>
 <CANma=H8OSKLTFc+0E10Mkzct8GSwfqGxt5juyifFkP5uOYhNHA@mail.gmail.com>
Message-ID: <d0e3d69511a1489da10848b7c154b145@DB4PR30MB030.064d.mgd.msft.net>

Look at how instance declarations are parsed. If you look at Parser.y you?ll see that for


instance (Eq a, Eq b) => Eq (a,b)

we get (in effect)


mkImplicitHsForAllTy (mkQualifiedHsForAllTy (Eq a, Eq b) (Eq (a,b))

The outer mkImplicit.. is to ensure that there is always, in the end, a HsForAllTy around the whole thing, even around

instance Eq a
say.

But we don?t actually want two nested HsForAllTys.  mk_forall_ty collapsed the two.

But you don?t want that either.  So I think you should make mkImplictHsForAllTy do the test instead.  Its goal is to wrap a HsForallTy if there isn?t one already. So


mkImplicitHsForAllTy (HsForAllTy exp tvs cxt ty)

  = HsForAllTy exp? tvs cxt ty

  where

    exp? = case exp of

             Qualified -> Implicit

             _         -> exp

mkImplicitHsForAllTy ty = mkHsForAllTy Implicit  []  (L loc _) ty

should do the job.

Incidentally, mkImplicitHsForAllTy should not take a ctxt argument.  If you have a non-empty context, use mkQualifiedHsForAllTy.  That means that in Convert you?ll need to use
   mkHsForAllTy Implicit ctxt ty?
instead of mkImplicitHsForAllTy

Simon

From: Alan & Kim Zimmerman [mailto:alan.zimm at gmail.com]
Sent: 10 April 2015 08:02
To: Simon Peyton Jones
Cc: ghc-devs at haskell.org
Subject: Re: Collapsing HsForAllTy, again

If I replace it with


mkHsForAllTy :: HsExplicitFlag -> [LHsTyVarBndr RdrName] -> LHsContext RdrName -> LHsType RdrName -> HsType RdrName
-- Smart constructor for HsForAllTy
-- mkHsForAllTy exp tvs (L _ []) ty = mk_forall_ty exp tvs ty
mkHsForAllTy exp tvs (L _ []) ty = HsForAllTy exp Nothing (mkHsQTvs tvs) (L noSrcSpan []) ty
mkHsForAllTy exp tvs ctxt     ty = HsForAllTy exp extra   (mkHsQTvs tvs) cleanCtxt        ty
  where -- Separate the extra-constraints wildcard when present
        (cleanCtxt, extra)
          | (L l HsWildcardTy) <- ignoreParens (last (unLoc ctxt)) = (init `fmap` ctxt, Just l)
          | otherwise = (ctxt, Nothing)
        ignoreParens (L _ (HsParTy ty)) = ty -- TODO:AZ We lose the annotation here
        ignoreParens ty                 = ty

I get the following errors in the stage 2 compile (only first 3 shown here)


libraries/ghc-prim/GHC/Classes.hs:52:19:
    Malformed instance: (Eq a, Eq b) => Eq (a, b)

libraries/ghc-prim/GHC/Classes.hs:53:19:
    Malformed instance: (Eq a, Eq b, Eq c) => Eq (a, b, c)

libraries/ghc-prim/GHC/Classes.hs:54:19:
    Malformed instance: (Eq a, Eq b, Eq c, Eq d) => Eq (a, b, c, d)


Alan

On Fri, Apr 10, 2015 at 12:14 AM, Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
Hmm.  I?m not sure what the motivation is either.  Try dropping it out and see if anything goes wrong.

Simon

From: ghc-devs [mailto:ghc-devs-bounces at haskell.org<mailto:ghc-devs-bounces at haskell.org>] On Behalf Of Alan & Kim Zimmerman
Sent: 09 April 2015 22:15
To: ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
Subject: Collapsing HsForAllTy, again

With the help of Jan Stolarek I tracked down the HsForAllTy flattening to
 `HsTypes.mk_forall_ty`.
This function takes any nested HsForAllTy's where the top one does not have a context defined, and collapses them into a single one.
I do not know what the motivation for this is, and if it perhaps speeds up or simplifies further compilation.
But now that API Annotations have arrived, making sure we do not lose the annotations for the sub-HsForAllTy  causes significant gymnastics in the parser [1].
So my question is, is there a good reason to continue doing this, given the trade-off in parser complexity.
Regards
  Alan
[1]  https://phabricator.haskell.org/D833


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150410/cae6aab9/attachment-0001.html>

From dave.terei at gmail.com  Fri Apr 10 08:37:57 2015
From: dave.terei at gmail.com (David Terei)
Date: Fri, 10 Apr 2015 01:37:57 -0700
Subject: Generalized Newtype Deriving not allowed in Safe Haskell
In-Reply-To: <0d913dcca48b47abadb7ab6b4125b906@DB4PR30MB030.064d.mgd.msft.net>
References: <CAL2jp559kvXbd3MxEC0Zrg8dzFrUbSYVMwzky3-oHMjKATurDA@mail.gmail.com>
 <0d913dcca48b47abadb7ab6b4125b906@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <CACHt1w8Mc_LoZaACO-sPvWxMwragP35bfKL2cz+_GD4tF24OOg@mail.gmail.com>

I'll prepare a patch for the userguide soon.

As for something better, yes I think we can and should. It's on my
todo list :) Basically, the new-GND design has all the mechanisms to
be safe, but sadly the defaults are rather worrying. Without explicit
annotations from the user, module abstractions are broken. This is why
we left GND out of Safe Haskell for the moment as it is a subtle and
easy mistake to make.

If the module contained explicit role annotations then it could be
allowed. The discussion in
https://ghc.haskell.org/trac/ghc/ticket/8827 has other solutions that
I prefer, such as only exporting the Coerce instance if all the
constructors are exported, it seems that the ship sailed on these
bigger changes sadly.

Cheers,
David

On 9 April 2015 at 00:56, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> There is a long discussion on https://ghc.haskell.org/trac/ghc/ticket/8827
> about whether the new Coercible story makes GND ok for Safe Haskell.  At a
> type-soundness level, definitely yes.  But there are other less-clear-cut
> issues like ?breaking abstractions? to consider.  The decision on the ticket
> (comment:36) seems to be: GND stays out of Safe Haskell for now, but there
> is room for a better proposal.
>
>
>
> I don?t have an opinion myself. David Terei and David Mazieres are in the
> driving seat, but I?m sure they?ll be responsive to user input.
>
>
>
> However, I think the user manual may not have kept up with #8827.  The
> sentence ?GeneralizedNewtypeDeriving ? It can be used to violate constructor
> access control, by allowing untrusted code to manipulate protected data
> types in ways the data type author did not intend, breaking invariants they
> have established.?  vanished from the 7.8 user manual (links below).  Maybe
> it should be restored.
>
>
>
> Safe Haskell aficionados, would you like to offer a patch for the manual?
> And maybe also a less drastic remedy than omitting GND altogether?
>
>
>
> Simon
>
>
>
> From: Omari Norman [mailto:omari at smileystation.com]
> Sent: 09 April 2015 02:44
> To: haskell Cafe
> Subject: Generalized Newtype Deriving not allowed in Safe Haskell
>
>
>
> When compiling code with Generalized Newtype Deriving and the -fwarn-unsafe
> flag, I get
>
>
>
> -XGeneralizedNewtypeDeriving is not allowed in Safe Haskell
>
>
>
> This happens both in GHC 7.8 and GHC 7.10.
>
>
>
> I thought I remembered reading somewhere that GNTD is now part of the safe
> language?  The GHC manual used to state that GNTD is not allowed in Safe
> Haskell:
>
>
>
> https://downloads.haskell.org/~ghc/7.6.3/docs/html/users_guide/safe-haskell.html#safe-language
>
>
>
> But this language on GNTD not being part of the safe language was removed in
> the 7.8 manual:
>
>
>
> https://downloads.haskell.org/~ghc/7.8.2/docs/html/users_guide/safe-haskell.html#safe-language
>
>
>
> The GHC release notes don't say anything about this one way or the other.
> Thoughts?
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>

From simonpj at microsoft.com  Fri Apr 10 08:48:52 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 10 Apr 2015 08:48:52 +0000
Subject: Generalized Newtype Deriving not allowed in Safe Haskell
In-Reply-To: <CACHt1w8Mc_LoZaACO-sPvWxMwragP35bfKL2cz+_GD4tF24OOg@mail.gmail.com>
References: <CAL2jp559kvXbd3MxEC0Zrg8dzFrUbSYVMwzky3-oHMjKATurDA@mail.gmail.com>
 <0d913dcca48b47abadb7ab6b4125b906@DB4PR30MB030.064d.mgd.msft.net>
 <CACHt1w8Mc_LoZaACO-sPvWxMwragP35bfKL2cz+_GD4tF24OOg@mail.gmail.com>
Message-ID: <ee5348affe8f498bbbd8c3660591932c@DB4PR30MB030.064d.mgd.msft.net>

|  prefer, such as only exporting the Coerce instance if all the
|  constructors are exported, it seems that the ship sailed on these

Coercible is relatively recent; I don't think we should regard it as cast in stone.

But yes, the Coerbible instance of a newtype is only available when the data constructor for the newtype is lexically in scope.

Simon

|  -----Original Message-----
|  From: davidterei at gmail.com [mailto:davidterei at gmail.com] On Behalf Of
|  David Terei
|  Sent: 10 April 2015 09:38
|  To: Simon Peyton Jones
|  Cc: Omari Norman; haskell Cafe; ghc-devs at haskell.org
|  Subject: Re: Generalized Newtype Deriving not allowed in Safe Haskell
|  
|  I'll prepare a patch for the userguide soon.
|  
|  As for something better, yes I think we can and should. It's on my todo
|  list :) Basically, the new-GND design has all the mechanisms to be
|  safe, but sadly the defaults are rather worrying. Without explicit
|  annotations from the user, module abstractions are broken. This is why
|  we left GND out of Safe Haskell for the moment as it is a subtle and
|  easy mistake to make.
|  
|  If the module contained explicit role annotations then it could be
|  allowed. The discussion in
|  https://ghc.haskell.org/trac/ghc/ticket/8827 has other solutions that I
|  prefer, such as only exporting the Coerce instance if all the
|  constructors are exported, it seems that the ship sailed on these
|  bigger changes sadly.
|  
|  Cheers,
|  David
|  
|  On 9 April 2015 at 00:56, Simon Peyton Jones <simonpj at microsoft.com>
|  wrote:
|  > There is a long discussion on
|  > https://ghc.haskell.org/trac/ghc/ticket/8827
|  > about whether the new Coercible story makes GND ok for Safe Haskell.
|  > At a type-soundness level, definitely yes.  But there are other
|  > less-clear-cut issues like ?breaking abstractions? to consider.  The
|  > decision on the ticket
|  > (comment:36) seems to be: GND stays out of Safe Haskell for now, but
|  > there is room for a better proposal.
|  >
|  >
|  >
|  > I don?t have an opinion myself. David Terei and David Mazieres are in
|  > the driving seat, but I?m sure they?ll be responsive to user input.
|  >
|  >
|  >
|  > However, I think the user manual may not have kept up with #8827.
|  The
|  > sentence ?GeneralizedNewtypeDeriving ? It can be used to violate
|  > constructor access control, by allowing untrusted code to manipulate
|  > protected data types in ways the data type author did not intend,
|  > breaking invariants they have established.?  vanished from the 7.8
|  > user manual (links below).  Maybe it should be restored.
|  >
|  >
|  >
|  > Safe Haskell aficionados, would you like to offer a patch for the
|  manual?
|  > And maybe also a less drastic remedy than omitting GND altogether?
|  >
|  >
|  >
|  > Simon
|  >
|  >
|  >
|  > From: Omari Norman [mailto:omari at smileystation.com]
|  > Sent: 09 April 2015 02:44
|  > To: haskell Cafe
|  > Subject: Generalized Newtype Deriving not allowed in Safe Haskell
|  >
|  >
|  >
|  > When compiling code with Generalized Newtype Deriving and the
|  > -fwarn-unsafe flag, I get
|  >
|  >
|  >
|  > -XGeneralizedNewtypeDeriving is not allowed in Safe Haskell
|  >
|  >
|  >
|  > This happens both in GHC 7.8 and GHC 7.10.
|  >
|  >
|  >
|  > I thought I remembered reading somewhere that GNTD is now part of the
|  > safe language?  The GHC manual used to state that GNTD is not allowed
|  > in Safe
|  > Haskell:
|  >
|  >
|  >
|  > https://downloads.haskell.org/~ghc/7.6.3/docs/html/users_guide/safe-
|  ha
|  > skell.html#safe-language
|  >
|  >
|  >
|  > But this language on GNTD not being part of the safe language was
|  > removed in the 7.8 manual:
|  >
|  >
|  >
|  > https://downloads.haskell.org/~ghc/7.8.2/docs/html/users_guide/safe-
|  ha
|  > skell.html#safe-language
|  >
|  >
|  >
|  > The GHC release notes don't say anything about this one way or the
|  other.
|  > Thoughts?
|  >
|  >
|  > _______________________________________________
|  > ghc-devs mailing list
|  > ghc-devs at haskell.org
|  > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
|  >

From alan.zimm at gmail.com  Fri Apr 10 09:30:21 2015
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Fri, 10 Apr 2015 11:30:21 +0200
Subject: API Annotations, MINIMAL pragma and BooleanFormula
Message-ID: <CANma=H_Msxfx=06tJ2ha7w9O5Bkg+b8waLUGNGhCzgGcNcVpsg@mail.gmail.com>

My last (known) issue is the MINIMAL pragma for a class definition.

In Parser.y this is captured (via `name_boolformula`) as a

  BooleanFormula (Located RdrName)

There is a problem with this from an API annotations point of view in that
the constructors (mkBool,mkAnd,mkOr) are smart and try to minimise the
boolean formula as it is constructed.

Unfortunately this discards information in the process.

I see a number of potential solutions

a. Capture the original source string for the pragma, and use that for the
annotations. This is a bad option.

b. Introduce a new variant of BooleanFormula for the AST, and convert to
use the current one when evaluating the pragma.

c. Keep the BooleanFormula as it is, but do not minimise the formula on
construction.

I suspect that c is the best option, I do not believe the formulas
constructed are particularly complex or numerous, so early optimisation is
not necessary.

Which is the best option? Or is there a different one?

Regards
  Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150410/db72da6b/attachment.html>

From alan.zimm at gmail.com  Fri Apr 10 11:11:48 2015
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Fri, 10 Apr 2015 13:11:48 +0200
Subject: Collapsing HsForAllTy, again
In-Reply-To: <d0e3d69511a1489da10848b7c154b145@DB4PR30MB030.064d.mgd.msft.net>
References: <CANma=H-o2Po6Y4XHYMLmU7VAAbFWb-jU2nW7O_0D96kDzjcy+A@mail.gmail.com>
 <1a73fdbf3b174e9381d6c70324eb159c@DB4PR30MB030.064d.mgd.msft.net>
 <CANma=H8OSKLTFc+0E10Mkzct8GSwfqGxt5juyifFkP5uOYhNHA@mail.gmail.com>
 <d0e3d69511a1489da10848b7c154b145@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <CANma=H9VTOqpFGHOoq6NxnGn7nib3eCYuujsPYHMYhVRQjg43Q@mail.gmail.com>

It looks like

splitLHsForAllTy
    :: LHsType name
    -> (LHsTyVarBndrs name, HsContext name, LHsType name)
splitLHsForAllTy poly_ty
  = case unLoc poly_ty of
        HsParTy ty                -> splitLHsForAllTy ty
        HsForAllTy _ _ tvs cxt ty -> (tvs, unLoc cxt, ty)
        _                         -> (emptyHsQTvs, [], poly_ty)
        -- The type vars should have been computed by now, even if they
were implicit

needs a recursive call for the HsForAllTy case, it now generates

libraries/base/Data/Monoid.hs:217:10:
    Malformed instance: forall f a. Alternative f => Monoid (Alt f a)


Alan

On Fri, Apr 10, 2015 at 10:13 AM, Simon Peyton Jones <simonpj at microsoft.com>
wrote:

>  Look at how instance declarations are parsed. If you look at Parser.y
> you?ll see that for
>
>
>
> instance (Eq a, Eq b) => Eq (a,b)
>
>
>
> we get (in effect)
>
>
>
> mkImplicitHsForAllTy (mkQualifiedHsForAllTy (Eq a, Eq b) (Eq (a,b))
>
>
>
> The outer mkImplicit.. is to ensure that there is always, in the end, a
> HsForAllTy around the whole thing, even around
>
> instance Eq a
>
> say.
>
>
>
> But we don?t actually want two nested HsForAllTys.  mk_forall_ty collapsed
> the two.
>
>
>
> But you don?t want that either.  So I think you should make
> mkImplictHsForAllTy do the test instead.  Its goal is to wrap a HsForallTy
> if there isn?t one already. So
>
>
>
> mkImplicitHsForAllTy (HsForAllTy exp tvs cxt ty)
>
>   = HsForAllTy exp? tvs cxt ty
>
>   where
>
>     exp? = case exp of
>
>              Qualified -> Implicit
>
>              _         -> exp
>
> mkImplicitHsForAllTy ty = mkHsForAllTy Implicit  []  (L loc _) ty
>
>
>
> should do the job.
>
>
>
> Incidentally, mkImplicitHsForAllTy should not take a ctxt argument.  If
> you have a non-empty context, use mkQualifiedHsForAllTy.  That means that
> in Convert you?ll need to use
>
>    mkHsForAllTy Implicit ctxt ty?
>
> instead of mkImplicitHsForAllTy
>
>
>
> Simon
>
>
>
> *From:* Alan & Kim Zimmerman [mailto:alan.zimm at gmail.com]
> *Sent:* 10 April 2015 08:02
> *To:* Simon Peyton Jones
> *Cc:* ghc-devs at haskell.org
> *Subject:* Re: Collapsing HsForAllTy, again
>
>
>
> If I replace it with
>
>
> mkHsForAllTy :: HsExplicitFlag -> [LHsTyVarBndr RdrName] -> LHsContext
> RdrName -> LHsType RdrName -> HsType RdrName
> -- Smart constructor for HsForAllTy
> -- mkHsForAllTy exp tvs (L _ []) ty = mk_forall_ty exp tvs ty
> mkHsForAllTy exp tvs (L _ []) ty = HsForAllTy exp Nothing (mkHsQTvs tvs)
> (L noSrcSpan []) ty
> mkHsForAllTy exp tvs ctxt     ty = HsForAllTy exp extra   (mkHsQTvs tvs)
> cleanCtxt        ty
>   where -- Separate the extra-constraints wildcard when present
>         (cleanCtxt, extra)
>           | (L l HsWildcardTy) <- ignoreParens (last (unLoc ctxt)) = (init
> `fmap` ctxt, Just l)
>           | otherwise = (ctxt, Nothing)
>         ignoreParens (L _ (HsParTy ty)) = ty -- TODO:AZ We lose the
> annotation here
>         ignoreParens ty                 = ty
>
>
> I get the following errors in the stage 2 compile (only first 3 shown here)
>
>
> libraries/ghc-prim/GHC/Classes.hs:52:19:
>     Malformed instance: (Eq a, Eq b) => Eq (a, b)
>
> libraries/ghc-prim/GHC/Classes.hs:53:19:
>     Malformed instance: (Eq a, Eq b, Eq c) => Eq (a, b, c)
>
> libraries/ghc-prim/GHC/Classes.hs:54:19:
>     Malformed instance: (Eq a, Eq b, Eq c, Eq d) => Eq (a, b, c, d)
>
>
>   Alan
>
>
>
> On Fri, Apr 10, 2015 at 12:14 AM, Simon Peyton Jones <
> simonpj at microsoft.com> wrote:
>
>  Hmm.  I?m not sure what the motivation is either.  Try dropping it out
> and see if anything goes wrong.
>
>
> Simon
>
>
>
> *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Alan
> & Kim Zimmerman
> *Sent:* 09 April 2015 22:15
> *To:* ghc-devs at haskell.org
> *Subject:* Collapsing HsForAllTy, again
>
>
>
> With the help of Jan Stolarek I tracked down the HsForAllTy flattening to
>  `HsTypes.mk_forall_ty`.
>
> This function takes any nested HsForAllTy's where the top one does not
> have a context defined, and collapses them into a single one.
>
> I do not know what the motivation for this is, and if it perhaps speeds up
> or simplifies further compilation.
>
> But now that API Annotations have arrived, making sure we do not lose the
> annotations for the sub-HsForAllTy  causes significant gymnastics in the
> parser [1].
>
> So my question is, is there a good reason to continue doing this, given
> the trade-off in parser complexity.
>
> Regards
>
>   Alan
>
> [1]  https://phabricator.haskell.org/D833
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150410/08b5bb6f/attachment-0001.html>

From alan.zimm at gmail.com  Fri Apr 10 12:05:21 2015
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Fri, 10 Apr 2015 14:05:21 +0200
Subject: Collapsing HsForAllTy, again
In-Reply-To: <CANma=H9VTOqpFGHOoq6NxnGn7nib3eCYuujsPYHMYhVRQjg43Q@mail.gmail.com>
References: <CANma=H-o2Po6Y4XHYMLmU7VAAbFWb-jU2nW7O_0D96kDzjcy+A@mail.gmail.com>
 <1a73fdbf3b174e9381d6c70324eb159c@DB4PR30MB030.064d.mgd.msft.net>
 <CANma=H8OSKLTFc+0E10Mkzct8GSwfqGxt5juyifFkP5uOYhNHA@mail.gmail.com>
 <d0e3d69511a1489da10848b7c154b145@DB4PR30MB030.064d.mgd.msft.net>
 <CANma=H9VTOqpFGHOoq6NxnGn7nib3eCYuujsPYHMYhVRQjg43Q@mail.gmail.com>
Message-ID: <CANma=H9A7GppOgGD4HJGpArhVj8kiyhg845txUtff864-J+mQw@mail.gmail.com>

And once the splitLHsForAllTy is sorted, this

tc_inst_head :: HsType Name -> TcM TcType
tc_inst_head (HsForAllTy _ _ hs_tvs hs_ctxt hs_ty)
  = tcHsTyVarBndrs hs_tvs $ \ tvs ->
    do { ctxt <- tcHsContext hs_ctxt
       ; ty   <- tc_lhs_type hs_ty ekConstraint    -- Body for forall has
kind Constraint
       ; return (mkSigmaTy tvs ctxt ty) }

results in

libraries/base/Data/Monoid.hs:217:23:
    Illegal constraint: Alternative f => Monoid (Alt f a)
    In the instance declaration for ?Alternative f => Monoid (Alt f a)?

Alan

On Fri, Apr 10, 2015 at 1:11 PM, Alan & Kim Zimmerman <alan.zimm at gmail.com>
wrote:

> It looks like
>
> splitLHsForAllTy
>     :: LHsType name
>     -> (LHsTyVarBndrs name, HsContext name, LHsType name)
> splitLHsForAllTy poly_ty
>   = case unLoc poly_ty of
>         HsParTy ty                -> splitLHsForAllTy ty
>         HsForAllTy _ _ tvs cxt ty -> (tvs, unLoc cxt, ty)
>         _                         -> (emptyHsQTvs, [], poly_ty)
>         -- The type vars should have been computed by now, even if they
> were implicit
>
> needs a recursive call for the HsForAllTy case, it now generates
>
> libraries/base/Data/Monoid.hs:217:10:
>     Malformed instance: forall f a. Alternative f => Monoid (Alt f a)
>
>
> Alan
>
> On Fri, Apr 10, 2015 at 10:13 AM, Simon Peyton Jones <
> simonpj at microsoft.com> wrote:
>
>>  Look at how instance declarations are parsed. If you look at Parser.y
>> you?ll see that for
>>
>>
>>
>> instance (Eq a, Eq b) => Eq (a,b)
>>
>>
>>
>> we get (in effect)
>>
>>
>>
>> mkImplicitHsForAllTy (mkQualifiedHsForAllTy (Eq a, Eq b) (Eq (a,b))
>>
>>
>>
>> The outer mkImplicit.. is to ensure that there is always, in the end, a
>> HsForAllTy around the whole thing, even around
>>
>> instance Eq a
>>
>> say.
>>
>>
>>
>> But we don?t actually want two nested HsForAllTys.  mk_forall_ty
>> collapsed the two.
>>
>>
>>
>> But you don?t want that either.  So I think you should make
>> mkImplictHsForAllTy do the test instead.  Its goal is to wrap a HsForallTy
>> if there isn?t one already. So
>>
>>
>>
>> mkImplicitHsForAllTy (HsForAllTy exp tvs cxt ty)
>>
>>   = HsForAllTy exp? tvs cxt ty
>>
>>   where
>>
>>     exp? = case exp of
>>
>>              Qualified -> Implicit
>>
>>              _         -> exp
>>
>> mkImplicitHsForAllTy ty = mkHsForAllTy Implicit  []  (L loc _) ty
>>
>>
>>
>> should do the job.
>>
>>
>>
>> Incidentally, mkImplicitHsForAllTy should not take a ctxt argument.  If
>> you have a non-empty context, use mkQualifiedHsForAllTy.  That means that
>> in Convert you?ll need to use
>>
>>    mkHsForAllTy Implicit ctxt ty?
>>
>> instead of mkImplicitHsForAllTy
>>
>>
>>
>> Simon
>>
>>
>>
>> *From:* Alan & Kim Zimmerman [mailto:alan.zimm at gmail.com]
>> *Sent:* 10 April 2015 08:02
>> *To:* Simon Peyton Jones
>> *Cc:* ghc-devs at haskell.org
>> *Subject:* Re: Collapsing HsForAllTy, again
>>
>>
>>
>> If I replace it with
>>
>>
>> mkHsForAllTy :: HsExplicitFlag -> [LHsTyVarBndr RdrName] -> LHsContext
>> RdrName -> LHsType RdrName -> HsType RdrName
>> -- Smart constructor for HsForAllTy
>> -- mkHsForAllTy exp tvs (L _ []) ty = mk_forall_ty exp tvs ty
>> mkHsForAllTy exp tvs (L _ []) ty = HsForAllTy exp Nothing (mkHsQTvs tvs)
>> (L noSrcSpan []) ty
>> mkHsForAllTy exp tvs ctxt     ty = HsForAllTy exp extra   (mkHsQTvs tvs)
>> cleanCtxt        ty
>>   where -- Separate the extra-constraints wildcard when present
>>         (cleanCtxt, extra)
>>           | (L l HsWildcardTy) <- ignoreParens (last (unLoc ctxt)) =
>> (init `fmap` ctxt, Just l)
>>           | otherwise = (ctxt, Nothing)
>>         ignoreParens (L _ (HsParTy ty)) = ty -- TODO:AZ We lose the
>> annotation here
>>         ignoreParens ty                 = ty
>>
>>
>> I get the following errors in the stage 2 compile (only first 3 shown
>> here)
>>
>>
>> libraries/ghc-prim/GHC/Classes.hs:52:19:
>>     Malformed instance: (Eq a, Eq b) => Eq (a, b)
>>
>> libraries/ghc-prim/GHC/Classes.hs:53:19:
>>     Malformed instance: (Eq a, Eq b, Eq c) => Eq (a, b, c)
>>
>> libraries/ghc-prim/GHC/Classes.hs:54:19:
>>     Malformed instance: (Eq a, Eq b, Eq c, Eq d) => Eq (a, b, c, d)
>>
>>
>>   Alan
>>
>>
>>
>> On Fri, Apr 10, 2015 at 12:14 AM, Simon Peyton Jones <
>> simonpj at microsoft.com> wrote:
>>
>>  Hmm.  I?m not sure what the motivation is either.  Try dropping it out
>> and see if anything goes wrong.
>>
>>
>> Simon
>>
>>
>>
>> *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Alan
>> & Kim Zimmerman
>> *Sent:* 09 April 2015 22:15
>> *To:* ghc-devs at haskell.org
>> *Subject:* Collapsing HsForAllTy, again
>>
>>
>>
>> With the help of Jan Stolarek I tracked down the HsForAllTy flattening to
>>  `HsTypes.mk_forall_ty`.
>>
>> This function takes any nested HsForAllTy's where the top one does not
>> have a context defined, and collapses them into a single one.
>>
>> I do not know what the motivation for this is, and if it perhaps speeds
>> up or simplifies further compilation.
>>
>> But now that API Annotations have arrived, making sure we do not lose the
>> annotations for the sub-HsForAllTy  causes significant gymnastics in the
>> parser [1].
>>
>> So my question is, is there a good reason to continue doing this, given
>> the trade-off in parser complexity.
>>
>> Regards
>>
>>   Alan
>>
>> [1]  https://phabricator.haskell.org/D833
>>
>>
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150410/cc00a8bb/attachment.html>

From eir at cis.upenn.edu  Fri Apr 10 12:07:05 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Fri, 10 Apr 2015 13:07:05 +0100
Subject: Generalized Newtype Deriving not allowed in Safe Haskell
In-Reply-To: <CACHt1w8Mc_LoZaACO-sPvWxMwragP35bfKL2cz+_GD4tF24OOg@mail.gmail.com>
References: <CAL2jp559kvXbd3MxEC0Zrg8dzFrUbSYVMwzky3-oHMjKATurDA@mail.gmail.com>
 <0d913dcca48b47abadb7ab6b4125b906@DB4PR30MB030.064d.mgd.msft.net>
 <CACHt1w8Mc_LoZaACO-sPvWxMwragP35bfKL2cz+_GD4tF24OOg@mail.gmail.com>
Message-ID: <86F7E6C0-6CD5-40CD-BAF9-1CA07FA80872@cis.upenn.edu>

Here's an idea: For a module to be Safe, then for each exported datatype, one of the following must hold:
1) The datatype comes with a role annotation.
2) The module exports all of the datatype's constructors.
3) If the datatype is defined in a place other than the current module, the current module exports no fewer data constructors than are exported in the datatype's defining module.

Why?
1) The role annotation, even if it has no effect, shows that the programmer has considered roles. Any mistake here is clearly the programmer's fault.
2) This datatype is clearly meant not to be abstract. `Coercible` then gives clients no more power than they already have.
3) This is subtler. It is a common idiom to export a datatype's constructors from a package-internal module, but then never to export the constructors beyond the package. If such a datatype has a role annotation (in its defining module, of course), then we're fine, even if it is exported abstractly later. However, suppose we are abstractly re-exporting a datatype that exports its constructors from its defining module. If there is no role annotation on the datatype, we're in trouble and should fail. BUT, if the datatype were exported abstractly in its defining module, then we don't need to fail on re-export, because nothing has changed.


Actually, we could simplify the conditions. Change (2) to:

2') The module exports all of the datatype's visible constructors.

I think explaining in terms of separate rules (2) and (3) is a little clearer, because the re-export case is slightly subtle, and this subtlety can be lost in (2').

This proposal would require tracking (in interface files, too) whether or not a datatype comes with a role annotation. This isn't hard, though. It might even help in pretty-printing.


An alternative would be to have a way of setting roles differently on export than internally. I don't think this breaks the type system, but it's yet another thing to specify and support. And we'd have to consider the possibility that some module will import a datatype from multiple re-exporting modules, each with different ascribed role annotations. Is this an error? Does GHC take some sort of least upper bound? I prefer not to go here, but there's nothing terribly wrong with this approach.

Richard

On Apr 10, 2015, at 9:37 AM, David Terei <dave.terei at gmail.com> wrote:

> I'll prepare a patch for the userguide soon.
> 
> As for something better, yes I think we can and should. It's on my
> todo list :) Basically, the new-GND design has all the mechanisms to
> be safe, but sadly the defaults are rather worrying. Without explicit
> annotations from the user, module abstractions are broken. This is why
> we left GND out of Safe Haskell for the moment as it is a subtle and
> easy mistake to make.
> 
> If the module contained explicit role annotations then it could be
> allowed. The discussion in
> https://ghc.haskell.org/trac/ghc/ticket/8827 has other solutions that
> I prefer, such as only exporting the Coerce instance if all the
> constructors are exported, it seems that the ship sailed on these
> bigger changes sadly.
> 
> Cheers,
> David
> 
> On 9 April 2015 at 00:56, Simon Peyton Jones <simonpj at microsoft.com> wrote:
>> There is a long discussion on https://ghc.haskell.org/trac/ghc/ticket/8827
>> about whether the new Coercible story makes GND ok for Safe Haskell.  At a
>> type-soundness level, definitely yes.  But there are other less-clear-cut
>> issues like ?breaking abstractions? to consider.  The decision on the ticket
>> (comment:36) seems to be: GND stays out of Safe Haskell for now, but there
>> is room for a better proposal.
>> 
>> 
>> 
>> I don?t have an opinion myself. David Terei and David Mazieres are in the
>> driving seat, but I?m sure they?ll be responsive to user input.
>> 
>> 
>> 
>> However, I think the user manual may not have kept up with #8827.  The
>> sentence ?GeneralizedNewtypeDeriving ? It can be used to violate constructor
>> access control, by allowing untrusted code to manipulate protected data
>> types in ways the data type author did not intend, breaking invariants they
>> have established.?  vanished from the 7.8 user manual (links below).  Maybe
>> it should be restored.
>> 
>> 
>> 
>> Safe Haskell aficionados, would you like to offer a patch for the manual?
>> And maybe also a less drastic remedy than omitting GND altogether?
>> 
>> 
>> 
>> Simon
>> 
>> 
>> 
>> From: Omari Norman [mailto:omari at smileystation.com]
>> Sent: 09 April 2015 02:44
>> To: haskell Cafe
>> Subject: Generalized Newtype Deriving not allowed in Safe Haskell
>> 
>> 
>> 
>> When compiling code with Generalized Newtype Deriving and the -fwarn-unsafe
>> flag, I get
>> 
>> 
>> 
>> -XGeneralizedNewtypeDeriving is not allowed in Safe Haskell
>> 
>> 
>> 
>> This happens both in GHC 7.8 and GHC 7.10.
>> 
>> 
>> 
>> I thought I remembered reading somewhere that GNTD is now part of the safe
>> language?  The GHC manual used to state that GNTD is not allowed in Safe
>> Haskell:
>> 
>> 
>> 
>> https://downloads.haskell.org/~ghc/7.6.3/docs/html/users_guide/safe-haskell.html#safe-language
>> 
>> 
>> 
>> But this language on GNTD not being part of the safe language was removed in
>> the 7.8 manual:
>> 
>> 
>> 
>> https://downloads.haskell.org/~ghc/7.8.2/docs/html/users_guide/safe-haskell.html#safe-language
>> 
>> 
>> 
>> The GHC release notes don't say anything about this one way or the other.
>> Thoughts?
>> 
>> 
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> 


From simonpj at microsoft.com  Fri Apr 10 12:08:43 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 10 Apr 2015 12:08:43 +0000
Subject: Collapsing HsForAllTy, again
In-Reply-To: <CANma=H9A7GppOgGD4HJGpArhVj8kiyhg845txUtff864-J+mQw@mail.gmail.com>
References: <CANma=H-o2Po6Y4XHYMLmU7VAAbFWb-jU2nW7O_0D96kDzjcy+A@mail.gmail.com>
 <1a73fdbf3b174e9381d6c70324eb159c@DB4PR30MB030.064d.mgd.msft.net>
 <CANma=H8OSKLTFc+0E10Mkzct8GSwfqGxt5juyifFkP5uOYhNHA@mail.gmail.com>
 <d0e3d69511a1489da10848b7c154b145@DB4PR30MB030.064d.mgd.msft.net>
 <CANma=H9VTOqpFGHOoq6NxnGn7nib3eCYuujsPYHMYhVRQjg43Q@mail.gmail.com>
 <CANma=H9A7GppOgGD4HJGpArhVj8kiyhg845txUtff864-J+mQw@mail.gmail.com>
Message-ID: <535b498957aa4ffca7a94f7bd887dea2@DB4PR30MB030.064d.mgd.msft.net>

You are describing code I cannot see.  Can you perhaps just work out what is happening and fix it?  Nothing very deep is here, I think.  If you get really stuck and cannot make progress then put it in a Phab patch and I will try to look.  But I?m struggling with time at the moment.

Simon

From: Alan & Kim Zimmerman [mailto:alan.zimm at gmail.com]
Sent: 10 April 2015 13:05
To: Simon Peyton Jones
Cc: ghc-devs at haskell.org
Subject: Re: Collapsing HsForAllTy, again

And once the splitLHsForAllTy is sorted, this

tc_inst_head :: HsType Name -> TcM TcType
tc_inst_head (HsForAllTy _ _ hs_tvs hs_ctxt hs_ty)
  = tcHsTyVarBndrs hs_tvs $ \ tvs ->
    do { ctxt <- tcHsContext hs_ctxt
       ; ty   <- tc_lhs_type hs_ty ekConstraint    -- Body for forall has kind Constraint
       ; return (mkSigmaTy tvs ctxt ty) }
results in

libraries/base/Data/Monoid.hs:217:23:
    Illegal constraint: Alternative f => Monoid (Alt f a)
    In the instance declaration for ?Alternative f => Monoid (Alt f a)?
Alan

On Fri, Apr 10, 2015 at 1:11 PM, Alan & Kim Zimmerman <alan.zimm at gmail.com<mailto:alan.zimm at gmail.com>> wrote:
It looks like

splitLHsForAllTy
    :: LHsType name
    -> (LHsTyVarBndrs name, HsContext name, LHsType name)
splitLHsForAllTy poly_ty
  = case unLoc poly_ty of
        HsParTy ty                -> splitLHsForAllTy ty
        HsForAllTy _ _ tvs cxt ty -> (tvs, unLoc cxt, ty)
        _                         -> (emptyHsQTvs, [], poly_ty)
        -- The type vars should have been computed by now, even if they were implicit
needs a recursive call for the HsForAllTy case, it now generates

libraries/base/Data/Monoid.hs:217:10:
    Malformed instance: forall f a. Alternative f => Monoid (Alt f a)

Alan

On Fri, Apr 10, 2015 at 10:13 AM, Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
Look at how instance declarations are parsed. If you look at Parser.y you?ll see that for


instance (Eq a, Eq b) => Eq (a,b)

we get (in effect)


mkImplicitHsForAllTy (mkQualifiedHsForAllTy (Eq a, Eq b) (Eq (a,b))

The outer mkImplicit.. is to ensure that there is always, in the end, a HsForAllTy around the whole thing, even around

instance Eq a
say.

But we don?t actually want two nested HsForAllTys.  mk_forall_ty collapsed the two.

But you don?t want that either.  So I think you should make mkImplictHsForAllTy do the test instead.  Its goal is to wrap a HsForallTy if there isn?t one already. So


mkImplicitHsForAllTy (HsForAllTy exp tvs cxt ty)

  = HsForAllTy exp? tvs cxt ty

  where

    exp? = case exp of

             Qualified -> Implicit

             _         -> exp

mkImplicitHsForAllTy ty = mkHsForAllTy Implicit  []  (L loc _) ty

should do the job.

Incidentally, mkImplicitHsForAllTy should not take a ctxt argument.  If you have a non-empty context, use mkQualifiedHsForAllTy.  That means that in Convert you?ll need to use
   mkHsForAllTy Implicit ctxt ty?
instead of mkImplicitHsForAllTy

Simon

From: Alan & Kim Zimmerman [mailto:alan.zimm at gmail.com<mailto:alan.zimm at gmail.com>]
Sent: 10 April 2015 08:02
To: Simon Peyton Jones
Cc: ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
Subject: Re: Collapsing HsForAllTy, again

If I replace it with


mkHsForAllTy :: HsExplicitFlag -> [LHsTyVarBndr RdrName] -> LHsContext RdrName -> LHsType RdrName -> HsType RdrName
-- Smart constructor for HsForAllTy
-- mkHsForAllTy exp tvs (L _ []) ty = mk_forall_ty exp tvs ty
mkHsForAllTy exp tvs (L _ []) ty = HsForAllTy exp Nothing (mkHsQTvs tvs) (L noSrcSpan []) ty
mkHsForAllTy exp tvs ctxt     ty = HsForAllTy exp extra   (mkHsQTvs tvs) cleanCtxt        ty
  where -- Separate the extra-constraints wildcard when present
        (cleanCtxt, extra)
          | (L l HsWildcardTy) <- ignoreParens (last (unLoc ctxt)) = (init `fmap` ctxt, Just l)
          | otherwise = (ctxt, Nothing)
        ignoreParens (L _ (HsParTy ty)) = ty -- TODO:AZ We lose the annotation here
        ignoreParens ty                 = ty

I get the following errors in the stage 2 compile (only first 3 shown here)


libraries/ghc-prim/GHC/Classes.hs:52:19:
    Malformed instance: (Eq a, Eq b) => Eq (a, b)

libraries/ghc-prim/GHC/Classes.hs:53:19:
    Malformed instance: (Eq a, Eq b, Eq c) => Eq (a, b, c)

libraries/ghc-prim/GHC/Classes.hs:54:19:
    Malformed instance: (Eq a, Eq b, Eq c, Eq d) => Eq (a, b, c, d)

Alan

On Fri, Apr 10, 2015 at 12:14 AM, Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
Hmm.  I?m not sure what the motivation is either.  Try dropping it out and see if anything goes wrong.

Simon

From: ghc-devs [mailto:ghc-devs-bounces at haskell.org<mailto:ghc-devs-bounces at haskell.org>] On Behalf Of Alan & Kim Zimmerman
Sent: 09 April 2015 22:15
To: ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
Subject: Collapsing HsForAllTy, again

With the help of Jan Stolarek I tracked down the HsForAllTy flattening to
 `HsTypes.mk_forall_ty`.
This function takes any nested HsForAllTy's where the top one does not have a context defined, and collapses them into a single one.
I do not know what the motivation for this is, and if it perhaps speeds up or simplifies further compilation.
But now that API Annotations have arrived, making sure we do not lose the annotations for the sub-HsForAllTy  causes significant gymnastics in the parser [1].
So my question is, is there a good reason to continue doing this, given the trade-off in parser complexity.
Regards
  Alan
[1]  https://phabricator.haskell.org/D833




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150410/ff5cc86b/attachment-0001.html>

From alan.zimm at gmail.com  Fri Apr 10 12:31:01 2015
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Fri, 10 Apr 2015 14:31:01 +0200
Subject: Collapsing HsForAllTy, again
In-Reply-To: <535b498957aa4ffca7a94f7bd887dea2@DB4PR30MB030.064d.mgd.msft.net>
References: <CANma=H-o2Po6Y4XHYMLmU7VAAbFWb-jU2nW7O_0D96kDzjcy+A@mail.gmail.com>
 <1a73fdbf3b174e9381d6c70324eb159c@DB4PR30MB030.064d.mgd.msft.net>
 <CANma=H8OSKLTFc+0E10Mkzct8GSwfqGxt5juyifFkP5uOYhNHA@mail.gmail.com>
 <d0e3d69511a1489da10848b7c154b145@DB4PR30MB030.064d.mgd.msft.net>
 <CANma=H9VTOqpFGHOoq6NxnGn7nib3eCYuujsPYHMYhVRQjg43Q@mail.gmail.com>
 <CANma=H9A7GppOgGD4HJGpArhVj8kiyhg845txUtff864-J+mQw@mail.gmail.com>
 <535b498957aa4ffca7a94f7bd887dea2@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <CANma=H8jjTfE1ti92txNd-oyDRCtj1pLEWMHR_e7hGU2rUR8Dg@mail.gmail.com>

Ok, I am making progress, when it is done I will put up a patch.

I figured I was probably posting too much, sorry all.

Alan

On Fri, Apr 10, 2015 at 2:08 PM, Simon Peyton Jones <simonpj at microsoft.com>
wrote:

>  You are describing code I cannot see.  Can you perhaps just work out
> what is happening and fix it?  Nothing very deep is here, I think.  If you
> get really stuck and cannot make progress then put it in a Phab patch and I
> will try to look.  But I?m struggling with time at the moment.
>
>
>
> Simon
>
>
>
> *From:* Alan & Kim Zimmerman [mailto:alan.zimm at gmail.com]
> *Sent:* 10 April 2015 13:05
>
> *To:* Simon Peyton Jones
> *Cc:* ghc-devs at haskell.org
> *Subject:* Re: Collapsing HsForAllTy, again
>
>
>
> And once the splitLHsForAllTy is sorted, this
>
> tc_inst_head :: HsType Name -> TcM TcType
> tc_inst_head (HsForAllTy _ _ hs_tvs hs_ctxt hs_ty)
>   = tcHsTyVarBndrs hs_tvs $ \ tvs ->
>     do { ctxt <- tcHsContext hs_ctxt
>        ; ty   <- tc_lhs_type hs_ty ekConstraint    -- Body for forall has
> kind Constraint
>        ; return (mkSigmaTy tvs ctxt ty) }
>
> results in
>
> libraries/base/Data/Monoid.hs:217:23:
>     Illegal constraint: Alternative f => Monoid (Alt f a)
>     In the instance declaration for ?Alternative f => Monoid (Alt f a)?
>
> Alan
>
>
>
> On Fri, Apr 10, 2015 at 1:11 PM, Alan & Kim Zimmerman <alan.zimm at gmail.com>
> wrote:
>
>   It looks like
>
> splitLHsForAllTy
>     :: LHsType name
>     -> (LHsTyVarBndrs name, HsContext name, LHsType name)
> splitLHsForAllTy poly_ty
>   = case unLoc poly_ty of
>         HsParTy ty                -> splitLHsForAllTy ty
>         HsForAllTy _ _ tvs cxt ty -> (tvs, unLoc cxt, ty)
>         _                         -> (emptyHsQTvs, [], poly_ty)
>         -- The type vars should have been computed by now, even if they
> were implicit
>
> needs a recursive call for the HsForAllTy case, it now generates
>
> libraries/base/Data/Monoid.hs:217:10:
>     Malformed instance: forall f a. Alternative f => Monoid (Alt f a)
>
>   Alan
>
>
>
> On Fri, Apr 10, 2015 at 10:13 AM, Simon Peyton Jones <
> simonpj at microsoft.com> wrote:
>
>  Look at how instance declarations are parsed. If you look at Parser.y
> you?ll see that for
>
>
>
> instance (Eq a, Eq b) => Eq (a,b)
>
>
>
> we get (in effect)
>
>
>
> mkImplicitHsForAllTy (mkQualifiedHsForAllTy (Eq a, Eq b) (Eq (a,b))
>
>
>
> The outer mkImplicit.. is to ensure that there is always, in the end, a
> HsForAllTy around the whole thing, even around
>
> instance Eq a
>
> say.
>
>
>
> But we don?t actually want two nested HsForAllTys.  mk_forall_ty collapsed
> the two.
>
>
>
> But you don?t want that either.  So I think you should make
> mkImplictHsForAllTy do the test instead.  Its goal is to wrap a HsForallTy
> if there isn?t one already. So
>
>
>
> mkImplicitHsForAllTy (HsForAllTy exp tvs cxt ty)
>
>   = HsForAllTy exp? tvs cxt ty
>
>   where
>
>     exp? = case exp of
>
>              Qualified -> Implicit
>
>              _         -> exp
>
> mkImplicitHsForAllTy ty = mkHsForAllTy Implicit  []  (L loc _) ty
>
>
>
> should do the job.
>
>
>
> Incidentally, mkImplicitHsForAllTy should not take a ctxt argument.  If
> you have a non-empty context, use mkQualifiedHsForAllTy.  That means that
> in Convert you?ll need to use
>
>    mkHsForAllTy Implicit ctxt ty?
>
> instead of mkImplicitHsForAllTy
>
>
>
> Simon
>
>
>
> *From:* Alan & Kim Zimmerman [mailto:alan.zimm at gmail.com]
> *Sent:* 10 April 2015 08:02
> *To:* Simon Peyton Jones
> *Cc:* ghc-devs at haskell.org
> *Subject:* Re: Collapsing HsForAllTy, again
>
>
>
> If I replace it with
>
>
> mkHsForAllTy :: HsExplicitFlag -> [LHsTyVarBndr RdrName] -> LHsContext
> RdrName -> LHsType RdrName -> HsType RdrName
> -- Smart constructor for HsForAllTy
> -- mkHsForAllTy exp tvs (L _ []) ty = mk_forall_ty exp tvs ty
> mkHsForAllTy exp tvs (L _ []) ty = HsForAllTy exp Nothing (mkHsQTvs tvs)
> (L noSrcSpan []) ty
> mkHsForAllTy exp tvs ctxt     ty = HsForAllTy exp extra   (mkHsQTvs tvs)
> cleanCtxt        ty
>   where -- Separate the extra-constraints wildcard when present
>         (cleanCtxt, extra)
>           | (L l HsWildcardTy) <- ignoreParens (last (unLoc ctxt)) = (init
> `fmap` ctxt, Just l)
>           | otherwise = (ctxt, Nothing)
>         ignoreParens (L _ (HsParTy ty)) = ty -- TODO:AZ We lose the
> annotation here
>         ignoreParens ty                 = ty
>
>
> I get the following errors in the stage 2 compile (only first 3 shown here)
>
>
> libraries/ghc-prim/GHC/Classes.hs:52:19:
>     Malformed instance: (Eq a, Eq b) => Eq (a, b)
>
> libraries/ghc-prim/GHC/Classes.hs:53:19:
>     Malformed instance: (Eq a, Eq b, Eq c) => Eq (a, b, c)
>
> libraries/ghc-prim/GHC/Classes.hs:54:19:
>     Malformed instance: (Eq a, Eq b, Eq c, Eq d) => Eq (a, b, c, d)
>
>  Alan
>
>
>
> On Fri, Apr 10, 2015 at 12:14 AM, Simon Peyton Jones <
> simonpj at microsoft.com> wrote:
>
>  Hmm.  I?m not sure what the motivation is either.  Try dropping it out
> and see if anything goes wrong.
>
>
> Simon
>
>
>
> *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Alan
> & Kim Zimmerman
> *Sent:* 09 April 2015 22:15
> *To:* ghc-devs at haskell.org
> *Subject:* Collapsing HsForAllTy, again
>
>
>
> With the help of Jan Stolarek I tracked down the HsForAllTy flattening to
>  `HsTypes.mk_forall_ty`.
>
> This function takes any nested HsForAllTy's where the top one does not
> have a context defined, and collapses them into a single one.
>
> I do not know what the motivation for this is, and if it perhaps speeds up
> or simplifies further compilation.
>
> But now that API Annotations have arrived, making sure we do not lose the
> annotations for the sub-HsForAllTy  causes significant gymnastics in the
> parser [1].
>
> So my question is, is there a good reason to continue doing this, given
> the trade-off in parser complexity.
>
> Regards
>
>   Alan
>
> [1]  https://phabricator.haskell.org/D833
>
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150410/76a25fe7/attachment.html>

From david.feuer at gmail.com  Fri Apr 10 22:54:18 2015
From: david.feuer at gmail.com (David Feuer)
Date: Fri, 10 Apr 2015 18:54:18 -0400
Subject: [Haskell-cafe] Generalized Newtype Deriving not allowed in Safe
 Haskell
In-Reply-To: <CACruqwRM_7u0ofCM7Jq99NOqrFxcjqDrwxBZtcJ36R6-d3KCuA@mail.gmail.com>
References: <CAL2jp559kvXbd3MxEC0Zrg8dzFrUbSYVMwzky3-oHMjKATurDA@mail.gmail.com>
 <0d913dcca48b47abadb7ab6b4125b906@DB4PR30MB030.064d.mgd.msft.net>
 <CACHt1w8Mc_LoZaACO-sPvWxMwragP35bfKL2cz+_GD4tF24OOg@mail.gmail.com>
 <86F7E6C0-6CD5-40CD-BAF9-1CA07FA80872@cis.upenn.edu>
 <CACruqwRM_7u0ofCM7Jq99NOqrFxcjqDrwxBZtcJ36R6-d3KCuA@mail.gmail.com>
Message-ID: <CAMgWh9tNkZV6GXp-iZ5fsPXg-JX2A1pKs+5hUgApiVrFmtp5MA@mail.gmail.com>

I think a module exporting some but not all data constructors of a type is
fundamentally broken behavior. I would generally be in favor of prohibiting
it altogether, and I would be strongly opposed to letting continued support
for it break anything else.
On Apr 10, 2015 9:05 AM, "Douglas McClean" <douglas.mcclean at gmail.com>
wrote:

> I don't think that 2+3 is equivalent to 2', because an explicit import
> list or hiding list could've brought only some of the datatype's
> constructors into visibility.
>
> On Fri, Apr 10, 2015 at 8:07 AM, Richard Eisenberg <eir at cis.upenn.edu>
> wrote:
>
>> Here's an idea: For a module to be Safe, then for each exported datatype,
>> one of the following must hold:
>> 1) The datatype comes with a role annotation.
>> 2) The module exports all of the datatype's constructors.
>> 3) If the datatype is defined in a place other than the current module,
>> the current module exports no fewer data constructors than are exported in
>> the datatype's defining module.
>>
>> Why?
>> 1) The role annotation, even if it has no effect, shows that the
>> programmer has considered roles. Any mistake here is clearly the
>> programmer's fault.
>> 2) This datatype is clearly meant not to be abstract. `Coercible` then
>> gives clients no more power than they already have.
>> 3) This is subtler. It is a common idiom to export a datatype's
>> constructors from a package-internal module, but then never to export the
>> constructors beyond the package. If such a datatype has a role annotation
>> (in its defining module, of course), then we're fine, even if it is
>> exported abstractly later. However, suppose we are abstractly re-exporting
>> a datatype that exports its constructors from its defining module. If there
>> is no role annotation on the datatype, we're in trouble and should fail.
>> BUT, if the datatype were exported abstractly in its defining module, then
>> we don't need to fail on re-export, because nothing has changed.
>>
>>
>> Actually, we could simplify the conditions. Change (2) to:
>>
>> 2') The module exports all of the datatype's visible constructors.
>>
>> I think explaining in terms of separate rules (2) and (3) is a little
>> clearer, because the re-export case is slightly subtle, and this subtlety
>> can be lost in (2').
>>
>> This proposal would require tracking (in interface files, too) whether or
>> not a datatype comes with a role annotation. This isn't hard, though. It
>> might even help in pretty-printing.
>>
>>
>> An alternative would be to have a way of setting roles differently on
>> export than internally. I don't think this breaks the type system, but it's
>> yet another thing to specify and support. And we'd have to consider the
>> possibility that some module will import a datatype from multiple
>> re-exporting modules, each with different ascribed role annotations. Is
>> this an error? Does GHC take some sort of least upper bound? I prefer not
>> to go here, but there's nothing terribly wrong with this approach.
>>
>> Richard
>>
>> On Apr 10, 2015, at 9:37 AM, David Terei <dave.terei at gmail.com> wrote:
>>
>> > I'll prepare a patch for the userguide soon.
>> >
>> > As for something better, yes I think we can and should. It's on my
>> > todo list :) Basically, the new-GND design has all the mechanisms to
>> > be safe, but sadly the defaults are rather worrying. Without explicit
>> > annotations from the user, module abstractions are broken. This is why
>> > we left GND out of Safe Haskell for the moment as it is a subtle and
>> > easy mistake to make.
>> >
>> > If the module contained explicit role annotations then it could be
>> > allowed. The discussion in
>> > https://ghc.haskell.org/trac/ghc/ticket/8827 has other solutions that
>> > I prefer, such as only exporting the Coerce instance if all the
>> > constructors are exported, it seems that the ship sailed on these
>> > bigger changes sadly.
>> >
>> > Cheers,
>> > David
>> >
>> > On 9 April 2015 at 00:56, Simon Peyton Jones <simonpj at microsoft.com>
>> wrote:
>> >> There is a long discussion on
>> https://ghc.haskell.org/trac/ghc/ticket/8827
>> >> about whether the new Coercible story makes GND ok for Safe Haskell.
>> At a
>> >> type-soundness level, definitely yes.  But there are other
>> less-clear-cut
>> >> issues like ?breaking abstractions? to consider.  The decision on the
>> ticket
>> >> (comment:36) seems to be: GND stays out of Safe Haskell for now, but
>> there
>> >> is room for a better proposal.
>> >>
>> >>
>> >>
>> >> I don?t have an opinion myself. David Terei and David Mazieres are in
>> the
>> >> driving seat, but I?m sure they?ll be responsive to user input.
>> >>
>> >>
>> >>
>> >> However, I think the user manual may not have kept up with #8827.  The
>> >> sentence ?GeneralizedNewtypeDeriving ? It can be used to violate
>> constructor
>> >> access control, by allowing untrusted code to manipulate protected data
>> >> types in ways the data type author did not intend, breaking invariants
>> they
>> >> have established.?  vanished from the 7.8 user manual (links below).
>> Maybe
>> >> it should be restored.
>> >>
>> >>
>> >>
>> >> Safe Haskell aficionados, would you like to offer a patch for the
>> manual?
>> >> And maybe also a less drastic remedy than omitting GND altogether?
>> >>
>> >>
>> >>
>> >> Simon
>> >>
>> >>
>> >>
>> >> From: Omari Norman [mailto:omari at smileystation.com]
>> >> Sent: 09 April 2015 02:44
>> >> To: haskell Cafe
>> >> Subject: Generalized Newtype Deriving not allowed in Safe Haskell
>> >>
>> >>
>> >>
>> >> When compiling code with Generalized Newtype Deriving and the
>> -fwarn-unsafe
>> >> flag, I get
>> >>
>> >>
>> >>
>> >> -XGeneralizedNewtypeDeriving is not allowed in Safe Haskell
>> >>
>> >>
>> >>
>> >> This happens both in GHC 7.8 and GHC 7.10.
>> >>
>> >>
>> >>
>> >> I thought I remembered reading somewhere that GNTD is now part of the
>> safe
>> >> language?  The GHC manual used to state that GNTD is not allowed in
>> Safe
>> >> Haskell:
>> >>
>> >>
>> >>
>> >>
>> https://downloads.haskell.org/~ghc/7.6.3/docs/html/users_guide/safe-haskell.html#safe-language
>> >>
>> >>
>> >>
>> >> But this language on GNTD not being part of the safe language was
>> removed in
>> >> the 7.8 manual:
>> >>
>> >>
>> >>
>> >>
>> https://downloads.haskell.org/~ghc/7.8.2/docs/html/users_guide/safe-haskell.html#safe-language
>> >>
>> >>
>> >>
>> >> The GHC release notes don't say anything about this one way or the
>> other.
>> >> Thoughts?
>> >>
>> >>
>> >> _______________________________________________
>> >> ghc-devs mailing list
>> >> ghc-devs at haskell.org
>> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> >>
>> > _______________________________________________
>> > ghc-devs mailing list
>> > ghc-devs at haskell.org
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> >
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>
>
>
> --
> J. Douglas McClean
>
> (781) 561-5540 (cell)
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150410/2f9072fa/attachment-0001.html>

From marlowsd at gmail.com  Sat Apr 11 20:26:48 2015
From: marlowsd at gmail.com (Simon Marlow)
Date: Sat, 11 Apr 2015 21:26:48 +0100
Subject: stack traces when debugging GHC
In-Reply-To: <A7E7AF02-D58F-40D6-A1B3-63704FD99015@cis.upenn.edu>
References: <A7E7AF02-D58F-40D6-A1B3-63704FD99015@cis.upenn.edu>
Message-ID: <55298388.7040502@gmail.com>

On 09/02/2015 02:51, Richard Eisenberg wrote:
> Hi devs,
>
> I've just made a miraculous discovery and I want to share!
>
> It has happened many times that I create some bizarre error in GHC and have no clue where it comes from. In the past, I've ended up using pprTrace to label all calls of the failing function, sometimes recursively, until I get an idea of what's going on. This is terribly painful. And then, I noticed that the function Debug.Trace.traceStack (just in the `base` package, not part of GHC) will print out a stack trace, when profiling is enabled. So, I tried building a profiled build of GHC, with -DDEBUG and -fprof-auto (just by editing the "prof" section of build.mk).
>
> And then, voila, ASSERTs now print stack traces! And, with a small change in Outputable, I can get pprTrace to print stack traces, too! Hooray!

I should have advertised this more widely, thanks for pointing it out.

> I'd love to put this on the wiki. Any clue where this might be found?

I see you've added a reference buried in Debugging/Compiler.  Why don't 
we just make traceStack the default?  Perhaps with a flag to disable (or 
enable) the stack trace.

Cheers,
Simon

From moritz at lichtzwerge.de  Sat Apr 11 23:39:29 2015
From: moritz at lichtzwerge.de (Moritz Angermann)
Date: Sun, 12 Apr 2015 07:39:29 +0800
Subject: stack traces when debugging GHC
In-Reply-To: <55298388.7040502@gmail.com>
References: <A7E7AF02-D58F-40D6-A1B3-63704FD99015@cis.upenn.edu>
 <55298388.7040502@gmail.com>
Message-ID: <19256E3C-E94A-4190-93FF-7DC99493A239@lichtzwerge.de>


> On 12 Apr 2015, at 04:26, Simon Marlow <marlowsd at gmail.com> wrote:
> 
>> On 09/02/2015 02:51, Richard Eisenberg wrote:
>> Hi devs,
>> 
>> I've just made a miraculous discovery and I want to share!
>> 
>> It has happened many times that I create some bizarre error in GHC and have no clue where it comes from. In the past, I've ended up using pprTrace to label all calls of the failing function, sometimes recursively, until I get an idea of what's going on. This is terribly painful. And then, I noticed that the function Debug.Trace.traceStack (just in the `base` package, not part of GHC) will print out a stack trace, when profiling is enabled. So, I tried building a profiled build of GHC, with -DDEBUG and -fprof-auto (just by editing the "prof" section of build.mk).
>> 
>> And then, voila, ASSERTs now print stack traces! And, with a small change in Outputable, I can get pprTrace to print stack traces, too! Hooray!
> 
> I should have advertised this more widely, thanks for pointing it out.
> 
>> I'd love to put this on the wiki. Any clue where this might be found?
> 
> I see you've added a reference buried in Debugging/Compiler.  Why don't we just make traceStack the default?  Perhaps with a flag to disable (or enable) the stack trace.

I think this is a great idea and would really like to see this being the default.

> 
> Cheers,
> Simon
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From dave.terei at gmail.com  Sun Apr 12 08:51:41 2015
From: dave.terei at gmail.com (David Terei)
Date: Sun, 12 Apr 2015 01:51:41 -0700
Subject: Generalized Newtype Deriving not allowed in Safe Haskell
In-Reply-To: <ee5348affe8f498bbbd8c3660591932c@DB4PR30MB030.064d.mgd.msft.net>
References: <CAL2jp559kvXbd3MxEC0Zrg8dzFrUbSYVMwzky3-oHMjKATurDA@mail.gmail.com>
 <0d913dcca48b47abadb7ab6b4125b906@DB4PR30MB030.064d.mgd.msft.net>
 <CACHt1w8Mc_LoZaACO-sPvWxMwragP35bfKL2cz+_GD4tF24OOg@mail.gmail.com>
 <ee5348affe8f498bbbd8c3660591932c@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <CACHt1w9GOLMPu+jBdUsi33rvyC_bQ=3MkFAzooTfG6MJ5_FxKA@mail.gmail.com>

On 10 April 2015 at 01:48, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> |  prefer, such as only exporting the Coerce instance if all the
> |  constructors are exported, it seems that the ship sailed on these
>
> Coercible is relatively recent; I don't think we should regard it as cast in stone.
>
> But yes, the Coerbible instance of a newtype is only available when the data constructor for the newtype is lexically in scope.

Yes, so as you point out in the paper, this is done to preserve
abstractions, but the same rule isn't applied to data types since some
types like IORef don't even have constructors that can be in scope.

Ideally I'd like to find a way forward that works for everyone and
isn't just a Safe Haskell mode setting.

I think the first question is, are there situations where you'd want
to use `coerce` internally to a module but disallow it externally? The
role mechanism is a little awkward as it doesn't allow this (although
it does for newtype's). If yes, then I think we should start there.

If it seems we don't need external vs internal control, then we could
simply change the default to be that GHC sets referential type
parameters to nominal and allows them to be weakened to referential
through role annotations. We could use hackage to test how much
breakage this would cause.

The third option is something Safe Haskell specific, so probably
applying the newtype constructor rule to data types.

>
> Simon
>
> |  -----Original Message-----
> |  From: davidterei at gmail.com [mailto:davidterei at gmail.com] On Behalf Of
> |  David Terei
> |  Sent: 10 April 2015 09:38
> |  To: Simon Peyton Jones
> |  Cc: Omari Norman; haskell Cafe; ghc-devs at haskell.org
> |  Subject: Re: Generalized Newtype Deriving not allowed in Safe Haskell
> |
> |  I'll prepare a patch for the userguide soon.
> |
> |  As for something better, yes I think we can and should. It's on my todo
> |  list :) Basically, the new-GND design has all the mechanisms to be
> |  safe, but sadly the defaults are rather worrying. Without explicit
> |  annotations from the user, module abstractions are broken. This is why
> |  we left GND out of Safe Haskell for the moment as it is a subtle and
> |  easy mistake to make.
> |
> |  If the module contained explicit role annotations then it could be
> |  allowed. The discussion in
> |  https://ghc.haskell.org/trac/ghc/ticket/8827 has other solutions that I
> |  prefer, such as only exporting the Coerce instance if all the
> |  constructors are exported, it seems that the ship sailed on these
> |  bigger changes sadly.
> |
> |  Cheers,
> |  David
> |
> |  On 9 April 2015 at 00:56, Simon Peyton Jones <simonpj at microsoft.com>
> |  wrote:
> |  > There is a long discussion on
> |  > https://ghc.haskell.org/trac/ghc/ticket/8827
> |  > about whether the new Coercible story makes GND ok for Safe Haskell.
> |  > At a type-soundness level, definitely yes.  But there are other
> |  > less-clear-cut issues like ?breaking abstractions? to consider.  The
> |  > decision on the ticket
> |  > (comment:36) seems to be: GND stays out of Safe Haskell for now, but
> |  > there is room for a better proposal.
> |  >
> |  >
> |  >
> |  > I don?t have an opinion myself. David Terei and David Mazieres are in
> |  > the driving seat, but I?m sure they?ll be responsive to user input.
> |  >
> |  >
> |  >
> |  > However, I think the user manual may not have kept up with #8827.
> |  The
> |  > sentence ?GeneralizedNewtypeDeriving ? It can be used to violate
> |  > constructor access control, by allowing untrusted code to manipulate
> |  > protected data types in ways the data type author did not intend,
> |  > breaking invariants they have established.?  vanished from the 7.8
> |  > user manual (links below).  Maybe it should be restored.
> |  >
> |  >
> |  >
> |  > Safe Haskell aficionados, would you like to offer a patch for the
> |  manual?
> |  > And maybe also a less drastic remedy than omitting GND altogether?
> |  >
> |  >
> |  >
> |  > Simon
> |  >
> |  >
> |  >
> |  > From: Omari Norman [mailto:omari at smileystation.com]
> |  > Sent: 09 April 2015 02:44
> |  > To: haskell Cafe
> |  > Subject: Generalized Newtype Deriving not allowed in Safe Haskell
> |  >
> |  >
> |  >
> |  > When compiling code with Generalized Newtype Deriving and the
> |  > -fwarn-unsafe flag, I get
> |  >
> |  >
> |  >
> |  > -XGeneralizedNewtypeDeriving is not allowed in Safe Haskell
> |  >
> |  >
> |  >
> |  > This happens both in GHC 7.8 and GHC 7.10.
> |  >
> |  >
> |  >
> |  > I thought I remembered reading somewhere that GNTD is now part of the
> |  > safe language?  The GHC manual used to state that GNTD is not allowed
> |  > in Safe
> |  > Haskell:
> |  >
> |  >
> |  >
> |  > https://downloads.haskell.org/~ghc/7.6.3/docs/html/users_guide/safe-
> |  ha
> |  > skell.html#safe-language
> |  >
> |  >
> |  >
> |  > But this language on GNTD not being part of the safe language was
> |  > removed in the 7.8 manual:
> |  >
> |  >
> |  >
> |  > https://downloads.haskell.org/~ghc/7.8.2/docs/html/users_guide/safe-
> |  ha
> |  > skell.html#safe-language
> |  >
> |  >
> |  >
> |  > The GHC release notes don't say anything about this one way or the
> |  other.
> |  > Thoughts?
> |  >
> |  >
> |  > _______________________________________________
> |  > ghc-devs mailing list
> |  > ghc-devs at haskell.org
> |  > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> |  >
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From ggreif at gmail.com  Sun Apr 12 14:33:46 2015
From: ggreif at gmail.com (Gabor Greif)
Date: Sun, 12 Apr 2015 16:33:46 +0200
Subject: Overlapping instances for poly-kinded data
Message-ID: <CAK-hX0kTdvEM9j4f+JmUhaoFBx2o+nHz5jb_O1EAktAfgz2OVQ@mail.gmail.com>

Hi all,

I observe a strange "deriving Show" behaviour for my data type Foo
that has proxies:

data Foo :: k -> * where
  Foo :: Proxy t -> Foo t

deriving instance Show (Foo t)

This works as expected. But now I add

instance {-# OVERLAPPING #-} KnownSymbol s => Show (Proxy (s :: Symbol)) where
  show = ('#' :) . symbolVal
instance {-# OVERLAPPING #-} KnownNat n => Show (Proxy (n :: Nat)) where
  show = ('#' :) . show . natVal

these orphan instances, and "deriving Show" won't pick them up. When I
go and specialise
deriving instance {-# OVERLAPPING #-} KnownNat t => Show (Foo (t :: Nat))
deriving instance {-# OVERLAPPING #-} KnownSymbol s => Show (Foo (s :: Symbol))

then it seems to work allright. Is polykinded derivation so different
from the monokinded one? Or is this simply a bug?

(a more elaborate WIP example can be found here:
https://code.google.com/p/omega/source/browse/mosaic/CloudAtlas.hs?spec=svn2465&r=2465)

Cheers,

    Gabor

From eir at cis.upenn.edu  Sun Apr 12 17:10:57 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Sun, 12 Apr 2015 18:10:57 +0100
Subject: Overlapping instances for poly-kinded data
In-Reply-To: <CAK-hX0kTdvEM9j4f+JmUhaoFBx2o+nHz5jb_O1EAktAfgz2OVQ@mail.gmail.com>
References: <CAK-hX0kTdvEM9j4f+JmUhaoFBx2o+nHz5jb_O1EAktAfgz2OVQ@mail.gmail.com>
Message-ID: <BE324717-CB5A-4553-8577-FE71CEBFDEED@cis.upenn.edu>

I believe this is expected behavior, for sufficiently nuanced expectations.

Let's consider a simpler story:

```
{-# LANGUAGE TypeSynonymInstances, FlexibleInstances #-}

class ShowType a where
  showType :: a -> String

instance ShowType Int where
  showType _ = "Int"
instance ShowType Bool where
  showType _ = "Bool"

instance ShowType [a] where
  showType _ = "list"
instance {-# OVERLAPPING #-} ShowType String where
  showType _ = "String"

class ShowType a => IsListy a where
  isListy :: a -> String

instance IsListy Int where
  isListy x = showType x ++ " is not listy."
instance IsListy Bool where
  isListy x = showType x ++ " is not listy."

instance IsListy [a] where
  isListy x = showType x ++ " is indeed listy."
```

The Int and Bool instances are just for exposition -- they don't really matter.

The question here is: should the `IsListy [a]` instance compile? (Spoiler: It does.) It seems at first that the instance should not compile. For the definition of `isListy` to compile, GHC needs an instance for `ShowType [a]`. But, we don't know what `a` is... so there are two potential instances. Indeed, if we add the following definition

```
topIsListy :: [a] -> String
topIsListy x = showType x ++ " is indeed listy."
```

we get a "several potential instances" error. Yet, the instance compiles.

The reason is that GHC is a little cheeky when picking instances while in the middle of an instance declaration: it skips the check for extra instances that might match. To understand why this happens, imagine adding the following declaration to our module:

```
instance {-# OVERLAPPING #-} IsListy String where
  isListy _ = "Strings sure are listy!"
```

Such an instance makes sense in this context. Yet, if GHC did a full overlap check when compiling the  `IsListy [a]` instance, that instance would fail, and we'd never get to write the nice, coherent set of instances we see here (including the new overlapping string instance). So, GHC skips the overlap check.

The exact same scenario is happening with your Show instance. The new orphans are overlapping, but GHC skips the overlap check in your Show instance. PolyKinds is not at issue.

Personally, I'm ambivalent on this skip-overlap-check-in-instances behavior. I understand why it's there, but I find it somewhat disturbing. If others do, too, I wouldn't be against opening a debate about this design decision.

I hope this is helpful!
Richard

On Apr 12, 2015, at 3:33 PM, Gabor Greif <ggreif at gmail.com> wrote:

> Hi all,
> 
> I observe a strange "deriving Show" behaviour for my data type Foo
> that has proxies:
> 
> data Foo :: k -> * where
>  Foo :: Proxy t -> Foo t
> 
> deriving instance Show (Foo t)
> 
> This works as expected. But now I add
> 
> instance {-# OVERLAPPING #-} KnownSymbol s => Show (Proxy (s :: Symbol)) where
>  show = ('#' :) . symbolVal
> instance {-# OVERLAPPING #-} KnownNat n => Show (Proxy (n :: Nat)) where
>  show = ('#' :) . show . natVal
> 
> these orphan instances, and "deriving Show" won't pick them up. When I
> go and specialise
> deriving instance {-# OVERLAPPING #-} KnownNat t => Show (Foo (t :: Nat))
> deriving instance {-# OVERLAPPING #-} KnownSymbol s => Show (Foo (s :: Symbol))
> 
> then it seems to work allright. Is polykinded derivation so different
> from the monokinded one? Or is this simply a bug?
> 
> (a more elaborate WIP example can be found here:
> https://code.google.com/p/omega/source/browse/mosaic/CloudAtlas.hs?spec=svn2465&r=2465)
> 
> Cheers,
> 
>    Gabor
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


From eir at cis.upenn.edu  Sun Apr 12 20:01:22 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Sun, 12 Apr 2015 21:01:22 +0100
Subject: Generalized Newtype Deriving not allowed in Safe Haskell
In-Reply-To: <CACHt1w9GOLMPu+jBdUsi33rvyC_bQ=3MkFAzooTfG6MJ5_FxKA@mail.gmail.com>
References: <CAL2jp559kvXbd3MxEC0Zrg8dzFrUbSYVMwzky3-oHMjKATurDA@mail.gmail.com>
 <0d913dcca48b47abadb7ab6b4125b906@DB4PR30MB030.064d.mgd.msft.net>
 <CACHt1w8Mc_LoZaACO-sPvWxMwragP35bfKL2cz+_GD4tF24OOg@mail.gmail.com>
 <ee5348affe8f498bbbd8c3660591932c@DB4PR30MB030.064d.mgd.msft.net>
 <CACHt1w9GOLMPu+jBdUsi33rvyC_bQ=3MkFAzooTfG6MJ5_FxKA@mail.gmail.com>
Message-ID: <2C81A9E3-EA90-46E6-8A52-7B0300F1E046@cis.upenn.edu>


On Apr 12, 2015, at 9:51 AM, David Terei <dave.terei at gmail.com> wrote:
> 
> Ideally I'd like to find a way forward that works for everyone and
> isn't just a Safe Haskell mode setting.

Agreed. I'm not convinced this can be done, but it's certainly worth trying.

> 
> I think the first question is, are there situations where you'd want
> to use `coerce` internally to a module but disallow it externally? The
> role mechanism is a little awkward as it doesn't allow this (although
> it does for newtype's). If yes, then I think we should start there.

Yes, the ability to use `coerce` within one module but not elsewhere would be nice. This can currently be simulated (without too much difficulty) with newtypes. A datatype D can have a more permissive role signature than an equivalent newtype N (where `newtype N = MkN D`). The package then exports N (without its constructor). This effectively allows local uses of `coerce`, even for datatypes. A more direct mechanism would be better, but I don't think we should bend over backwards for it.

> 
> If it seems we don't need external vs internal control, then we could
> simply change the default to be that GHC sets referential type
> parameters to nominal and allows them to be weakened to referential
> through role annotations. We could use hackage to test how much
> breakage this would cause.

I worry that the breakage would be significant. But, now that authors have had a chance to put in role annotations, maybe it wouldn't be so bad. The change to GHC to make this happen is trivial: just change default_role in TcTyDecls.initialRoleEnv1. I don't have the infrastructure around to make an all-of-Hackage test, but I'm happy to support someone else who does.

Richard

From dave.terei at gmail.com  Sun Apr 12 23:41:01 2015
From: dave.terei at gmail.com (David Terei)
Date: Sun, 12 Apr 2015 16:41:01 -0700
Subject: Generalized Newtype Deriving not allowed in Safe Haskell
In-Reply-To: <2C81A9E3-EA90-46E6-8A52-7B0300F1E046@cis.upenn.edu>
References: <CAL2jp559kvXbd3MxEC0Zrg8dzFrUbSYVMwzky3-oHMjKATurDA@mail.gmail.com>
 <0d913dcca48b47abadb7ab6b4125b906@DB4PR30MB030.064d.mgd.msft.net>
 <CACHt1w8Mc_LoZaACO-sPvWxMwragP35bfKL2cz+_GD4tF24OOg@mail.gmail.com>
 <ee5348affe8f498bbbd8c3660591932c@DB4PR30MB030.064d.mgd.msft.net>
 <CACHt1w9GOLMPu+jBdUsi33rvyC_bQ=3MkFAzooTfG6MJ5_FxKA@mail.gmail.com>
 <2C81A9E3-EA90-46E6-8A52-7B0300F1E046@cis.upenn.edu>
Message-ID: <CACHt1w8W6s13e3uZ+u9=h02xE9Kc+3nCNxb==RJ3Fo3-YShDgw@mail.gmail.com>

On 12 April 2015 at 13:01, Richard Eisenberg <eir at cis.upenn.edu> wrote:
>
> On Apr 12, 2015, at 9:51 AM, David Terei <dave.terei at gmail.com> wrote:
>>
>> Ideally I'd like to find a way forward that works for everyone and
>> isn't just a Safe Haskell mode setting.
>
> Agreed. I'm not convinced this can be done, but it's certainly worth trying.
>
>>
>> I think the first question is, are there situations where you'd want
>> to use `coerce` internally to a module but disallow it externally? The
>> role mechanism is a little awkward as it doesn't allow this (although
>> it does for newtype's). If yes, then I think we should start there.
>
> Yes, the ability to use `coerce` within one module but not elsewhere would be nice. This can currently be simulated (without too much difficulty) with newtypes. A datatype D can have a more permissive role signature than an equivalent newtype N (where `newtype N = MkN D`). The package then exports N (without its constructor). This effectively allows local uses of `coerce`, even for datatypes. A more direct mechanism would be better, but I don't think we should bend over backwards for it.
>
>>
>> If it seems we don't need external vs internal control, then we could
>> simply change the default to be that GHC sets referential type
>> parameters to nominal and allows them to be weakened to referential
>> through role annotations. We could use hackage to test how much
>> breakage this would cause.
>
> I worry that the breakage would be significant. But, now that authors have had a chance to put in role annotations, maybe it wouldn't be so bad. The change to GHC to make this happen is trivial: just change default_role in TcTyDecls.initialRoleEnv1. I don't have the infrastructure around to make an all-of-Hackage test, but I'm happy to support someone else who does.

A way to temper this as discussed in the ticket is to have the default
be determined by the export list. A data type with all it's
constructors exported can default to representational roles when
possible, while nominal roles would be the default when a subset of
constructors are exported.

This is more complex for users to understand, but does map to the
semantics expected under Haskell2010. It may be best to drive this
decision with data.

Luckily we've also got infrastructure for testing against Hackage:
http://hackage.haskell.org/package/hackager

>
> Richard
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From simonpj at microsoft.com  Mon Apr 13 06:50:04 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 13 Apr 2015 06:50:04 +0000
Subject: GHC Trac down
Message-ID: <0678dde4bfa34f899f1d8a3fad1ac523@DB4PR30MB030.064d.mgd.msft.net>

Is GHC's Trac down again?  It's not working for me.
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150413/7600f52f/attachment.html>

From simonpj at microsoft.com  Mon Apr 13 06:57:15 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 13 Apr 2015 06:57:15 +0000
Subject: stack traces when debugging GHC
In-Reply-To: <55298388.7040502@gmail.com>
References: <A7E7AF02-D58F-40D6-A1B3-63704FD99015@cis.upenn.edu>
 <55298388.7040502@gmail.com>
Message-ID: <fd60876e21cf4cc88e1b48e883e6ed59@DB4PR30MB030.064d.mgd.msft.net>

|  I see you've added a reference buried in Debugging/Compiler.  Why don't
|  we just make traceStack the default?  Perhaps with a flag to disable
|  (or enable) the stack trace.

Sounds desirable to me. It'll only work with profiling, though, of course.

Would someone like to do this?  At least make a ticket?

Simon

|  -----Original Message-----
|  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Simon
|  Marlow
|  Sent: 11 April 2015 21:27
|  To: Richard Eisenberg; ghc-devs at haskell.org Devs
|  Subject: Re: stack traces when debugging GHC
|  
|  On 09/02/2015 02:51, Richard Eisenberg wrote:
|  > Hi devs,
|  >
|  > I've just made a miraculous discovery and I want to share!
|  >
|  > It has happened many times that I create some bizarre error in GHC
|  and have no clue where it comes from. In the past, I've ended up using
|  pprTrace to label all calls of the failing function, sometimes
|  recursively, until I get an idea of what's going on. This is terribly
|  painful. And then, I noticed that the function Debug.Trace.traceStack
|  (just in the `base` package, not part of GHC) will print out a stack
|  trace, when profiling is enabled. So, I tried building a profiled build
|  of GHC, with -DDEBUG and -fprof-auto (just by editing the "prof"
|  section of build.mk).
|  >
|  > And then, voila, ASSERTs now print stack traces! And, with a small
|  change in Outputable, I can get pprTrace to print stack traces, too!
|  Hooray!
|  
|  I should have advertised this more widely, thanks for pointing it out.
|  
|  > I'd love to put this on the wiki. Any clue where this might be found?
|  
|  I see you've added a reference buried in Debugging/Compiler.  Why don't
|  we just make traceStack the default?  Perhaps with a flag to disable
|  (or
|  enable) the stack trace.
|  
|  Cheers,
|  Simon
|  _______________________________________________
|  ghc-devs mailing list
|  ghc-devs at haskell.org
|  http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From simonpj at microsoft.com  Mon Apr 13 07:10:59 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 13 Apr 2015 07:10:59 +0000
Subject: Generalized Newtype Deriving not allowed in Safe Haskell
In-Reply-To: <CACHt1w9GOLMPu+jBdUsi33rvyC_bQ=3MkFAzooTfG6MJ5_FxKA@mail.gmail.com>
References: <CAL2jp559kvXbd3MxEC0Zrg8dzFrUbSYVMwzky3-oHMjKATurDA@mail.gmail.com>
 <0d913dcca48b47abadb7ab6b4125b906@DB4PR30MB030.064d.mgd.msft.net>
 <CACHt1w8Mc_LoZaACO-sPvWxMwragP35bfKL2cz+_GD4tF24OOg@mail.gmail.com>
 <ee5348affe8f498bbbd8c3660591932c@DB4PR30MB030.064d.mgd.msft.net>
 <CACHt1w9GOLMPu+jBdUsi33rvyC_bQ=3MkFAzooTfG6MJ5_FxKA@mail.gmail.com>
Message-ID: <bd7fb584e9b0400ea13a04c628d77cc6@DB4PR30MB030.064d.mgd.msft.net>

David

If you would like to lead a debate, and drive it to a conclusion, that would be most helpful.  

Usually it's constructive to write a wiki page that sets out the design choices, with examples to illustrate their consequences, to set the terms of the debate.  Otherwise you risk misunderstandings, with red herrings being discussed repeatedly.

Thanks

Simon

|  -----Original Message-----
|  From: davidterei at gmail.com [mailto:davidterei at gmail.com] On Behalf Of
|  David Terei
|  Sent: 12 April 2015 09:52
|  To: Simon Peyton Jones
|  Cc: Omari Norman; ghc-devs at haskell.org; haskell Cafe
|  Subject: Re: Generalized Newtype Deriving not allowed in Safe Haskell
|  
|  On 10 April 2015 at 01:48, Simon Peyton Jones <simonpj at microsoft.com>
|  wrote:
|  > |  prefer, such as only exporting the Coerce instance if all the
|  > | constructors are exported, it seems that the ship sailed on these
|  >
|  > Coercible is relatively recent; I don't think we should regard it as
|  cast in stone.
|  >
|  > But yes, the Coerbible instance of a newtype is only available when
|  the data constructor for the newtype is lexically in scope.
|  
|  Yes, so as you point out in the paper, this is done to preserve
|  abstractions, but the same rule isn't applied to data types since some
|  types like IORef don't even have constructors that can be in scope.
|  
|  Ideally I'd like to find a way forward that works for everyone and
|  isn't just a Safe Haskell mode setting.
|  
|  I think the first question is, are there situations where you'd want to
|  use `coerce` internally to a module but disallow it externally? The
|  role mechanism is a little awkward as it doesn't allow this (although
|  it does for newtype's). If yes, then I think we should start there.
|  
|  If it seems we don't need external vs internal control, then we could
|  simply change the default to be that GHC sets referential type
|  parameters to nominal and allows them to be weakened to referential
|  through role annotations. We could use hackage to test how much
|  breakage this would cause.
|  
|  The third option is something Safe Haskell specific, so probably
|  applying the newtype constructor rule to data types.
|  
|  >
|  > Simon
|  >
|  > |  -----Original Message-----
|  > |  From: davidterei at gmail.com [mailto:davidterei at gmail.com] On Behalf
|  > | Of  David Terei
|  > |  Sent: 10 April 2015 09:38
|  > |  To: Simon Peyton Jones
|  > |  Cc: Omari Norman; haskell Cafe; ghc-devs at haskell.org
|  > |  Subject: Re: Generalized Newtype Deriving not allowed in Safe
|  > | Haskell
|  > |
|  > |  I'll prepare a patch for the userguide soon.
|  > |
|  > |  As for something better, yes I think we can and should. It's on my
|  > | todo  list :) Basically, the new-GND design has all the mechanisms
|  > | to be  safe, but sadly the defaults are rather worrying. Without
|  > | explicit  annotations from the user, module abstractions are
|  broken.
|  > | This is why  we left GND out of Safe Haskell for the moment as it
|  is
|  > | a subtle and  easy mistake to make.
|  > |
|  > |  If the module contained explicit role annotations then it could be
|  > | allowed. The discussion in
|  > |  https://ghc.haskell.org/trac/ghc/ticket/8827 has other solutions
|  > | that I  prefer, such as only exporting the Coerce instance if all
|  > | the  constructors are exported, it seems that the ship sailed on
|  > | these  bigger changes sadly.
|  > |
|  > |  Cheers,
|  > |  David
|  > |
|  > |  On 9 April 2015 at 00:56, Simon Peyton Jones
|  > | <simonpj at microsoft.com>
|  > |  wrote:
|  > |  > There is a long discussion on
|  > |  > https://ghc.haskell.org/trac/ghc/ticket/8827
|  > |  > about whether the new Coercible story makes GND ok for Safe
|  Haskell.
|  > |  > At a type-soundness level, definitely yes.  But there are other
|  > | > less-clear-cut issues like ?breaking abstractions? to consider.
|  > | The  > decision on the ticket  > (comment:36) seems to be: GND
|  stays
|  > | out of Safe Haskell for now, but  > there is room for a better
|  > | proposal.
|  > |  >
|  > |  >
|  > |  >
|  > |  > I don?t have an opinion myself. David Terei and David Mazieres
|  > | are in  > the driving seat, but I?m sure they?ll be responsive to
|  user input.
|  > |  >
|  > |  >
|  > |  >
|  > |  > However, I think the user manual may not have kept up with
|  #8827.
|  > |  The
|  > |  > sentence ?GeneralizedNewtypeDeriving ? It can be used to violate
|  > | > constructor access control, by allowing untrusted code to
|  > | manipulate  > protected data types in ways the data type author did
|  > | not intend,  > breaking invariants they have established.?
|  vanished
|  > | from the 7.8  > user manual (links below).  Maybe it should be
|  restored.
|  > |  >
|  > |  >
|  > |  >
|  > |  > Safe Haskell aficionados, would you like to offer a patch for
|  the
|  > | manual?
|  > |  > And maybe also a less drastic remedy than omitting GND
|  altogether?
|  > |  >
|  > |  >
|  > |  >
|  > |  > Simon
|  > |  >
|  > |  >
|  > |  >
|  > |  > From: Omari Norman [mailto:omari at smileystation.com]  > Sent: 09
|  > | April 2015 02:44  > To: haskell Cafe  > Subject: Generalized
|  Newtype
|  > | Deriving not allowed in Safe Haskell  >  >  >  > When compiling
|  code
|  > | with Generalized Newtype Deriving and the  > -fwarn-unsafe flag, I
|  > | get  >  >  >  > -XGeneralizedNewtypeDeriving is not allowed in Safe
|  > | Haskell  >  >  >  > This happens both in GHC 7.8 and GHC 7.10.
|  > |  >
|  > |  >
|  > |  >
|  > |  > I thought I remembered reading somewhere that GNTD is now part
|  of
|  > | the  > safe language?  The GHC manual used to state that GNTD is
|  not
|  > | allowed  > in Safe  > Haskell:
|  > |  >
|  > |  >
|  > |  >
|  > |  >
|  > |
|  https://downloads.haskell.org/~ghc/7.6.3/docs/html/users_guide/safe-
|  > |  ha
|  > |  > skell.html#safe-language
|  > |  >
|  > |  >
|  > |  >
|  > |  > But this language on GNTD not being part of the safe language
|  was
|  > | > removed in the 7.8 manual:
|  > |  >
|  > |  >
|  > |  >
|  > |  >
|  > |
|  https://downloads.haskell.org/~ghc/7.8.2/docs/html/users_guide/safe-
|  > |  ha
|  > |  > skell.html#safe-language
|  > |  >
|  > |  >
|  > |  >
|  > |  > The GHC release notes don't say anything about this one way or
|  > | the  other.
|  > |  > Thoughts?
|  > |  >
|  > |  >
|  > |  > _______________________________________________
|  > |  > ghc-devs mailing list
|  > |  > ghc-devs at haskell.org
|  > |  > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
|  > |  >
|  > _______________________________________________
|  > ghc-devs mailing list
|  > ghc-devs at haskell.org
|  > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From simonpj at microsoft.com  Mon Apr 13 07:48:52 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 13 Apr 2015 07:48:52 +0000
Subject: Overlapping instances for poly-kinded data
In-Reply-To: <BE324717-CB5A-4553-8577-FE71CEBFDEED@cis.upenn.edu>
References: <CAK-hX0kTdvEM9j4f+JmUhaoFBx2o+nHz5jb_O1EAktAfgz2OVQ@mail.gmail.com>
 <BE324717-CB5A-4553-8577-FE71CEBFDEED@cis.upenn.edu>
Message-ID: <fa473399957648e3b92d21d151480649@DB4PR30MB030.064d.mgd.msft.net>

|  Personally, I'm ambivalent on this skip-overlap-check-in-instances
|  behavior. I understand why it's there, but I find it somewhat
|  disturbing. If others do, too, I wouldn't be against opening a debate
|  about this design decision.

I agree that it's a "bit disturbing". Here's the comment that justifies it.  If someone can think of a better way, I'm all ears.

Simon


Note [Subtle interaction of recursion and overlap]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Consider this
  class C a where { op1,op2 :: a -> a }
  instance C a => C [a] where
    op1 x = op2 x ++ op2 x
    op2 x = ...
  instance C [Int] where
    ...

When type-checking the C [a] instance, we need a C [a] dictionary (for
the call of op2).  If we look up in the instance environment, we find
an overlap.  And in *general* the right thing is to complain (see Note
[Overlapping instances] in InstEnv).  But in *this* case it's wrong to
complain, because we just want to delegate to the op2 of this same
instance.

Why is this justified?  Because we generate a (C [a]) constraint in
a context in which 'a' cannot be instantiated to anything that matches
other overlapping instances, or else we would not be executing this
version of op1 in the first place.

It might even be a bit disguised:

  nullFail :: C [a] => [a] -> [a]
  nullFail x = op2 x ++ op2 x

  instance C a => C [a] where
    op1 x = nullFail x

Precisely this is used in package 'regex-base', module Context.hs.
See the overlapping instances for RegexContext, and the fact that they
call 'nullFail' just like the example above.  The DoCon package also
does the same thing; it shows up in module Fraction.hs.

Conclusion: when typechecking the methods in a C [a] instance, we want to
treat the 'a' as an *existential* type variable, in the sense described
by Note [Binding when looking up instances].  That is why isOverlappableTyVar
responds True to an InstSkol, which is the kind of skolem we use in
tcInstDecl2.

|  -----Original Message-----
|  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
|  Richard Eisenberg
|  Sent: 12 April 2015 18:11
|  To: Gabor Greif
|  Cc: ghc-devs
|  Subject: Re: Overlapping instances for poly-kinded data
|  
|  I believe this is expected behavior, for sufficiently nuanced
|  expectations.
|  
|  Let's consider a simpler story:
|  
|  ```
|  {-# LANGUAGE TypeSynonymInstances, FlexibleInstances #-}
|  
|  class ShowType a where
|    showType :: a -> String
|  
|  instance ShowType Int where
|    showType _ = "Int"
|  instance ShowType Bool where
|    showType _ = "Bool"
|  
|  instance ShowType [a] where
|    showType _ = "list"
|  instance {-# OVERLAPPING #-} ShowType String where
|    showType _ = "String"
|  
|  class ShowType a => IsListy a where
|    isListy :: a -> String
|  
|  instance IsListy Int where
|    isListy x = showType x ++ " is not listy."
|  instance IsListy Bool where
|    isListy x = showType x ++ " is not listy."
|  
|  instance IsListy [a] where
|    isListy x = showType x ++ " is indeed listy."
|  ```
|  
|  The Int and Bool instances are just for exposition -- they don't really
|  matter.
|  
|  The question here is: should the `IsListy [a]` instance compile?
|  (Spoiler: It does.) It seems at first that the instance should not
|  compile. For the definition of `isListy` to compile, GHC needs an
|  instance for `ShowType [a]`. But, we don't know what `a` is... so there
|  are two potential instances. Indeed, if we add the following definition
|  
|  ```
|  topIsListy :: [a] -> String
|  topIsListy x = showType x ++ " is indeed listy."
|  ```
|  
|  we get a "several potential instances" error. Yet, the instance
|  compiles.
|  
|  The reason is that GHC is a little cheeky when picking instances while
|  in the middle of an instance declaration: it skips the check for extra
|  instances that might match. To understand why this happens, imagine
|  adding the following declaration to our module:
|  
|  ```
|  instance {-# OVERLAPPING #-} IsListy String where
|    isListy _ = "Strings sure are listy!"
|  ```
|  
|  Such an instance makes sense in this context. Yet, if GHC did a full
|  overlap check when compiling the  `IsListy [a]` instance, that instance
|  would fail, and we'd never get to write the nice, coherent set of
|  instances we see here (including the new overlapping string instance).
|  So, GHC skips the overlap check.
|  
|  The exact same scenario is happening with your Show instance. The new
|  orphans are overlapping, but GHC skips the overlap check in your Show
|  instance. PolyKinds is not at issue.
|  
|  Personally, I'm ambivalent on this skip-overlap-check-in-instances
|  behavior. I understand why it's there, but I find it somewhat
|  disturbing. If others do, too, I wouldn't be against opening a debate
|  about this design decision.
|  
|  I hope this is helpful!
|  Richard
|  
|  On Apr 12, 2015, at 3:33 PM, Gabor Greif <ggreif at gmail.com> wrote:
|  
|  > Hi all,
|  >
|  > I observe a strange "deriving Show" behaviour for my data type Foo
|  > that has proxies:
|  >
|  > data Foo :: k -> * where
|  >  Foo :: Proxy t -> Foo t
|  >
|  > deriving instance Show (Foo t)
|  >
|  > This works as expected. But now I add
|  >
|  > instance {-# OVERLAPPING #-} KnownSymbol s => Show (Proxy (s ::
|  > Symbol)) where  show = ('#' :) . symbolVal instance {-# OVERLAPPING
|  > #-} KnownNat n => Show (Proxy (n :: Nat)) where  show = ('#' :) .
|  show
|  > . natVal
|  >
|  > these orphan instances, and "deriving Show" won't pick them up. When
|  I
|  > go and specialise deriving instance {-# OVERLAPPING #-} KnownNat t =>
|  > Show (Foo (t :: Nat)) deriving instance {-# OVERLAPPING #-}
|  > KnownSymbol s => Show (Foo (s :: Symbol))
|  >
|  > then it seems to work allright. Is polykinded derivation so different
|  > from the monokinded one? Or is this simply a bug?
|  >
|  > (a more elaborate WIP example can be found here:
|  >
|  https://code.google.com/p/omega/source/browse/mosaic/CloudAtlas.hs?spe
|  > c=svn2465&r=2465)
|  >
|  > Cheers,
|  >
|  >    Gabor
|  > _______________________________________________
|  > ghc-devs mailing list
|  > ghc-devs at haskell.org
|  > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
|  
|  _______________________________________________
|  ghc-devs mailing list
|  ghc-devs at haskell.org
|  http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From k-bx at k-bx.com  Mon Apr 13 14:41:10 2015
From: k-bx at k-bx.com (Kostiantyn Rybnikov)
Date: Mon, 13 Apr 2015 17:41:10 +0300
Subject: GHC Trac down
In-Reply-To: <0678dde4bfa34f899f1d8a3fad1ac523@DB4PR30MB030.064d.mgd.msft.net>
References: <0678dde4bfa34f899f1d8a3fad1ac523@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <CAAbahfQm2tTfR62-90xGxt_6E6-__4rBAaceTf4-AFbNk1mHmA@mail.gmail.com>

It's down (well, timeouts) currently also.

I recall someone asked for volunteers to help with trac problems and
optimization. If this is still valid, I'd volunteer to help. Who should I
contact?

Thanks.

On Mon, Apr 13, 2015 at 9:50 AM, Simon Peyton Jones <simonpj at microsoft.com>
wrote:

>  Is GHC?s Trac down again?  It?s not working for me.
>
> Simon
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150413/be62b806/attachment.html>

From ky3 at atamo.com  Tue Apr 14 00:38:41 2015
From: ky3 at atamo.com (Kim-Ee Yeoh)
Date: Tue, 14 Apr 2015 07:38:41 +0700
Subject: GHC Trac down
In-Reply-To: <CAAbahfQm2tTfR62-90xGxt_6E6-__4rBAaceTf4-AFbNk1mHmA@mail.gmail.com>
References: <0678dde4bfa34f899f1d8a3fad1ac523@DB4PR30MB030.064d.mgd.msft.net>
 <CAAbahfQm2tTfR62-90xGxt_6E6-__4rBAaceTf4-AFbNk1mHmA@mail.gmail.com>
Message-ID: <CAPY+ZdRHhTkpeVdprJc7dYDKRi=rnZgjqD1uGeN3Q_rcsOnmDQ@mail.gmail.com>

On Mon, Apr 13, 2015 at 9:41 PM, Kostiantyn Rybnikov <k-bx at k-bx.com> wrote:

> I recall someone asked for volunteers to help with trac problems and
> optimization. If this is still valid, I'd volunteer to help. Who should I
> contact?


Herbert Valerio Riedel did some work installing the new spam filter on
trac. Perhaps you might start with him?

-- Kim-Ee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150414/1cf5cac3/attachment.html>

From dave.terei at gmail.com  Tue Apr 14 01:18:02 2015
From: dave.terei at gmail.com (David Terei)
Date: Mon, 13 Apr 2015 18:18:02 -0700
Subject: Generalized Newtype Deriving not allowed in Safe Haskell
In-Reply-To: <bd7fb584e9b0400ea13a04c628d77cc6@DB4PR30MB030.064d.mgd.msft.net>
References: <CAL2jp559kvXbd3MxEC0Zrg8dzFrUbSYVMwzky3-oHMjKATurDA@mail.gmail.com>
 <0d913dcca48b47abadb7ab6b4125b906@DB4PR30MB030.064d.mgd.msft.net>
 <CACHt1w8Mc_LoZaACO-sPvWxMwragP35bfKL2cz+_GD4tF24OOg@mail.gmail.com>
 <ee5348affe8f498bbbd8c3660591932c@DB4PR30MB030.064d.mgd.msft.net>
 <CACHt1w9GOLMPu+jBdUsi33rvyC_bQ=3MkFAzooTfG6MJ5_FxKA@mail.gmail.com>
 <bd7fb584e9b0400ea13a04c628d77cc6@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <CACHt1w-B2CJFs7YUHQxPg4RakBUQoOjFGkrx9hgs9BsHjsw8Aw@mail.gmail.com>

Good advice. I'll set that up soon.

On 13 April 2015 at 00:10, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> David
>
> If you would like to lead a debate, and drive it to a conclusion, that would be most helpful.
>
> Usually it's constructive to write a wiki page that sets out the design choices, with examples to illustrate their consequences, to set the terms of the debate.  Otherwise you risk misunderstandings, with red herrings being discussed repeatedly.
>
> Thanks
>
> Simon
>
> |  -----Original Message-----
> |  From: davidterei at gmail.com [mailto:davidterei at gmail.com] On Behalf Of
> |  David Terei
> |  Sent: 12 April 2015 09:52
> |  To: Simon Peyton Jones
> |  Cc: Omari Norman; ghc-devs at haskell.org; haskell Cafe
> |  Subject: Re: Generalized Newtype Deriving not allowed in Safe Haskell
> |
> |  On 10 April 2015 at 01:48, Simon Peyton Jones <simonpj at microsoft.com>
> |  wrote:
> |  > |  prefer, such as only exporting the Coerce instance if all the
> |  > | constructors are exported, it seems that the ship sailed on these
> |  >
> |  > Coercible is relatively recent; I don't think we should regard it as
> |  cast in stone.
> |  >
> |  > But yes, the Coerbible instance of a newtype is only available when
> |  the data constructor for the newtype is lexically in scope.
> |
> |  Yes, so as you point out in the paper, this is done to preserve
> |  abstractions, but the same rule isn't applied to data types since some
> |  types like IORef don't even have constructors that can be in scope.
> |
> |  Ideally I'd like to find a way forward that works for everyone and
> |  isn't just a Safe Haskell mode setting.
> |
> |  I think the first question is, are there situations where you'd want to
> |  use `coerce` internally to a module but disallow it externally? The
> |  role mechanism is a little awkward as it doesn't allow this (although
> |  it does for newtype's). If yes, then I think we should start there.
> |
> |  If it seems we don't need external vs internal control, then we could
> |  simply change the default to be that GHC sets referential type
> |  parameters to nominal and allows them to be weakened to referential
> |  through role annotations. We could use hackage to test how much
> |  breakage this would cause.
> |
> |  The third option is something Safe Haskell specific, so probably
> |  applying the newtype constructor rule to data types.
> |
> |  >
> |  > Simon
> |  >
> |  > |  -----Original Message-----
> |  > |  From: davidterei at gmail.com [mailto:davidterei at gmail.com] On Behalf
> |  > | Of  David Terei
> |  > |  Sent: 10 April 2015 09:38
> |  > |  To: Simon Peyton Jones
> |  > |  Cc: Omari Norman; haskell Cafe; ghc-devs at haskell.org
> |  > |  Subject: Re: Generalized Newtype Deriving not allowed in Safe
> |  > | Haskell
> |  > |
> |  > |  I'll prepare a patch for the userguide soon.
> |  > |
> |  > |  As for something better, yes I think we can and should. It's on my
> |  > | todo  list :) Basically, the new-GND design has all the mechanisms
> |  > | to be  safe, but sadly the defaults are rather worrying. Without
> |  > | explicit  annotations from the user, module abstractions are
> |  broken.
> |  > | This is why  we left GND out of Safe Haskell for the moment as it
> |  is
> |  > | a subtle and  easy mistake to make.
> |  > |
> |  > |  If the module contained explicit role annotations then it could be
> |  > | allowed. The discussion in
> |  > |  https://ghc.haskell.org/trac/ghc/ticket/8827 has other solutions
> |  > | that I  prefer, such as only exporting the Coerce instance if all
> |  > | the  constructors are exported, it seems that the ship sailed on
> |  > | these  bigger changes sadly.
> |  > |
> |  > |  Cheers,
> |  > |  David
> |  > |
> |  > |  On 9 April 2015 at 00:56, Simon Peyton Jones
> |  > | <simonpj at microsoft.com>
> |  > |  wrote:
> |  > |  > There is a long discussion on
> |  > |  > https://ghc.haskell.org/trac/ghc/ticket/8827
> |  > |  > about whether the new Coercible story makes GND ok for Safe
> |  Haskell.
> |  > |  > At a type-soundness level, definitely yes.  But there are other
> |  > | > less-clear-cut issues like ?breaking abstractions? to consider.
> |  > | The  > decision on the ticket  > (comment:36) seems to be: GND
> |  stays
> |  > | out of Safe Haskell for now, but  > there is room for a better
> |  > | proposal.
> |  > |  >
> |  > |  >
> |  > |  >
> |  > |  > I don?t have an opinion myself. David Terei and David Mazieres
> |  > | are in  > the driving seat, but I?m sure they?ll be responsive to
> |  user input.
> |  > |  >
> |  > |  >
> |  > |  >
> |  > |  > However, I think the user manual may not have kept up with
> |  #8827.
> |  > |  The
> |  > |  > sentence ?GeneralizedNewtypeDeriving ? It can be used to violate
> |  > | > constructor access control, by allowing untrusted code to
> |  > | manipulate  > protected data types in ways the data type author did
> |  > | not intend,  > breaking invariants they have established.?
> |  vanished
> |  > | from the 7.8  > user manual (links below).  Maybe it should be
> |  restored.
> |  > |  >
> |  > |  >
> |  > |  >
> |  > |  > Safe Haskell aficionados, would you like to offer a patch for
> |  the
> |  > | manual?
> |  > |  > And maybe also a less drastic remedy than omitting GND
> |  altogether?
> |  > |  >
> |  > |  >
> |  > |  >
> |  > |  > Simon
> |  > |  >
> |  > |  >
> |  > |  >
> |  > |  > From: Omari Norman [mailto:omari at smileystation.com]  > Sent: 09
> |  > | April 2015 02:44  > To: haskell Cafe  > Subject: Generalized
> |  Newtype
> |  > | Deriving not allowed in Safe Haskell  >  >  >  > When compiling
> |  code
> |  > | with Generalized Newtype Deriving and the  > -fwarn-unsafe flag, I
> |  > | get  >  >  >  > -XGeneralizedNewtypeDeriving is not allowed in Safe
> |  > | Haskell  >  >  >  > This happens both in GHC 7.8 and GHC 7.10.
> |  > |  >
> |  > |  >
> |  > |  >
> |  > |  > I thought I remembered reading somewhere that GNTD is now part
> |  of
> |  > | the  > safe language?  The GHC manual used to state that GNTD is
> |  not
> |  > | allowed  > in Safe  > Haskell:
> |  > |  >
> |  > |  >
> |  > |  >
> |  > |  >
> |  > |
> |  https://downloads.haskell.org/~ghc/7.6.3/docs/html/users_guide/safe-
> |  > |  ha
> |  > |  > skell.html#safe-language
> |  > |  >
> |  > |  >
> |  > |  >
> |  > |  > But this language on GNTD not being part of the safe language
> |  was
> |  > | > removed in the 7.8 manual:
> |  > |  >
> |  > |  >
> |  > |  >
> |  > |  >
> |  > |
> |  https://downloads.haskell.org/~ghc/7.8.2/docs/html/users_guide/safe-
> |  > |  ha
> |  > |  > skell.html#safe-language
> |  > |  >
> |  > |  >
> |  > |  >
> |  > |  > The GHC release notes don't say anything about this one way or
> |  > | the  other.
> |  > |  > Thoughts?
> |  > |  >
> |  > |  >
> |  > |  > _______________________________________________
> |  > |  > ghc-devs mailing list
> |  > |  > ghc-devs at haskell.org
> |  > |  > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> |  > |  >
> |  > _______________________________________________
> |  > ghc-devs mailing list
> |  > ghc-devs at haskell.org
> |  > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From asr at eafit.edu.co  Tue Apr 14 04:24:25 2015
From: asr at eafit.edu.co (=?UTF-8?B?QW5kcsOpcyBTaWNhcmQtUmFtw61yZXo=?=)
Date: Mon, 13 Apr 2015 23:24:25 -0500
Subject: Phabricator as bug tracker system (off topic)
Message-ID: <CAOUWSGD7hqOa7kHOOJV9q+rUQpzqxt19nc+9sD9tiOp11u9xgA@mail.gmail.com>

Hi,

(I apologise for this off topic message)

>From the discussion started in
https://mail.haskell.org/pipermail/ghc-devs/2014-June/005117.html, it
seems GHC HQ didn't choose Phabricator as bug tracker system because
migrating from Trac "...There's no real pressure to do so and it would
be tons of work".

Since Google is shutting down Google Code, we need to move Agda's bug
tracker system from Google Code to something else.

>From some preliminary investigation, it seems Phabricator bug tracker
system (Maniphest) is more robust than GitHub one.

I would appreciate some feedback related to Maniphest or other bug
tracker system.

Thanks,

-- 
Andr?s

From k-bx at k-bx.com  Tue Apr 14 06:48:39 2015
From: k-bx at k-bx.com (Kostiantyn Rybnikov)
Date: Tue, 14 Apr 2015 09:48:39 +0300
Subject: GHC Trac down
In-Reply-To: <CAPY+ZdRHhTkpeVdprJc7dYDKRi=rnZgjqD1uGeN3Q_rcsOnmDQ@mail.gmail.com>
References: <0678dde4bfa34f899f1d8a3fad1ac523@DB4PR30MB030.064d.mgd.msft.net>
 <CAAbahfQm2tTfR62-90xGxt_6E6-__4rBAaceTf4-AFbNk1mHmA@mail.gmail.com>
 <CAPY+ZdRHhTkpeVdprJc7dYDKRi=rnZgjqD1uGeN3Q_rcsOnmDQ@mail.gmail.com>
Message-ID: <CAAbahfSidxGqiOUoYFA1kuMHsAGE22ijS-xMudKdGJ8Wi=+uWw@mail.gmail.com>

Yes, we started conversation in #haskell-infrastructure channel now, thank
you.

On Tue, Apr 14, 2015 at 3:38 AM, Kim-Ee Yeoh <ky3 at atamo.com> wrote:

>
> On Mon, Apr 13, 2015 at 9:41 PM, Kostiantyn Rybnikov <k-bx at k-bx.com>
> wrote:
>
>> I recall someone asked for volunteers to help with trac problems and
>> optimization. If this is still valid, I'd volunteer to help. Who should I
>> contact?
>
>
> Herbert Valerio Riedel did some work installing the new spam filter on
> trac. Perhaps you might start with him?
>
> -- Kim-Ee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150414/2c59c738/attachment.html>

From jan.stolarek at p.lodz.pl  Tue Apr 14 06:52:01 2015
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Tue, 14 Apr 2015 08:52:01 +0200
Subject: Phabricator as bug tracker system (off topic)
In-Reply-To: <CAOUWSGD7hqOa7kHOOJV9q+rUQpzqxt19nc+9sD9tiOp11u9xgA@mail.gmail.com>
References: <CAOUWSGD7hqOa7kHOOJV9q+rUQpzqxt19nc+9sD9tiOp11u9xgA@mail.gmail.com>
Message-ID: <201504140852.01752.jan.stolarek@p.lodz.pl>

> we need to move Agda's bug tracker system from Google Code to something else.
Finally! I disliked Google Code so much that if I found a bug in Agda I either mailed it to the 
discussion list or did not report it at all.

And now on topic:
- the only project I've been using Trac for is GHC. It seems to lack some more advanced features 
but from a developer's perspective it conatins everything necessary to do the job. It can be 
customized to the needs of a project. I think the only major downside of Trac is that a single 
installation can only run a single project. Probably not a problem for Agda.
- GitHubs issue tracker lacks many fetures that might be essential for a larger project. For 
example you can't assign related issues or blocked issues. There is no way to add attachments or 
customize it in any way (eg. GHC Trac can list test names for a given ticket and connects tickets 
to phabricator). Still better than Google Code IMO.
- I've been also using and administrating Redmine. It is feature rich and much more intuitive than 
Trac (at least for me). One instance can run multiple projects. Major downside: it starts slowly 
(ie. if no one was using it recently and someone visits it the instance must be started and that 
takes several seconds).
- I've been also using Bugzilla, mostly to report bugs for some open-source project. For a pearson 
that only reports bugs it was OK. Not sure how it works for a developer.

HTH

Janek

>
> From some preliminary investigation, it seems Phabricator bug tracker
> system (Maniphest) is more robust than GitHub one.
>
> I would appreciate some feedback related to Maniphest or other bug
> tracker system.
>
> Thanks,



---
Politechnika ??dzka
Lodz University of Technology

Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata.
Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k?
prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie.

This email contains information intended solely for the use of the individual to whom it is addressed.
If you are not the intended recipient or if you have received this message in error,
please notify the sender and delete it from your system.

From karel.gardas at centrum.cz  Tue Apr 14 06:56:31 2015
From: karel.gardas at centrum.cz (Karel Gardas)
Date: Tue, 14 Apr 2015 08:56:31 +0200
Subject: Phabricator as bug tracker system (off topic)
In-Reply-To: <201504140852.01752.jan.stolarek@p.lodz.pl>
References: <CAOUWSGD7hqOa7kHOOJV9q+rUQpzqxt19nc+9sD9tiOp11u9xgA@mail.gmail.com>
 <201504140852.01752.jan.stolarek@p.lodz.pl>
Message-ID: <552CBA1F.8050801@centrum.cz>

On 04/14/15 08:52 AM, Jan Stolarek wrote:
> And now on topic:
> - the only project I've been using Trac for is GHC. It seems to lack some more advanced features
> but from a developer's perspective it conatins everything necessary to do the job. It can be
> customized to the needs of a project. I think the only major downside of Trac is that a single
> installation can only run a single project. Probably not a problem for Agda.

Jan,

I'm using Trac for managing 5 independent internal projects without a 
problem and this is a single installation.

Cheers,
Karel

From jan.stolarek at p.lodz.pl  Tue Apr 14 06:58:07 2015
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Tue, 14 Apr 2015 08:58:07 +0200
Subject: Phabricator as bug tracker system (off topic)
In-Reply-To: <552CBA1F.8050801@centrum.cz>
References: <CAOUWSGD7hqOa7kHOOJV9q+rUQpzqxt19nc+9sD9tiOp11u9xgA@mail.gmail.com>
 <201504140852.01752.jan.stolarek@p.lodz.pl> <552CBA1F.8050801@centrum.cz>
Message-ID: <201504140858.07464.jan.stolarek@p.lodz.pl>

> I'm using Trac for managing 5 independent internal projects without a
> problem and this is a single installation.
It looks like I'm not up to date with latest administrative Trac features. Sorry.

Janek

---
Politechnika ??dzka
Lodz University of Technology

Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata.
Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k?
prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie.

This email contains information intended solely for the use of the individual to whom it is addressed.
If you are not the intended recipient or if you have received this message in error,
please notify the sender and delete it from your system.

From austin at well-typed.com  Tue Apr 14 17:47:30 2015
From: austin at well-typed.com (Austin Seipp)
Date: Tue, 14 Apr 2015 12:47:30 -0500
Subject: GHC Weekly News - 2015/04/14
Message-ID: <CAEs96n2paWLhDev1mN2y3BxPKDhYREU8Z3JQD738HRBCmQQT0g@mail.gmail.com>

(You can find a copy of this post online at
https://ghc.haskell.org/trac/ghc/blog/weekly20150414)

Hi *,

It's been a few weeks since the last news bulletin - your editor
apologizes about that. It's actually been a relatively slow few weeks
here too, and busy-ness outside of GHC has attracted some of my
attention. Despite that, GHC 7.10.1 was released, a new HP alpha is
out, and things are moving along smoothly. Now that the release is
done, things are quitely moving along in `HEAD` - with people
committing code with reckless abandon, of course.

This week, GHC HQ met up, but it's been very light since the 7.10.1
release. Currently there isn't anything pushing us to do a 7.10.2
release at least for a few more weeks it looks like - but see below.

  - We puzzled a bit about the release status of 7.10.2, and thought:
it's only holding up people who are depending on it. So, who's
depending on it, and what do they need fixed? See below for more.

  - We also talked a bit about performance - it seems the compiler has
been getting much slower over time since the 7.8.x release series, and
it's time to reign it in. Austin will be spending his week
investigating a bit of this, and the causes.

== 7.10.2 Status ==

So, you may be wondering when the 7.10.2 release is. The trick is it
happens when you tell us it should happen!

So far, taking a look at milestone:7.10.2, we've fixed about half the
bugs we currently have marked down to fix. But we're probably going to
punt some of those - and we're not sure all the ones that are there
should be.

So this is a call: **If you need something to be fixed during 7.10.2,
please file a ticket, set the milestone, and alert us**. The sooner
the better, because it'll inform us as to when we should release.
Emailing `ghc-devs at haskell.org` is also a sure-fire way to get our
attention.

And remember: you can always find out the latest about the next
release at the Status page (in this case, for 7.10.2) -
https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.2

== Call for help: DocBook to AsciiDoc ==

The GHC team needs some help. A few months ago, we put out a poll to
convert our DocBook-based manual to AsciiDoc.

The poll had a mostly lukewarm reception, with the idea that it will
A) make life easier for people who frequently modify the users guide,
and B) make life easier for people who add things irregularly, as a
lower barrier to entry.

It looks like we still **want** to do this - but alas, many of us
don't have time!

So, we're asking the public: Is anyone willing to step up and help
here? For example, it may be possible to get a long ways with just
`pandoc`, but we need someone to finish it - and in return, we'll help
along the way!

== List chatter ==

  - Austin Seipp announced GHC
    7.10.1. https://mail.haskell.org/pipermail/ghc-devs/2015-March/008700.html

  - Mark Lentczner announced an alpha Haskell Platform
    release. https://mail.haskell.org/pipermail/ghc-devs/2015-March/008724.html

  - David Macek announced MSYS2 packages for GHC on Windows, and also
    asked for some help with continuous windows building - Windows
    hackers should help out!
https://mail.haskell.org/pipermail/ghc-devs/2015-March/008735.html

  - Jan Stolarek reports about increased memory usage with GHC 7.10.1.
    https://mail.haskell.org/pipermail/ghc-devs/2015-April/008751.html

  - Thomas Miedema chimed into a thread started by Karel Gardas about
    better parallelizing the GHC build - and hopefully we can get
    something good out of
    it. https://mail.haskell.org/pipermail/ghc-devs/2015-April/008749.html

  - Austin Seipp made a call for help on working on and improving the
    GHC homepage, and luckily Sergey Bushnyak answered the call and
    has helped out!
    https://mail.haskell.org/pipermail/ghc-devs/2015-April/008762.html

  - Ozgun Ataman kicked off a thread about slower compilation times,
    with some nasty numbers. It's becoming more clear compiler
    performance should be a priority for 7.12, and we've let some
    things slip away from us:
    https://mail.haskell.org/pipermail/ghc-devs/2015-April/008766.html

  - A GHC user, Dave, asked the list about some questions with Cross
    Compilation, as he's attempting to get GHC to work natively inside
    the Open Embedded build environment. Unfortunately, things haven't
    been going well so far, and any input from enterprising hackers is
    appreciated:
    https://mail.haskell.org/pipermail/ghc-devs/2015-April/008774.html

  - Dan Aloni has started a discussion about improving GHC's error
    messages, spurred by a popular blog post he wrote and posted on
    Reddit about some Happy/GHC improvements he's made. This is a
    difficult area (error messages in general are hard) to work on, so
    thanks to Dan for helping!
    https://mail.haskell.org/pipermail/ghc-devs/2015-April/008778.html

  - Simon Peyton Jones started a discussion about
    `GeneralizedNewtypeDeriving` and Safe Haskell, in particular,
    whatever the current status, our documentation doesn't accurately
    reflect it! Perhaps someone could help out writing the
    documentation based on the current status quo?
    https://mail.haskell.org/pipermail/ghc-devs/2015-April/008783.html

  - Tamar Christina started a thread about replacing `ghc-split`, an
    old Perl script inside GHC, but he wanted to know: what do we do
    about a regex replacement? Mikhail Glushenkov spoke up about a
    similar decision the LLVM developers used: to use the OpenBSD
    regex implementation.
https://mail.haskell.org/pipermail/ghc-devs/2015-April/008785.html

  - Alan Zimmerman has posted several questions and threads about the
    parser and the status of API annotations, which he's been
    furiously working on now that GHC 7.10 is being used on
    Hackage. Interested onlookers could learn a thing or two!
    https://mail.haskell.org/pipermail/ghc-devs/2015-April/008782.html
    &
    https://mail.haskell.org/pipermail/ghc-devs/2015-April/008787.html
    &
    https://mail.haskell.org/pipermail/ghc-devs/2015-April/008794.html

  - Gabor Greif has a question about some seemingly strange behavior
    regarding the interaction between poly-kinded `data` types and
    overlapping instances. Richard sez: this behavior is
    expected. https://mail.haskell.org/pipermail/ghc-devs/2015-April/008804.html

== Noteworthy commits ==

  - Commit de1160be047790afde4ec76de0a81ba3be0c73fa - refactor the
    story around switch cases (with a code-size improvement)

  - Commit 995e8c1c8692b60c907c7d2ccea179d52ca8e69e - drop old
    `integer-gmp-0.5` source code.

  - Commit 59f7a7b6091e9c0564f3f370d09398d8c9cd8ad5 - Restore unwind
    information generation (fixes DWARF generation)

  - Commit 9f0f99fd41ff82cc223d3b682703e508efb564d2 - Fix an old bug
    in the demand analyzer (with some nice compiler performance
    boosts).

  - Commit a7524eaed33324e2155c47d4a705bef1d70a2b5b - Support for
    multiple signature files in scope (Backpack).

== Closed tickets ==

#10222, #10219, #8057, #10226, #10220, #9723, #10230, #10208, #10236,
#10213, #10231, #10240, #10243, #10237, #10224, #8811, #10197, #10252,
#9958, #10253, #8248, #10207, #10214, #9964, #10194, #10251, #10188,
#10257, #10247, #10247, #9160, #10259, #9965, #10265, #10264, #10286,
#10282, #10290, #10291, #10300, #9929, #8276, #10218, #10148, #10232,
#10274, #10275, #10195, and #10233.

-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From joehillen at gmail.com  Tue Apr 14 19:07:57 2015
From: joehillen at gmail.com (Joe Hillenbrand)
Date: Tue, 14 Apr 2015 12:07:57 -0700
Subject: GHC Weekly News - 2015/04/14
In-Reply-To: <CAEs96n2paWLhDev1mN2y3BxPKDhYREU8Z3JQD738HRBCmQQT0g@mail.gmail.com>
References: <CAEs96n2paWLhDev1mN2y3BxPKDhYREU8Z3JQD738HRBCmQQT0g@mail.gmail.com>
Message-ID: <CANJQ5C6cEBmuwCY_c4hpLzQCq-imY30cG3qW2EvsqeCGtsX16Q@mail.gmail.com>

> == Call for help: DocBook to AsciiDoc ==
>
> So, we're asking the public: Is anyone willing to step up and help
here? For example, it may be possible to get a long ways with just
`pandoc`, but we need someone to finish it - and in return, we'll help
along the way!


Do you have anymore information on this? Tickets? Current status? This
is the first I've heard about the proposed conversion, and I follow
ghc-devs@ pretty closely.

On Tue, Apr 14, 2015 at 10:47 AM, Austin Seipp <austin at well-typed.com> wrote:
> (You can find a copy of this post online at
> https://ghc.haskell.org/trac/ghc/blog/weekly20150414)
>
> Hi *,
>
> It's been a few weeks since the last news bulletin - your editor
> apologizes about that. It's actually been a relatively slow few weeks
> here too, and busy-ness outside of GHC has attracted some of my
> attention. Despite that, GHC 7.10.1 was released, a new HP alpha is
> out, and things are moving along smoothly. Now that the release is
> done, things are quitely moving along in `HEAD` - with people
> committing code with reckless abandon, of course.
>
> This week, GHC HQ met up, but it's been very light since the 7.10.1
> release. Currently there isn't anything pushing us to do a 7.10.2
> release at least for a few more weeks it looks like - but see below.
>
>   - We puzzled a bit about the release status of 7.10.2, and thought:
> it's only holding up people who are depending on it. So, who's
> depending on it, and what do they need fixed? See below for more.
>
>   - We also talked a bit about performance - it seems the compiler has
> been getting much slower over time since the 7.8.x release series, and
> it's time to reign it in. Austin will be spending his week
> investigating a bit of this, and the causes.
>
> == 7.10.2 Status ==
>
> So, you may be wondering when the 7.10.2 release is. The trick is it
> happens when you tell us it should happen!
>
> So far, taking a look at milestone:7.10.2, we've fixed about half the
> bugs we currently have marked down to fix. But we're probably going to
> punt some of those - and we're not sure all the ones that are there
> should be.
>
> So this is a call: **If you need something to be fixed during 7.10.2,
> please file a ticket, set the milestone, and alert us**. The sooner
> the better, because it'll inform us as to when we should release.
> Emailing `ghc-devs at haskell.org` is also a sure-fire way to get our
> attention.
>
> And remember: you can always find out the latest about the next
> release at the Status page (in this case, for 7.10.2) -
> https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.2
>
> == Call for help: DocBook to AsciiDoc ==
>
> The GHC team needs some help. A few months ago, we put out a poll to
> convert our DocBook-based manual to AsciiDoc.
>
> The poll had a mostly lukewarm reception, with the idea that it will
> A) make life easier for people who frequently modify the users guide,
> and B) make life easier for people who add things irregularly, as a
> lower barrier to entry.
>
> It looks like we still **want** to do this - but alas, many of us
> don't have time!
>
> So, we're asking the public: Is anyone willing to step up and help
> here? For example, it may be possible to get a long ways with just
> `pandoc`, but we need someone to finish it - and in return, we'll help
> along the way!
>
> == List chatter ==
>
>   - Austin Seipp announced GHC
>     7.10.1. https://mail.haskell.org/pipermail/ghc-devs/2015-March/008700.html
>
>   - Mark Lentczner announced an alpha Haskell Platform
>     release. https://mail.haskell.org/pipermail/ghc-devs/2015-March/008724.html
>
>   - David Macek announced MSYS2 packages for GHC on Windows, and also
>     asked for some help with continuous windows building - Windows
>     hackers should help out!
> https://mail.haskell.org/pipermail/ghc-devs/2015-March/008735.html
>
>   - Jan Stolarek reports about increased memory usage with GHC 7.10.1.
>     https://mail.haskell.org/pipermail/ghc-devs/2015-April/008751.html
>
>   - Thomas Miedema chimed into a thread started by Karel Gardas about
>     better parallelizing the GHC build - and hopefully we can get
>     something good out of
>     it. https://mail.haskell.org/pipermail/ghc-devs/2015-April/008749.html
>
>   - Austin Seipp made a call for help on working on and improving the
>     GHC homepage, and luckily Sergey Bushnyak answered the call and
>     has helped out!
>     https://mail.haskell.org/pipermail/ghc-devs/2015-April/008762.html
>
>   - Ozgun Ataman kicked off a thread about slower compilation times,
>     with some nasty numbers. It's becoming more clear compiler
>     performance should be a priority for 7.12, and we've let some
>     things slip away from us:
>     https://mail.haskell.org/pipermail/ghc-devs/2015-April/008766.html
>
>   - A GHC user, Dave, asked the list about some questions with Cross
>     Compilation, as he's attempting to get GHC to work natively inside
>     the Open Embedded build environment. Unfortunately, things haven't
>     been going well so far, and any input from enterprising hackers is
>     appreciated:
>     https://mail.haskell.org/pipermail/ghc-devs/2015-April/008774.html
>
>   - Dan Aloni has started a discussion about improving GHC's error
>     messages, spurred by a popular blog post he wrote and posted on
>     Reddit about some Happy/GHC improvements he's made. This is a
>     difficult area (error messages in general are hard) to work on, so
>     thanks to Dan for helping!
>     https://mail.haskell.org/pipermail/ghc-devs/2015-April/008778.html
>
>   - Simon Peyton Jones started a discussion about
>     `GeneralizedNewtypeDeriving` and Safe Haskell, in particular,
>     whatever the current status, our documentation doesn't accurately
>     reflect it! Perhaps someone could help out writing the
>     documentation based on the current status quo?
>     https://mail.haskell.org/pipermail/ghc-devs/2015-April/008783.html
>
>   - Tamar Christina started a thread about replacing `ghc-split`, an
>     old Perl script inside GHC, but he wanted to know: what do we do
>     about a regex replacement? Mikhail Glushenkov spoke up about a
>     similar decision the LLVM developers used: to use the OpenBSD
>     regex implementation.
> https://mail.haskell.org/pipermail/ghc-devs/2015-April/008785.html
>
>   - Alan Zimmerman has posted several questions and threads about the
>     parser and the status of API annotations, which he's been
>     furiously working on now that GHC 7.10 is being used on
>     Hackage. Interested onlookers could learn a thing or two!
>     https://mail.haskell.org/pipermail/ghc-devs/2015-April/008782.html
>     &
>     https://mail.haskell.org/pipermail/ghc-devs/2015-April/008787.html
>     &
>     https://mail.haskell.org/pipermail/ghc-devs/2015-April/008794.html
>
>   - Gabor Greif has a question about some seemingly strange behavior
>     regarding the interaction between poly-kinded `data` types and
>     overlapping instances. Richard sez: this behavior is
>     expected. https://mail.haskell.org/pipermail/ghc-devs/2015-April/008804.html
>
> == Noteworthy commits ==
>
>   - Commit de1160be047790afde4ec76de0a81ba3be0c73fa - refactor the
>     story around switch cases (with a code-size improvement)
>
>   - Commit 995e8c1c8692b60c907c7d2ccea179d52ca8e69e - drop old
>     `integer-gmp-0.5` source code.
>
>   - Commit 59f7a7b6091e9c0564f3f370d09398d8c9cd8ad5 - Restore unwind
>     information generation (fixes DWARF generation)
>
>   - Commit 9f0f99fd41ff82cc223d3b682703e508efb564d2 - Fix an old bug
>     in the demand analyzer (with some nice compiler performance
>     boosts).
>
>   - Commit a7524eaed33324e2155c47d4a705bef1d70a2b5b - Support for
>     multiple signature files in scope (Backpack).
>
> == Closed tickets ==
>
> #10222, #10219, #8057, #10226, #10220, #9723, #10230, #10208, #10236,
> #10213, #10231, #10240, #10243, #10237, #10224, #8811, #10197, #10252,
> #9958, #10253, #8248, #10207, #10214, #9964, #10194, #10251, #10188,
> #10257, #10247, #10247, #9160, #10259, #9965, #10265, #10264, #10286,
> #10282, #10290, #10291, #10300, #9929, #8276, #10218, #10148, #10232,
> #10274, #10275, #10195, and #10233.
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From ozataman at gmail.com  Tue Apr 14 19:56:00 2015
From: ozataman at gmail.com (Ozgun Ataman)
Date: Tue, 14 Apr 2015 15:56:00 -0400
Subject: Slower Compilation on GHC 7.8.4 (vs. 7.6.3)
In-Reply-To: <55243283.3050506@gmail.com>
References: <CAGn37G2cTGy88F-cHjFg9XEbDqaYqQetKR4iPqUnzT9DDXdWDQ@mail.gmail.com>
 <55243283.3050506@gmail.com>
Message-ID: <CAGn37G3ifA7AttvFD2E7ZqDW_4rJtn=f6xxb7s=FZW6ZwzMtEw@mail.gmail.com>

Hello all,

Thank you for the comments and apologies that it took a bit of time to get
back to you. My colleague Michael and I have taken a stab at a package
demonstrating the slowdown. Our hypothesis was that the presence of type
declarations, large values/literals, typeclass instantiations and
engagement of TH caused at least some of the slowdown we were seeing in our
app code. It turns out this was only partially true:

   - 500 random type declarations were a modest 10-25% slower.
   - Simply instantiating types with a given class did not contribute that
   much to the slowdown (around 5% on top of type declarations)
   - There was no notable slowdown on large values/literals (false
   hypothesis)
   - TH-enabled derivations were over 100% slower (lens and safecopy used
   as test subjects)
      - lens: ~100% slower
      - safecopy: ~125% slower
   - The slowdowns appeared to be super-linear in at least some cases.
   Doubling the declaration count to 1000 increased the % of the slowdown:
      - Declarations: 30% slower
      - lens TH slowdown: ~100% slower (stayed the same)
      - safecopy TH slowdown: ~140% slower


I'd be happy to create a ticket if this is sufficient support material.
It's hard to say these conclusively isolate *all* culprits for the full
slowdown we observe in our codebase, but are hopefully at least a
significant part.

Here's the package:
https://dl.dropboxusercontent.com/u/58525/ghc-slowdown.tar.gz

Best,
Oz



On Tue, Apr 7, 2015 at 3:39 PM, Simon Marlow <marlowsd at gmail.com> wrote:

> Just a comment on this one point:
>
> On 05/04/2015 19:01, Ozgun Ataman wrote:
>
>>   * With O0 and -j=N the overall wall-clock time is 40% higher, but the
>>     CPU time spent is a staggering 7.5X higher (!)
>>
>
> When looking at Haskell programs executing in parallel, it's normal to see
> a high CPU time, because the GC threads spin looking for work.  The extra
> CPU time is just time spent spinning, it doesn't imply that the compiler
> was doing extra work.  What matters is the overall wall-clock time - a
> worse wall-clock time indicates that something has gone wrong.
>
> We should look at compile-time regression independently of performance
> issues with -j.  Parallel compilation is a new feature and mostly likely
> needs a lot of tuning.  Note that cabal's -j feature is different from
> GHC's (and is likely to give much more reliable improvements) because it
> runs multiple compiler instances in parallel.
>
> Cheers,
> Simon
>
>
>    * With -O0, "cabal repl" load times have gone up by a staggering 2.5X
>> (!)
>>       o 7.8.4: 3 min. 35 seconds
>>       o 7.6.3: 1 min. 2 seconds
>>   * Measuring compile times for individual modules, we see that those
>>     that are heavily loaded with lots of types, TH-facilitated type and
>>     typeclass derivations and those that contain large "blobs" of values
>>     directly at the top level now take much longer to compile:
>>       o We have 10 modules that each take over 10 seconds
>>       o We have 3 modules that each take over 35 seconds
>>   * Sidenote observation: In general, parallel builds with -j appear to
>>     cause a very significant overhead under the "system" part of timing:
>>       o Example with 7.6.3, O0: cabal build  140.57s user 13.25s system
>>         100% cpu 2:33.70 total
>>       o Example with 7.8.4, O0: cabal build  507.83s user 655.43s system
>>         549% cpu 3:31.59 total
>>
>>
>> The main hurt here has been the infeasibility of using "cabal repl /
>> ghci"  fast-feedback style development (via emacs, vim, command-line,
>> etc.), since:
>>
>>   * Unlike "cabal build", "cabal repl" re-compiles from scratch with
>>     every invocation ":l App.Foo.Bar", which itself is the necessary
>>     first step when starting to hack on a module (we can then use :r to
>>     somewhat help the situation)
>>   * The slowdown is about 2.5X as stated above: What used to take a
>>     minute now takes 3.5 minutes.
>>   * cabal repl does not seem to benefit from -j at all
>>   * cabal repl 7.8.4 appears to be hurt particularly by the heavier
>> modules
>>   * The heavier modules are often at the top of the compile tree (types,
>>     derivations, etc) and are practically loaded on the critical path
>>     all the time
>>
>> Let me know if I'm missing anything here and any/all feedback is much
>> appreciated!
>>
>> Cheers,
>> Oz
>>
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150414/64a4f750/attachment-0001.html>

From austin at well-typed.com  Tue Apr 14 19:58:04 2015
From: austin at well-typed.com (Austin Seipp)
Date: Tue, 14 Apr 2015 14:58:04 -0500
Subject: Help wanted: working on the GHC webpage
In-Reply-To: <551E9EDA.40301@sigrlami.eu>
References: <CAEs96n303YDnawHbGzretCC24ogxfoo1LmzB4xFyhbDTAidYTQ@mail.gmail.com>
 <551E92A8.7020901@sigrlami.eu> <87y4m9conm.fsf@gmail.com>
 <551E9EDA.40301@sigrlami.eu>
Message-ID: <CAEs96n3juDV+uKVNkm4iD5vtu4A1taSqg229uXUamGQarXL8RA@mail.gmail.com>

Hey Sergey,

Sorry for the delay - thanks for all your changes! A few other people
have stepped up. But we still need more help of course. :)

I'm incorporating your changes into the main Git repository as we
speak, and I greatly appreciate it! I'm also incorporating changes
from others. Please watch the repo and let me know if you have
questions!

PS: As for Trac, I agree that at the minimum there should be some kind
of syndication or something from the homepage to Trac... the Weekly
News *is* user-focused, but the homepage has been severely lacking.
I'd appreciate comments here - make an issue about it on the bug
tracker!

On Fri, Apr 3, 2015 at 9:08 AM, Sergey Bushnyak
<sergey.bushnyak at sigrlami.eu> wrote:
>
>> Why would it be easier? What's difficult about publishing on
>> https://ghc.haskell.org/trac/ghc/blog?
>
> I'm actually don't know how it's published on track. From my standpoint as
> newcomer it's better to see what's happening from one place, with one
> design, have some shared git repo where people contribute in markdown.
>>
>> Moreover, the GHC weekly news are intimately linked to Trac, as they
>> reference Trac-tickets and Git commits, which Trac is able to annotate
>> with meta-data (ticket-type, -status, and -title for Ticket references,
>> as well as part of the Git commit msg for Git-commit refs).
>
>
> Ok, it was just a suggestion. Maybe it's a bad idea, doesn't know about
> annotation.
>
> Anyway, still can help on updating ghc home page.
>



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From asr at eafit.edu.co  Tue Apr 14 20:32:49 2015
From: asr at eafit.edu.co (=?UTF-8?B?QW5kcsOpcyBTaWNhcmQtUmFtw61yZXo=?=)
Date: Tue, 14 Apr 2015 15:32:49 -0500
Subject: Slower Compilation on GHC 7.8.4 (vs. 7.6.3)
In-Reply-To: <CAGn37G3ifA7AttvFD2E7ZqDW_4rJtn=f6xxb7s=FZW6ZwzMtEw@mail.gmail.com>
References: <CAGn37G2cTGy88F-cHjFg9XEbDqaYqQetKR4iPqUnzT9DDXdWDQ@mail.gmail.com>
 <55243283.3050506@gmail.com>
 <CAGn37G3ifA7AttvFD2E7ZqDW_4rJtn=f6xxb7s=FZW6ZwzMtEw@mail.gmail.com>
Message-ID: <CAOUWSGCZC5U0aQ4iSJ5vC7zCCWQuxkPiej=FgO4A=byg=Z1LFw@mail.gmail.com>

On 14 April 2015 at 14:56, Ozgun Ataman <ozataman at gmail.com> wrote:
> 500 random type declarations were a modest 10-25% slower.

I don't think this is a modest percent by only adding type
declarations. Is it an expected behaviour?


-- 
Andr?s

From joehillen at gmail.com  Tue Apr 14 22:48:58 2015
From: joehillen at gmail.com (Joe Hillenbrand)
Date: Tue, 14 Apr 2015 15:48:58 -0700
Subject: GHC Weekly News - 2015/04/14
In-Reply-To: <CANJQ5C6cEBmuwCY_c4hpLzQCq-imY30cG3qW2EvsqeCGtsX16Q@mail.gmail.com>
References: <CAEs96n2paWLhDev1mN2y3BxPKDhYREU8Z3JQD738HRBCmQQT0g@mail.gmail.com>
 <CANJQ5C6cEBmuwCY_c4hpLzQCq-imY30cG3qW2EvsqeCGtsX16Q@mail.gmail.com>
Message-ID: <CANJQ5C4ocKKhGFyvXz38F+zc02GsMXK+Gz4GKLOP4cxvvpVXCw@mail.gmail.com>

Found the thread:
https://mail.haskell.org/pipermail/ghc-devs/2014-October/006599.html

On Tue, Apr 14, 2015 at 12:07 PM, Joe Hillenbrand <joehillen at gmail.com> wrote:
>> == Call for help: DocBook to AsciiDoc ==
>>
>> So, we're asking the public: Is anyone willing to step up and help
> here? For example, it may be possible to get a long ways with just
> `pandoc`, but we need someone to finish it - and in return, we'll help
> along the way!
>
>
> Do you have anymore information on this? Tickets? Current status? This
> is the first I've heard about the proposed conversion, and I follow
> ghc-devs@ pretty closely.
>

From eir at cis.upenn.edu  Wed Apr 15 00:20:47 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Wed, 15 Apr 2015 01:20:47 +0100
Subject: stack traces when debugging GHC
In-Reply-To: <fd60876e21cf4cc88e1b48e883e6ed59@DB4PR30MB030.064d.mgd.msft.net>
References: <A7E7AF02-D58F-40D6-A1B3-63704FD99015@cis.upenn.edu>
 <55298388.7040502@gmail.com>
 <fd60876e21cf4cc88e1b48e883e6ed59@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <2F8C959D-10F9-4C8A-AB3D-9D688CE60A6C@cis.upenn.edu>

Posted as #10303. Comments welcome.

On Apr 13, 2015, at 7:57 AM, Simon Peyton Jones <simonpj at microsoft.com> wrote:

> |  I see you've added a reference buried in Debugging/Compiler.  Why don't
> |  we just make traceStack the default?  Perhaps with a flag to disable
> |  (or enable) the stack trace.
> 
> Sounds desirable to me. It'll only work with profiling, though, of course.
> 
> Would someone like to do this?  At least make a ticket?
> 
> Simon
> 
> |  -----Original Message-----
> |  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Simon
> |  Marlow
> |  Sent: 11 April 2015 21:27
> |  To: Richard Eisenberg; ghc-devs at haskell.org Devs
> |  Subject: Re: stack traces when debugging GHC
> |  
> |  On 09/02/2015 02:51, Richard Eisenberg wrote:
> |  > Hi devs,
> |  >
> |  > I've just made a miraculous discovery and I want to share!
> |  >
> |  > It has happened many times that I create some bizarre error in GHC
> |  and have no clue where it comes from. In the past, I've ended up using
> |  pprTrace to label all calls of the failing function, sometimes
> |  recursively, until I get an idea of what's going on. This is terribly
> |  painful. And then, I noticed that the function Debug.Trace.traceStack
> |  (just in the `base` package, not part of GHC) will print out a stack
> |  trace, when profiling is enabled. So, I tried building a profiled build
> |  of GHC, with -DDEBUG and -fprof-auto (just by editing the "prof"
> |  section of build.mk).
> |  >
> |  > And then, voila, ASSERTs now print stack traces! And, with a small
> |  change in Outputable, I can get pprTrace to print stack traces, too!
> |  Hooray!
> |  
> |  I should have advertised this more widely, thanks for pointing it out.
> |  
> |  > I'd love to put this on the wiki. Any clue where this might be found?
> |  
> |  I see you've added a reference buried in Debugging/Compiler.  Why don't
> |  we just make traceStack the default?  Perhaps with a flag to disable
> |  (or
> |  enable) the stack trace.
> |  
> |  Cheers,
> |  Simon
> |  _______________________________________________
> |  ghc-devs mailing list
> |  ghc-devs at haskell.org
> |  http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> 


From mle+hs at mega-nerd.com  Wed Apr 15 06:04:31 2015
From: mle+hs at mega-nerd.com (Erik de Castro Lopo)
Date: Tue, 14 Apr 2015 23:04:31 -0700
Subject: ghc-7.10 branch regression
Message-ID: <20150414230431.400cca1d18909803fb76c275@mega-nerd.com>


Hi all,

It seems that commit 42448e3757 from git HEAD has been pulled into the
ghc-7.10 branch as commit 07da52ce2d.

This is problematic because that patch puts in a *requirement* for llvm-3.6
(which is good for git HEAD) but the llvm backend code in the ghc-7.10 branch
does not compiler with llvm-3.6. Specifically, on armhf I get:

    /usr/bin/opt-3.6: /tmp/ghc16494_0/ghc16494_2.ll:7:6: error: unexpected type in metadata definition
    !0 = metadata !{metadata !"top", i8* null}

Furthermore, validating the ghc-7.10 branch on amd64-linis results in 16
unexpected failures (i'm currenty in the process of validating this branch
with the problematic commit reverted).

At this point we need to decide whether:

   a) Require llvm-3.6 for 7.10.2 and later.

or

   b) Revert commit 07da52ce2d in the ghc-7.10 branch and continue to use
      llvm-3.5 for the 7.10 series.

For option a) we would need to do the following:

  * Pull in 5d5abdca31 from git HEAD that upgrades the LLVM backend to support
    llvm-3.6 only.
  * Pull in 485dba86 from git HEAD that updates the configure stuff and is
    really the second part of 42448e3757.

For option b) we would need to do the following:

  * Revert 07da52ce2d from ghc-7.10
  * Apply the patch mentioned here:
        https://ghc.haskell.org/trac/ghc/ticket/10234#comment:11

At this point, my personal preference would be a). For me, git HEAD using
llvm-3.6 has been working a lot better on armhf and arm64 than the ghc-7.10
branch. Ticket #10234 has been set to 'merge' status to refect this.

Cheers,
Erik


PS : I would have raised another ticket about this, but I think the problem
     here was actually caused by too many tickets and too many commits being
     involved.
Interesting tidbits in case anyone is interested:

* On armhf, building the ghc-7.10 branch fails because we a generating LLVM IR
  code targeted for llvm-3.5 and trying to compile it with llcm-3.6.

* The ghc-7.10 validates (with 16 unexpected failures) in x86 variants because
  validation uses the NCG to build the compiler and ignores the requirement for
  llvm-3.6, and then bindisttest compiler just uses "llc" and "opt" (in git
  HEAD this difference between the compiler configure script and the binary-dist
  configure script is fixed in 485dba86 and it is fixed in ghc-7.10 by the patch
  in https://ghc.haskell.org/trac/ghc/ticket/10234#comment:11).




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

From simonpj at microsoft.com  Wed Apr 15 08:06:14 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 15 Apr 2015 08:06:14 +0000
Subject: Slower Compilation on GHC 7.8.4 (vs. 7.6.3)
In-Reply-To: <CAGn37G3ifA7AttvFD2E7ZqDW_4rJtn=f6xxb7s=FZW6ZwzMtEw@mail.gmail.com>
References: <CAGn37G2cTGy88F-cHjFg9XEbDqaYqQetKR4iPqUnzT9DDXdWDQ@mail.gmail.com>
 <55243283.3050506@gmail.com>
 <CAGn37G3ifA7AttvFD2E7ZqDW_4rJtn=f6xxb7s=FZW6ZwzMtEw@mail.gmail.com>
Message-ID: <2a4196b73ecc40908433c03186ab6e9e@DB4PR30MB030.064d.mgd.msft.net>

This is all very helpful Oz.  Thanks.

What would be even more helpful would be ticket(s) that focus on individual bad aspects, especially ones that are non-linear.  Eg ?Here are modules with 500, 1000, 2000 declarations, and compile time goes up non-linearly?.

The two big ones seem to be:

?         Type declarations

?         TH-enabled derivations (whatever they are)

The simpler the better.   Eg safecopy probably has fewer dependencies than lens.  And maybe it?s nothing to do with safecopy, but any old derivation will do?

What?s ideal is to be able to turn up the size knob, with a profiled compiler, and see which bits of the compiler are going non-linear.

Thanks!

Simon

From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Ozgun Ataman
Sent: 14 April 2015 20:56
To: Simon Marlow
Cc: michael.xavier at soostone.com; ghc-devs at haskell.org
Subject: Re: Slower Compilation on GHC 7.8.4 (vs. 7.6.3)

Hello all,

Thank you for the comments and apologies that it took a bit of time to get back to you. My colleague Michael and I have taken a stab at a package demonstrating the slowdown. Our hypothesis was that the presence of type declarations, large values/literals, typeclass instantiations and engagement of TH caused at least some of the slowdown we were seeing in our app code. It turns out this was only partially true:

  *   500 random type declarations were a modest 10-25% slower.
  *   Simply instantiating types with a given class did not contribute that much to the slowdown (around 5% on top of type declarations)
  *   There was no notable slowdown on large values/literals (false hypothesis)
  *   TH-enabled derivations were over 100% slower (lens and safecopy used as test subjects)

     *   lens: ~100% slower
     *   safecopy: ~125% slower

  *   The slowdowns appeared to be super-linear in at least some cases. Doubling the declaration count to 1000 increased the % of the slowdown:

     *   Declarations: 30% slower
     *   lens TH slowdown: ~100% slower (stayed the same)
     *   safecopy TH slowdown: ~140% slower

I'd be happy to create a ticket if this is sufficient support material. It's hard to say these conclusively isolate *all* culprits for the full slowdown we observe in our codebase, but are hopefully at least a significant part.

Here's the package: https://dl.dropboxusercontent.com/u/58525/ghc-slowdown.tar.gz

Best,
Oz



On Tue, Apr 7, 2015 at 3:39 PM, Simon Marlow <marlowsd at gmail.com<mailto:marlowsd at gmail.com>> wrote:
Just a comment on this one point:

On 05/04/2015 19:01, Ozgun Ataman wrote:
  * With O0 and -j=N the overall wall-clock time is 40% higher, but the
    CPU time spent is a staggering 7.5X higher (!)

When looking at Haskell programs executing in parallel, it's normal to see a high CPU time, because the GC threads spin looking for work.  The extra CPU time is just time spent spinning, it doesn't imply that the compiler was doing extra work.  What matters is the overall wall-clock time - a worse wall-clock time indicates that something has gone wrong.

We should look at compile-time regression independently of performance issues with -j.  Parallel compilation is a new feature and mostly likely needs a lot of tuning.  Note that cabal's -j feature is different from GHC's (and is likely to give much more reliable improvements) because it runs multiple compiler instances in parallel.

Cheers,
Simon

  * With -O0, "cabal repl" load times have gone up by a staggering 2.5X (!)
      o 7.8.4: 3 min. 35 seconds
      o 7.6.3: 1 min. 2 seconds
  * Measuring compile times for individual modules, we see that those
    that are heavily loaded with lots of types, TH-facilitated type and
    typeclass derivations and those that contain large "blobs" of values
    directly at the top level now take much longer to compile:
      o We have 10 modules that each take over 10 seconds
      o We have 3 modules that each take over 35 seconds
  * Sidenote observation: In general, parallel builds with -j appear to
    cause a very significant overhead under the "system" part of timing:
      o Example with 7.6.3, O0: cabal build  140.57s user 13.25s system
        100% cpu 2:33.70 total
      o Example with 7.8.4, O0: cabal build  507.83s user 655.43s system
        549% cpu 3:31.59 total


The main hurt here has been the infeasibility of using "cabal repl /
ghci"  fast-feedback style development (via emacs, vim, command-line,
etc.), since:

  * Unlike "cabal build", "cabal repl" re-compiles from scratch with
    every invocation ":l App.Foo.Bar", which itself is the necessary
    first step when starting to hack on a module (we can then use :r to
    somewhat help the situation)
  * The slowdown is about 2.5X as stated above: What used to take a
    minute now takes 3.5 minutes.
  * cabal repl does not seem to benefit from -j at all
  * cabal repl 7.8.4 appears to be hurt particularly by the heavier modules
  * The heavier modules are often at the top of the compile tree (types,
    derivations, etc) and are practically loaded on the critical path
    all the time

Let me know if I'm missing anything here and any/all feedback is much
appreciated!

Cheers,
Oz


_______________________________________________
ghc-devs mailing list
ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150415/6263453f/attachment-0001.html>

From mle+hs at mega-nerd.com  Wed Apr 15 10:12:35 2015
From: mle+hs at mega-nerd.com (Erik de Castro Lopo)
Date: Wed, 15 Apr 2015 03:12:35 -0700
Subject: ghc-7.10 branch regression
In-Reply-To: <20150414230431.400cca1d18909803fb76c275@mega-nerd.com>
References: <20150414230431.400cca1d18909803fb76c275@mega-nerd.com>
Message-ID: <20150415031235.cf83910f6c5bc9e6b6f6cf8d@mega-nerd.com>

Erik de Castro Lopo wrote:

> At this point we need to decide whether:
> 
>    a) Require llvm-3.6 for 7.10.2 and later.

I've done some testing on the ghc-7.10 branch (with a couple of patches
cherry picked from master) with llvm-3.6 on amd64-linux. WIth this,
there are 17 unexpected failures during validate:

   deriving/should_fail       T7959 [stderr mismatch] (normal)
   deriving/should_fail       drvfail005 [stderr mismatch] (normal)
   deriving/should_fail       drvfail009 [stderr mismatch] (normal)
   indexed-types/should_fail  SimpleFail14 [stderr mismatch] (normal)
   simplCore/should_compile   spec-inline [stderr mismatch] (optasm)
   typecheck/should_compile   T10195 [exit code non-0] (normal)
   typecheck/should_fail      T2994 [stderr mismatch] (normal)
   typecheck/should_fail      T3540 [stderr mismatch] (normal)
   typecheck/should_fail      T7778 [stderr mismatch] (normal)
   typecheck/should_fail      tcfail036 [stderr mismatch] (normal)
   typecheck/should_fail      tcfail057 [stderr mismatch] (normal)
   typecheck/should_fail      tcfail063 [stderr mismatch] (normal)
   typecheck/should_fail      tcfail134 [stderr mismatch] (normal)
   typecheck/should_fail      tcfail146 [stderr mismatch] (normal)
   typecheck/should_fail      tcfail147 [stderr mismatch] (normal)
   typecheck/should_fail      tcfail151 [stderr mismatch] (normal)
   typecheck/should_fail      tcfail209 [stderr mismatch] (normal)

All bit one oft these all seem to be stderr mismatches rather than
actual problems.

My validate run on armhf is still running.

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

From george.colpitts at gmail.com  Wed Apr 15 12:00:55 2015
From: george.colpitts at gmail.com (George Colpitts)
Date: Wed, 15 Apr 2015 09:00:55 -0300
Subject: ghc-7.10 branch regression
In-Reply-To: <20150415031235.cf83910f6c5bc9e6b6f6cf8d@mega-nerd.com>
References: <20150414230431.400cca1d18909803fb76c275@mega-nerd.com>
 <20150415031235.cf83910f6c5bc9e6b6f6cf8d@mega-nerd.com>
Message-ID: <CAB-d4A7v=fx05tU1DZ95xAmKiyyvRhySBUNmUtU1kmmmxDcYYA@mail.gmail.com>

I believe we need to do  b) Revert commit 07da52ce2d in the ghc-7.10 branch
and continue to use llvm-3.5 for the 7.10 series.

I think the plan is to require llvm-3.6 or a later version for 7.12.1 and
later

Ghc 7.10.1 only supports llvm 3.5 as stated in
https://ghc.haskell.org/trac/ghc/ticket/9929

I filed a doc bug on this yesterday,
https://ghc.haskell.org/trac/ghc/ticket/10302



On Wed, Apr 15, 2015 at 7:12 AM, Erik de Castro Lopo <mle+hs at mega-nerd.com>
wrote:

> Erik de Castro Lopo wrote:
>
> > At this point we need to decide whether:
> >
> >    a) Require llvm-3.6 for 7.10.2 and later.
>
> I've done some testing on the ghc-7.10 branch (with a couple of patches
> cherry picked from master) with llvm-3.6 on amd64-linux. WIth this,
> there are 17 unexpected failures during validate:
>
>    deriving/should_fail       T7959 [stderr mismatch] (normal)
>    deriving/should_fail       drvfail005 [stderr mismatch] (normal)
>    deriving/should_fail       drvfail009 [stderr mismatch] (normal)
>    indexed-types/should_fail  SimpleFail14 [stderr mismatch] (normal)
>    simplCore/should_compile   spec-inline [stderr mismatch] (optasm)
>    typecheck/should_compile   T10195 [exit code non-0] (normal)
>    typecheck/should_fail      T2994 [stderr mismatch] (normal)
>    typecheck/should_fail      T3540 [stderr mismatch] (normal)
>    typecheck/should_fail      T7778 [stderr mismatch] (normal)
>    typecheck/should_fail      tcfail036 [stderr mismatch] (normal)
>    typecheck/should_fail      tcfail057 [stderr mismatch] (normal)
>    typecheck/should_fail      tcfail063 [stderr mismatch] (normal)
>    typecheck/should_fail      tcfail134 [stderr mismatch] (normal)
>    typecheck/should_fail      tcfail146 [stderr mismatch] (normal)
>    typecheck/should_fail      tcfail147 [stderr mismatch] (normal)
>    typecheck/should_fail      tcfail151 [stderr mismatch] (normal)
>    typecheck/should_fail      tcfail209 [stderr mismatch] (normal)
>
> All bit one oft these all seem to be stderr mismatches rather than
> actual problems.
>
> My validate run on armhf is still running.
>
> Erik
> --
> ----------------------------------------------------------------------
> Erik de Castro Lopo
> http://www.mega-nerd.com/
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150415/5404a0a9/attachment.html>

From jan.stolarek at p.lodz.pl  Wed Apr 15 12:20:10 2015
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Wed, 15 Apr 2015 14:20:10 +0200
Subject: Building patches that change format of interface files
Message-ID: <201504151420.10254.jan.stolarek@p.lodz.pl>

GHC Devs,

Once I compile GHC I use the "cd ghc; make 2" trick to re-compile any changes. That however does 
not work if my code changes modify the format of interface files - the resulting compiler is 
unusable. In fact the only way to get a working compiler after interface format change that I am 
aware of is to rebuild everything from scratch. Needless to say, this takes a lot of time. Is 
there a better way? I'd like to test D841 but if this means rebuilding everything then I'll have 
to pass.

Janek

---
Politechnika ??dzka
Lodz University of Technology

Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata.
Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k?
prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie.

This email contains information intended solely for the use of the individual to whom it is addressed.
If you are not the intended recipient or if you have received this message in error,
please notify the sender and delete it from your system.

From ezyang at mit.edu  Wed Apr 15 12:26:31 2015
From: ezyang at mit.edu (Edward Z. Yang)
Date: Wed, 15 Apr 2015 13:26:31 +0100
Subject: Building patches that change format of interface files
In-Reply-To: <201504151420.10254.jan.stolarek@p.lodz.pl>
References: <201504151420.10254.jan.stolarek@p.lodz.pl>
Message-ID: <1429100753-sup-4939@sabre>

Technically, you can skip recompiling the stage1 compiler. But I never
bother: all of the libraries must be rebuilt; you have, after all,
changed the interface file format.

Edward

Excerpts from Jan Stolarek's message of 2015-04-15 13:20:10 +0100:
> GHC Devs,
> 
> Once I compile GHC I use the "cd ghc; make 2" trick to re-compile any changes. That however does 
> not work if my code changes modify the format of interface files - the resulting compiler is 
> unusable. In fact the only way to get a working compiler after interface format change that I am 
> aware of is to rebuild everything from scratch. Needless to say, this takes a lot of time. Is 
> there a better way? I'd like to test D841 but if this means rebuilding everything then I'll have 
> to pass.
> 
> Janek
> 
> ---
> Politechnika ??dzka
> Lodz University of Technology
> 
> Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata.
> Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k?
> prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie.
> 
> This email contains information intended solely for the use of the individual to whom it is addressed.
> If you are not the intended recipient or if you have received this message in error,
> please notify the sender and delete it from your system.

From adam at well-typed.com  Wed Apr 15 12:33:25 2015
From: adam at well-typed.com (Adam Gundry)
Date: Wed, 15 Apr 2015 13:33:25 +0100
Subject: Building patches that change format of interface files
In-Reply-To: <201504151420.10254.jan.stolarek@p.lodz.pl>
References: <201504151420.10254.jan.stolarek@p.lodz.pl>
Message-ID: <552E5A95.9070807@well-typed.com>

[oops, forgot to cc ghc-devs]

Hi Janek,

On 15/04/15 13:20, Jan Stolarek wrote:
> Once I compile GHC I use the "cd ghc; make 2" trick to re-compile any
changes. That however does
> not work if my code changes modify the format of interface files - the
resulting compiler is
> unusable. In fact the only way to get a working compiler after
interface format change that I am
> aware of is to rebuild everything from scratch. Needless to say, this
takes a lot of time. Is
> there a better way?

I hit this problem quite often as well, but unfortunately don't know of
a general solution other than rebuilding everything.


> I'd like to test D841 but if this means rebuilding everything then
I'll have to pass.

In the case of D841, the interface file changes are very minor
(specifically, a new tag is used when an empty closed type family is
compiled, but of course none of them exist yet). Thus you might be able
to get away without a full rebuild. (I think ./configure incorporates
some git revision data into the interface file version number, so
presumably you have to avoid that as well.)

All the best,

Adam

-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From rwbarton at gmail.com  Wed Apr 15 12:55:59 2015
From: rwbarton at gmail.com (Reid Barton)
Date: Wed, 15 Apr 2015 08:55:59 -0400
Subject: ghc-7.10 branch regression
In-Reply-To: <20150414230431.400cca1d18909803fb76c275@mega-nerd.com>
References: <20150414230431.400cca1d18909803fb76c275@mega-nerd.com>
Message-ID: <CADmwj470ndKV4dOFyAz_O5qKQnSgQfwRMG1V98L-TvwZrZ+z=g@mail.gmail.com>

On Wed, Apr 15, 2015 at 2:04 AM, Erik de Castro Lopo <mle+hs at mega-nerd.com>
wrote:

>
> At this point we need to decide whether:
>
>    a) Require llvm-3.6 for 7.10.2 and later.
>

Surely we're not going to do this.


> or
>
>    b) Revert commit 07da52ce2d in the ghc-7.10 branch and continue to use
>       llvm-3.5 for the 7.10 series.
>

Why do we need to revert anything, can't we just make a one-character fix
of 3.6 to 3.5 on the ghc-7.10 branch?

Regards,
Reid Barton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150415/b2bcba78/attachment.html>

From jan.stolarek at p.lodz.pl  Wed Apr 15 15:52:09 2015
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Wed, 15 Apr 2015 17:52:09 +0200
Subject: Building patches that change format of interface files
In-Reply-To: <552E5A95.9070807@well-typed.com>
References: <201504151420.10254.jan.stolarek@p.lodz.pl>
 <552E5A95.9070807@well-typed.com>
Message-ID: <201504151752.09367.jan.stolarek@p.lodz.pl>

> In the case of D841, the interface file changes are very minor
> (specifically, a new tag is used when an empty closed type family is
> compiled, but of course none of them exist yet). Thus you might be able
> to get away without a full rebuild.
Good point. Sadly, your patch conflicts with my work on injective type families so looks like I 
have no choice but to do a full rebuild. I'll post comments about things I wanted to test on 
Phab.

Janek

---
Politechnika ????dzka
Lodz University of Technology

Tre???? tej wiadomo??ci zawiera informacje przeznaczone tylko dla adresata.
Je??eli nie jeste??cie Pa??stwo jej adresatem, b?
d?? otrzymali??cie j?
 przez pomy??k??
prosimy o powiadomienie o tym nadawcy oraz trwa??e jej usuni??cie.

This email contains information intended solely for the use of the individual to whom it is addressed.
If you are not the intended recipient or if you have received this message in error,
please notify the sender and delete it from your system.

From george.colpitts at gmail.com  Wed Apr 15 16:44:50 2015
From: george.colpitts at gmail.com (George Colpitts)
Date: Wed, 15 Apr 2015 13:44:50 -0300
Subject: ghc-7.10 branch regression
In-Reply-To: <CADmwj470ndKV4dOFyAz_O5qKQnSgQfwRMG1V98L-TvwZrZ+z=g@mail.gmail.com>
References: <20150414230431.400cca1d18909803fb76c275@mega-nerd.com>
 <CADmwj470ndKV4dOFyAz_O5qKQnSgQfwRMG1V98L-TvwZrZ+z=g@mail.gmail.com>
Message-ID: <CAB-d4A7O48zzWsNPV6KSpRPrn0NCiYxtdZA+d-_sVsQpp7Ot5A@mail.gmail.com>

yes wrt b) making a one-character fix of 3.6 to 3.5 on the ghc-7.10 branch
sound like the right thing to me.

wrt a) my understanding is that for 7.10.2 we will also use llvm 3.5 as in
7.10.1

For 7.12.1 and forward we will also have one supported llvm version per
release which  right now for 7.12.1 is 3.6 but could become 3.7

The plan for llvm for 7.12.1and later is given in
https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend.


On Wed, Apr 15, 2015 at 9:55 AM, Reid Barton <rwbarton at gmail.com> wrote:

> On Wed, Apr 15, 2015 at 2:04 AM, Erik de Castro Lopo <mle+hs at mega-nerd.com
> > wrote:
>
>>
>> At this point we need to decide whether:
>>
>>    a) Require llvm-3.6 for 7.10.2 and later.
>>
>
> Surely we're not going to do this.
>
>
>> or
>>
>>    b) Revert commit 07da52ce2d in the ghc-7.10 branch and continue to use
>>       llvm-3.5 for the 7.10 series.
>>
>
> Why do we need to revert anything, can't we just make a one-character fix
> of 3.6 to 3.5 on the ghc-7.10 branch?
>
> Regards,
> Reid Barton
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150415/5f0d7188/attachment.html>

From bergey at teallabs.org  Wed Apr 15 19:50:36 2015
From: bergey at teallabs.org (Daniel Bergey)
Date: Wed, 15 Apr 2015 19:50:36 +0000
Subject: DocBook to AsciiDoc
Message-ID: <87lhhtp3w3.fsf@chladni.home>

I just read that GHC wants to convert the manual to asciidoc.  If no one
else has yet volunteered to do this, I hearby volunteer myself.

I haven't contributed to the GHC manual before, nor to GHC.  I guess
that I will need to learn my way around Phabricator?  I expect to be
proof-reading sections that I haven't read before, about GHC features I
don't use.  I don't expect this to be a problem, since the goal is just
to match the current HTML output.  I do have some experience with
DocBook, Asciidoc, and Pandoc, which should be helpful.

Is there anything I should convert that isn't in under the users_guide
folder?[1]

It looks as though the users guide gets frequent commits.[2] Does one
`arc diff` per file, approximately, sound reasonable, to keep merge
conflicts manageable?

Anything else I should know before I begin?  Who to list as reviewers?
A Trac ticket to link all the asciidoc commits together?

Thanks,
Daniel

Footnotes: 
[1]  http://git.haskell.org/ghc.git/tree/HEAD:/docs/users_guide

[2]  http://git.haskell.org/ghc.git/history/HEAD:/docs/users_guide

From mle+hs at mega-nerd.com  Wed Apr 15 19:55:25 2015
From: mle+hs at mega-nerd.com (Erik de Castro Lopo)
Date: Wed, 15 Apr 2015 12:55:25 -0700
Subject: ghc-7.10 branch regression
In-Reply-To: <CADmwj470ndKV4dOFyAz_O5qKQnSgQfwRMG1V98L-TvwZrZ+z=g@mail.gmail.com>
References: <20150414230431.400cca1d18909803fb76c275@mega-nerd.com>
 <CADmwj470ndKV4dOFyAz_O5qKQnSgQfwRMG1V98L-TvwZrZ+z=g@mail.gmail.com>
Message-ID: <20150415125525.51f632f70b61dfe0d8b0f8bc@mega-nerd.com>

Reid Barton wrote:

> Why do we need to revert anything, can't we just make a one-character fix
> of 3.6 to 3.5 on the ghc-7.10 branch?

Even with that one character change the LLVM detection is not complete
or correct. Specifically, building the compiler will enforce the right
llvm version, but the binary-dist configure script just uses "llc" and
"opt".

Furthermore, I am pretty sure that #10292 is causes by llvm-3.5 and that
if we use llvm-3.6 buildng on Arm works. Unfortunately building and
testing on Arm takes a long time and I am still in the process of
verifying this.

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

From simonpj at microsoft.com  Wed Apr 15 20:10:54 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 15 Apr 2015 20:10:54 +0000
Subject: [Haskell] Haskell on Windows instructions - is MinGHC version
 update needed?
In-Reply-To: <80967076.3696551.1429116658064.JavaMail.yahoo@mail.yahoo.com>
References: <80967076.3696551.1429116658064.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <dd4fdde441124c13a518e845aa6bf3f2@DB4PR30MB030.064d.mgd.msft.net>

Fwding to the GHC Windows Task force, who will doubtless know what to do.

Simon

| -----Original Message-----
| From: Haskell [mailto:haskell-bounces at haskell.org] On Behalf Of Howard B.
| Golden
| Sent: 15 April 2015 17:51
| To: haskell at haskell.org
| Subject: [Haskell] Haskell on Windows instructions - is MinGHC version
| update needed?
| 
| Hi,
| 
| Currently, the Haskell website's Windows download page
| (https://www.haskell.org/downloads/windows) offers two alternatives,
| MinGHC and Haskell Platform. The MinGHC alternative has a link to MinGHC-
| 7.8.3 installer. Should this be updated to MinGHC-7.8.4? I ask this
| because Long Term Support Haskell 2.3 is now using GHC 7.8.4. If you want
| to update the link, you only need to change the URL from 7.8.3 to 7.8.4.
| 
| Howard
| _______________________________________________
| Haskell mailing list
| Haskell at haskell.org
| http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

From lonetiger at gmail.com  Wed Apr 15 22:54:53 2015
From: lonetiger at gmail.com (=?utf-8?Q?Tamar_Christina?=)
Date: Wed, 15 Apr 2015 22:54:53 +0000
Subject: =?utf-8?Q?Re:_[Haskell]_Haskell_on_Windows_instructions_-_is_MinGHC_versi?=
 =?utf-8?Q?on_update_needed=3F?=
In-Reply-To: <dd4fdde441124c13a518e845aa6bf3f2@DB4PR30MB030.064d.mgd.msft.net>
References: <80967076.3696551.1429116658064.JavaMail.yahoo@mail.yahoo.com>,
 <dd4fdde441124c13a518e845aa6bf3f2@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <552eece3.654bb40a.0dc8.ffffe662@mx.google.com>

Hi Simon,


I have created a pull request to update the download links to 7.10.1 releases.


https://github.com/haskell-infra/hl/pull/106


Regards,

Tamar






From: Simon Peyton Jones
Sent: ?Wednesday?, ?April? ?15?, ?2015 ?22?:?10
To: Tamar Christina, Roman Kuznetsov, Kyrill Briantsev, Darren Grant, David Macek, Michael Steele, Andrew Klingenberg
Cc: GHC





Fwding to the GHC Windows Task force, who will doubtless know what to do.

Simon

| -----Original Message-----
| From: Haskell [mailto:haskell-bounces at haskell.org] On Behalf Of Howard B.
| Golden
| Sent: 15 April 2015 17:51
| To: haskell at haskell.org
| Subject: [Haskell] Haskell on Windows instructions - is MinGHC version
| update needed?
| 
| Hi,
| 
| Currently, the Haskell website's Windows download page
| (https://www.haskell.org/downloads/windows) offers two alternatives,
| MinGHC and Haskell Platform. The MinGHC alternative has a link to MinGHC-
| 7.8.3 installer. Should this be updated to MinGHC-7.8.4? I ask this
| because Long Term Support Haskell 2.3 is now using GHC 7.8.4. If you want
| to update the link, you only need to change the URL from 7.8.3 to 7.8.4.
| 
| Howard
| _______________________________________________
| Haskell mailing list
| Haskell at haskell.org
| http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
_______________________________________________
ghc-devs mailing list
ghc-devs at haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150415/7c54a2bc/attachment.html>

From howard_b_golden at yahoo.com  Wed Apr 15 23:11:57 2015
From: howard_b_golden at yahoo.com (Howard B. Golden)
Date: Wed, 15 Apr 2015 23:11:57 +0000 (UTC)
Subject: [Haskell] Haskell on Windows instructions - is MinGHC version
 update needed?
In-Reply-To: <552eece3.654bb40a.0dc8.ffffe662@mx.google.com>
References: <552eece3.654bb40a.0dc8.ffffe662@mx.google.com>
Message-ID: <2127549691.3966128.1429139517398.JavaMail.yahoo@mail.yahoo.com>

Hi Windows Task Force,

Rather than pointing to just the latest 7.10.1 release, please consider having 7.10.1 and 7.8.4 links (and others if you wish). Haskell LTS 2.3 is designed for GHC-7.8.4. It seems to me that many Windows users would find that an attractive combination in addition to 7.10.1.

Howard
________________________________
From: Tamar Christina <lonetiger at gmail.com>
To: Simon Peyton Jones <simonpj at microsoft.com>; Tamar Christina <tamar at zhox.com>; Roman Kuznetsov <kuznero at gmail.com>; Kyrill Briantsev <kyrab at mail.ru>; Darren Grant <dedgrant at gmail.com>; David Macek <david.macek.0 at gmail.com>; Michael Steele <mikesteele81 at gmail.com>; Andrew Klingenberg <asklingenberg at gmail.com> 
Cc: GHC <ghc-devs at haskell.org> 
Sent: Wednesday, April 15, 2015 3:54 PM
Subject: Re: [Haskell] Haskell on Windows instructions - is MinGHC version update needed?



Hi Simon,

I have created a pull request to update the download links to 7.10.1 releases.

https://github.com/haskell-infra/hl/pull/106

Regards,
Tamar


From: Simon Peyton Jones
Sent: ?Wednesday?, ?April? ?15?, ?2015 ?22?:?10
To: Tamar Christina, Roman Kuznetsov, Kyrill Briantsev, Darren Grant, David Macek, Michael Steele, Andrew Klingenberg
Cc: GHC



Fwding to the GHC Windows Task force, who will doubtless know what to do.

Simon

| -----Original Message-----
| From: Haskell [mailto:haskell-bounces at haskell.org] On Behalf Of Howard B.
| Golden
| Sent: 15 April 2015 17:51
| To: haskell at haskell.org
| Subject: [Haskell] Haskell on Windows instructions - is MinGHC version
| update needed?
| 
| Hi,
| 
| Currently, the Haskell website's Windows download page
| (https://www.haskell.org/downloads/windows) offers two alternatives,
| MinGHC and Haskell Platform. The MinGHC alternative has a link to MinGHC-
| 7.8.3 installer. Should this be updated to MinGHC-7.8.4? I ask this
| because Long Term Support Haskell 2.3 is now using GHC 7.8.4. If you want
| to update the link, you only need to change the URL from 7.8.3 to 7.8.4.
| 
| Howard
| _______________________________________________
| Haskell mailing list
| Haskell at haskell.org
| http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
_______________________________________________
ghc-devs mailing list
ghc-devs at haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
ghc-devs at haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From lonetiger at gmail.com  Wed Apr 15 23:43:10 2015
From: lonetiger at gmail.com (=?utf-8?Q?Tamar_Christina?=)
Date: Wed, 15 Apr 2015 23:43:10 +0000
Subject: =?utf-8?Q?Re:_[Haskell]_Haskell_on_Windows_instructions_-_is_MinGHC_versi?=
 =?utf-8?Q?on_update_needed=3F?=
In-Reply-To: <2127549691.3966128.1429139517398.JavaMail.yahoo@mail.yahoo.com>
References: <552eece3.654bb40a.0dc8.ffffe662@mx.google.com>,
 <2127549691.3966128.1429139517398.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <552ef814.2508b40a.3737.2746@mx.google.com>

Hi Howard,


Ah, I was under the impression that there would be a download link from the LTS section on the download page.


Since there isn?t one I have updated the pull request with a section for Haskell LTS which provides links to 7.8.4.


It will look like https://github.com/Mistuke/hl/blob/update-windows-download-pages/static/markdown/windows-install.md


Regards,

Tamar





From: Howard B. Golden
Sent: ?Thursday?, ?April? ?16?, ?2015 ?01?:?11
To: Tamar Christina, Simon Peyton Jones, Tamar Christina, Roman Kuznetsov, kyra, Darren Grant, David Macek, Michael Steele, Andrew Klingenberg
Cc: GHC





Hi Windows Task Force,

Rather than pointing to just the latest 7.10.1 release, please consider having 7.10.1 and 7.8.4 links (and others if you wish). Haskell LTS 2.3 is designed for GHC-7.8.4. It seems to me that many Windows users would find that an attractive combination in addition to 7.10.1.

Howard
________________________________
From: Tamar Christina <lonetiger at gmail.com>
To: Simon Peyton Jones <simonpj at microsoft.com>; Tamar Christina <tamar at zhox.com>; Roman Kuznetsov <kuznero at gmail.com>; Kyrill Briantsev <kyrab at mail.ru>; Darren Grant <dedgrant at gmail.com>; David Macek <david.macek.0 at gmail.com>; Michael Steele <mikesteele81 at gmail.com>; Andrew Klingenberg <asklingenberg at gmail.com> 
Cc: GHC <ghc-devs at haskell.org> 
Sent: Wednesday, April 15, 2015 3:54 PM
Subject: Re: [Haskell] Haskell on Windows instructions - is MinGHC version update needed?



Hi Simon,

I have created a pull request to update the download links to 7.10.1 releases.

https://github.com/haskell-infra/hl/pull/106

Regards,
Tamar


From: Simon Peyton Jones
Sent: ?Wednesday?, ?April? ?15?, ?2015 ?22?:?10
To: Tamar Christina, Roman Kuznetsov, Kyrill Briantsev, Darren Grant, David Macek, Michael Steele, Andrew Klingenberg
Cc: GHC



Fwding to the GHC Windows Task force, who will doubtless know what to do.

Simon

| -----Original Message-----
| From: Haskell [mailto:haskell-bounces at haskell.org] On Behalf Of Howard B.
| Golden
| Sent: 15 April 2015 17:51
| To: haskell at haskell.org
| Subject: [Haskell] Haskell on Windows instructions - is MinGHC version
| update needed?
| 
| Hi,
| 
| Currently, the Haskell website's Windows download page
| (https://www.haskell.org/downloads/windows) offers two alternatives,
| MinGHC and Haskell Platform. The MinGHC alternative has a link to MinGHC-
| 7.8.3 installer. Should this be updated to MinGHC-7.8.4? I ask this
| because Long Term Support Haskell 2.3 is now using GHC 7.8.4. If you want
| to update the link, you only need to change the URL from 7.8.3 to 7.8.4.
| 
| Howard
| _______________________________________________
| Haskell mailing list
| Haskell at haskell.org
| http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
_______________________________________________
ghc-devs mailing list
ghc-devs at haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
ghc-devs at haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150415/245ec6ce/attachment-0001.html>

From ben at smart-cactus.org  Thu Apr 16 01:10:24 2015
From: ben at smart-cactus.org (Ben Gamari)
Date: Wed, 15 Apr 2015 21:10:24 -0400
Subject: ghc-7.10 branch regression
In-Reply-To: <20150415125525.51f632f70b61dfe0d8b0f8bc@mega-nerd.com>
References: <20150414230431.400cca1d18909803fb76c275@mega-nerd.com>
 <CADmwj470ndKV4dOFyAz_O5qKQnSgQfwRMG1V98L-TvwZrZ+z=g@mail.gmail.com>
 <20150415125525.51f632f70b61dfe0d8b0f8bc@mega-nerd.com>
Message-ID: <87pp74dgjj.fsf@gmail.com>

Erik de Castro Lopo <mle+hs at mega-nerd.com> writes:

> Reid Barton wrote:
>
>> Why do we need to revert anything, can't we just make a one-character fix
>> of 3.6 to 3.5 on the ghc-7.10 branch?
>
> Even with that one character change the LLVM detection is not complete
> or correct. Specifically, building the compiler will enforce the right
> llvm version, but the binary-dist configure script just uses "llc" and
> "opt".
>
> Furthermore, I am pretty sure that #10292 is causes by llvm-3.5 and that
> if we use llvm-3.6 buildng on Arm works. Unfortunately building and
> testing on Arm takes a long time and I am still in the process of
> verifying this.
>
While I would love to see LLVM 3.6 rolled out soon as a GHC target (it
is substantially more stable on ARM in my experience) I agree that doing
this for 7.10.2 would be a bit of a large change for a minor release.
If nothing else it would be surprising for users to find that their
previously working LLVM/GHC combination needed to be upgraded upon
moving to 7.10.2.

In my experience LLVM 3.5 works reasonably well on ARM; it seems like
this should be sufficient to carry us through to 7.12.

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/ghc-devs/attachments/20150415/62f106ce/attachment.sig>

From austin at well-typed.com  Thu Apr 16 04:12:48 2015
From: austin at well-typed.com (Austin Seipp)
Date: Wed, 15 Apr 2015 23:12:48 -0500
Subject: DocBook to AsciiDoc
In-Reply-To: <87lhhtp3w3.fsf@chladni.home>
References: <87lhhtp3w3.fsf@chladni.home>
Message-ID: <CAEs96n3zyj9FVKnx018iLrkVjkY=gwUcskum6Bd==o3hHNkHiA@mail.gmail.com>

Hey Daniel,

Thanks! Quick notes:

  1) Yes, please file a ticket about this and refer to it in
Phabricator when you make revisions. For this issue, I'd suggest just
having one ticket, and every single commit references that one ticket.
Adding a bunch of tickets just makes it all harder.

  2) You can just add 'austin' and 'hvr' as reviewers.

  3) You'll need to do some prodding with the build system: we need
'asciidoc' to be picked up by ./configure, etc. If you need help with
this, just holler.

I like the idea of one file at a time. If we can get by with that, I
think we should.

Thanks for helping!

On Wed, Apr 15, 2015 at 2:50 PM, Daniel Bergey <bergey at teallabs.org> wrote:
> I just read that GHC wants to convert the manual to asciidoc.  If no one
> else has yet volunteered to do this, I hearby volunteer myself.
>
> I haven't contributed to the GHC manual before, nor to GHC.  I guess
> that I will need to learn my way around Phabricator?  I expect to be
> proof-reading sections that I haven't read before, about GHC features I
> don't use.  I don't expect this to be a problem, since the goal is just
> to match the current HTML output.  I do have some experience with
> DocBook, Asciidoc, and Pandoc, which should be helpful.
>
> Is there anything I should convert that isn't in under the users_guide
> folder?[1]
>
> It looks as though the users guide gets frequent commits.[2] Does one
> `arc diff` per file, approximately, sound reasonable, to keep merge
> conflicts manageable?
>
> Anything else I should know before I begin?  Who to list as reviewers?
> A Trac ticket to link all the asciidoc commits together?
>
> Thanks,
> Daniel
>
> Footnotes:
> [1]  http://git.haskell.org/ghc.git/tree/HEAD:/docs/users_guide
>
> [2]  http://git.haskell.org/ghc.git/history/HEAD:/docs/users_guide
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From michael at snoyman.com  Thu Apr 16 07:20:32 2015
From: michael at snoyman.com (Michael Snoyman)
Date: Thu, 16 Apr 2015 07:20:32 +0000
Subject: [Haskell] Haskell on Windows instructions - is MinGHC version
 update needed?
In-Reply-To: <552ef814.2508b40a.3737.2746@mx.google.com>
References: <552eece3.654bb40a.0dc8.ffffe662@mx.google.com>
 <2127549691.3966128.1429139517398.JavaMail.yahoo@mail.yahoo.com>
 <552ef814.2508b40a.3737.2746@mx.google.com>
Message-ID: <CAKA2Jg+4hqO6ZB8EabnrT5vmYcQnFmt2VupPTv1mkJ=LeRUO=g@mail.gmail.com>

Just weighing in from the LTS side (and I guess MinGHC as well): having a
link to 7.8.4 is definitely the right thing to do. LTS 2 will not compile
with GHC 7.10 (see: https://github.com/fpco/stackage/issues/378 for more
information).

On Thu, Apr 16, 2015 at 2:45 AM Tamar Christina <lonetiger at gmail.com> wrote:

>  Hi Howard,
>
> Ah, I was under the impression that there would be a download link from
> the LTS section on the download page.
>
> Since there isn?t one I have updated the pull request with a section for
> Haskell LTS which provides links to 7.8.4.
>
> It will look like
> https://github.com/Mistuke/hl/blob/update-windows-download-pages/static/markdown/windows-install.md
>
> Regards,
> Tamar
>
> *From:* Howard B. Golden <howard_b_golden at yahoo.com>
> *Sent:* ?Thursday?, ?April? ?16?, ?2015 ?01?:?11
> *To:* Tamar Christina <lonetiger at gmail.com>, Simon Peyton Jones
> <simonpj at microsoft.com>, Tamar Christina <tamar at zhox.com>, Roman Kuznetsov
> <kuznero at gmail.com>, kyra <kyrab at mail.ru>, Darren Grant
> <dedgrant at gmail.com>, David Macek <david.macek.0 at gmail.com>, Michael
> Steele <mikesteele81 at gmail.com>, Andrew Klingenberg
> <asklingenberg at gmail.com>
> *Cc:* GHC <ghc-devs at haskell.org>
>
> Hi Windows Task Force,
>
> Rather than pointing to just the latest 7.10.1 release, please consider
> having 7.10.1 and 7.8.4 links (and others if you wish). Haskell LTS 2.3 is
> designed for GHC-7.8.4. It seems to me that many Windows users would find
> that an attractive combination in addition to 7.10.1.
>
> Howard
> ________________________________
> From: Tamar Christina <lonetiger at gmail.com>
> To: Simon Peyton Jones <simonpj at microsoft.com>; Tamar Christina <
> tamar at zhox.com>; Roman Kuznetsov <kuznero at gmail.com>; Kyrill Briantsev <
> kyrab at mail.ru>; Darren Grant <dedgrant at gmail.com>; David Macek <
> david.macek.0 at gmail.com>; Michael Steele <mikesteele81 at gmail.com>; Andrew
> Klingenberg <asklingenberg at gmail.com>
> Cc: GHC <ghc-devs at haskell.org>
> Sent: Wednesday, April 15, 2015 3:54 PM
> Subject: Re: [Haskell] Haskell on Windows instructions - is MinGHC version
> update needed?
>
>
>
>
> Hi Simon,
>
> I have created a pull request to update the download links to 7.10.1
> releases.
>
> https://github.com/haskell-infra/hl/pull/106
>
> Regards,
> Tamar
>
>
> From: Simon Peyton Jones
> Sent: ?Wednesday?, ?April? ?15?, ?2015 ?22?:?10
> To: Tamar Christina, Roman Kuznetsov, Kyrill Briantsev, Darren Grant,
> David Macek, Michael Steele, Andrew Klingenberg
> Cc: GHC
>
>
>
> Fwding to the GHC Windows Task force, who will doubtless know what to do.
>
> Simon
>
> | -----Original Message-----
> | From: Haskell [mailto:haskell-bounces at haskell.org] On Behalf Of Howard
> B.
> | Golden
> | Sent: 15 April 2015 17:51
> | To: haskell at haskell.org
> | Subject: [Haskell] Haskell on Windows instructions - is MinGHC version
> | update needed?
> |
> | Hi,
> |
> | Currently, the Haskell website's Windows download page
> | (https://www.haskell.org/downloads/windows) offers two alternatives,
> | MinGHC and Haskell Platform. The MinGHC alternative has a link to MinGHC-
> | 7.8.3 installer. Should this be updated to MinGHC-7.8.4? I ask this
> | because Long Term Support Haskell 2.3 is now using GHC 7.8.4. If you want
> | to update the link, you only need to change the URL from 7.8.3 to 7.8.4.
> |
> | Howard
> | _______________________________________________
> | Haskell mailing list
> | Haskell at haskell.org
> | http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150416/20558f6d/attachment.html>

From eir at cis.upenn.edu  Thu Apr 16 14:19:56 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Thu, 16 Apr 2015 10:19:56 -0400
Subject: Trac is soul-extinguishingly slow
Message-ID: <639DE387-A909-44B8-80DE-9DA9620E250B@cis.upenn.edu>

Hi devs,

Trac isn't working again. In an entirely unscientific study, 4 out of the last 5 sessions where I tried to access Trac, I was unable to.

If ghc.haskell.org is getting slammed, is it possible to disconnect Trac from that name and instead just publish some IP address until we have things working better? (Apologies if that sentence doesn't make any sense at all. I've dealt very little with these sorts of issues.)

Thanks,
Richard

From eir at cis.upenn.edu  Thu Apr 16 14:42:45 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Thu, 16 Apr 2015 10:42:45 -0400
Subject: Trac is soul-extinguishingly slow
In-Reply-To: <639DE387-A909-44B8-80DE-9DA9620E250B@cis.upenn.edu>
References: <639DE387-A909-44B8-80DE-9DA9620E250B@cis.upenn.edu>
Message-ID: <F578D7A5-89FB-474E-BE31-7A5F571E87ED@cis.upenn.edu>

Trac is bac.

But is there anything we can do to improve reliability?

Thanks!
Richard

On Apr 16, 2015, at 10:19 AM, Richard Eisenberg <eir at cis.upenn.edu> wrote:

> Hi devs,
> 
> Trac isn't working again. In an entirely unscientific study, 4 out of the last 5 sessions where I tried to access Trac, I was unable to.
> 
> If ghc.haskell.org is getting slammed, is it possible to disconnect Trac from that name and instead just publish some IP address until we have things working better? (Apologies if that sentence doesn't make any sense at all. I've dealt very little with these sorts of issues.)
> 
> Thanks,
> Richard
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


From k-bx at k-bx.com  Thu Apr 16 16:06:40 2015
From: k-bx at k-bx.com (Kostiantyn Rybnikov)
Date: Thu, 16 Apr 2015 19:06:40 +0300
Subject: Trac is soul-extinguishingly slow
In-Reply-To: <F578D7A5-89FB-474E-BE31-7A5F571E87ED@cis.upenn.edu>
References: <639DE387-A909-44B8-80DE-9DA9620E250B@cis.upenn.edu>
 <F578D7A5-89FB-474E-BE31-7A5F571E87ED@cis.upenn.edu>
Message-ID: <CAAbahfTdOgy4b8NM=Zgk1FLFyfACm1MuwqLTc2fKW7VBf25MOQ@mail.gmail.com>

Hi.

I will soon (today or early tomorrow) get back to Herbert with two things:

- profiling instructions
- possible solution

Also, he mentioned today in irc that he's going to add a tmp fix by
restarting apache periodically, since problem starts after an hour of its
work (not sure if I was supposed to talk about this :)).
16 ????. 2015 17:42 "Richard Eisenberg" <eir at cis.upenn.edu> ????:

> Trac is bac.
>
> But is there anything we can do to improve reliability?
>
> Thanks!
> Richard
>
> On Apr 16, 2015, at 10:19 AM, Richard Eisenberg <eir at cis.upenn.edu> wrote:
>
> > Hi devs,
> >
> > Trac isn't working again. In an entirely unscientific study, 4 out of
> the last 5 sessions where I tried to access Trac, I was unable to.
> >
> > If ghc.haskell.org is getting slammed, is it possible to disconnect
> Trac from that name and instead just publish some IP address until we have
> things working better? (Apologies if that sentence doesn't make any sense
> at all. I've dealt very little with these sorts of issues.)
> >
> > Thanks,
> > Richard
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150416/52033a15/attachment.html>

From johnw at newartisans.com  Fri Apr 17 17:52:01 2015
From: johnw at newartisans.com (John Wiegley)
Date: Fri, 17 Apr 2015 10:52:01 -0700
Subject: Trac is soul-extinguishingly slow
In-Reply-To: <639DE387-A909-44B8-80DE-9DA9620E250B@cis.upenn.edu> (Richard
 Eisenberg's message of "Thu, 16 Apr 2015 10:19:56 -0400")
References: <639DE387-A909-44B8-80DE-9DA9620E250B@cis.upenn.edu>
Message-ID: <m27ftatzge.fsf@newartisans.com>

>>>>> Richard Eisenberg <eir at cis.upenn.edu> writes:

> If ghc.haskell.org is getting slammed, is it possible to disconnect Trac
> from that name and instead just publish some IP address until we have things
> working better? (Apologies if that sentence doesn't make any sense at all.
> I've dealt very little with these sorts of issues.)

I'm wondering if, in the interim, we couldn't do two things:

 1. Make the public facing side of Trac read-only, by generating a static copy
    of the site nightly and exposing that via nginx. Bug data would be one day
    old at most, but it could still be searched, browsed, etc. Just not
    interacted with by non-GHC developers.

 2. Give the GHC developers an SSH login to the machine running Trac, so that,
    by way of a port forward and an edit to /etc/hosts, they could have
    secure, direct access to the bug tracker.

I realize this is sub-optimal in many ways, but it's relatively easy to setup
and would cure all current problems until a better solution is found.

John

From metaniklas at gmail.com  Fri Apr 17 18:07:06 2015
From: metaniklas at gmail.com (Niklas Larsson)
Date: Fri, 17 Apr 2015 20:07:06 +0200
Subject: Trac is soul-extinguishingly slow
In-Reply-To: <m27ftatzge.fsf@newartisans.com>
References: <639DE387-A909-44B8-80DE-9DA9620E250B@cis.upenn.edu>
 <m27ftatzge.fsf@newartisans.com>
Message-ID: <55314bcc.6acf980a.2560.ffffe844@mx.google.com>

How would non-developers file or comment on bugs in that scenario?

BR,
Niklas 

----- Ursprungligt meddelande -----
Fr?n: "John Wiegley" <johnw at newartisans.com>
Skickat: ?2015-?04-?17 19:52
Till: "Richard Eisenberg" <eir at cis.upenn.edu>
Kopia: "ghc-devs at haskell.org Devs" <ghc-devs at haskell.org>
?mne: Re: Trac is soul-extinguishingly slow

>>>>> Richard Eisenberg <eir at cis.upenn.edu> writes:

> If ghc.haskell.org is getting slammed, is it possible to disconnect Trac
> from that name and instead just publish some IP address until we have things
> working better? (Apologies if that sentence doesn't make any sense at all.
> I've dealt very little with these sorts of issues.)

I'm wondering if, in the interim, we couldn't do two things:

 1. Make the public facing side of Trac read-only, by generating a static copy
    of the site nightly and exposing that via nginx. Bug data would be one day
    old at most, but it could still be searched, browsed, etc. Just not
    interacted with by non-GHC developers.

 2. Give the GHC developers an SSH login to the machine running Trac, so that,
    by way of a port forward and an edit to /etc/hosts, they could have
    secure, direct access to the bug tracker.

I realize this is sub-optimal in many ways, but it's relatively easy to setup
and would cure all current problems until a better solution is found.

John
_______________________________________________
ghc-devs mailing list
ghc-devs at haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150417/3cdec449/attachment.html>

From johnw at newartisans.com  Sat Apr 18 18:12:29 2015
From: johnw at newartisans.com (John Wiegley)
Date: Sat, 18 Apr 2015 11:12:29 -0700
Subject: Trac is soul-extinguishingly slow
In-Reply-To: <55314bcc.6acf980a.2560.ffffe844@mx.google.com> (Niklas Larsson's
 message of "Fri, 17 Apr 2015 20:07:06 +0200")
References: <639DE387-A909-44B8-80DE-9DA9620E250B@cis.upenn.edu>
 <m27ftatzge.fsf@newartisans.com>
 <55314bcc.6acf980a.2560.ffffe844@mx.google.com>
Message-ID: <m24modb90y.fsf@newartisans.com>

>>>>> Niklas Larsson <metaniklas at gmail.com> writes:

> How would non-developers file or comment on bugs in that scenario?

They wouldn't, that being our incentive to get it fixed rather than allow this
band-aid to remain.

John

From mail at joachim-breitner.de  Sun Apr 19 07:44:18 2015
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 19 Apr 2015 09:44:18 +0200
Subject: Branchless implementation for literal case =?UTF-8?Q?=E2=80=93?= is
 it worth it?
Message-ID: <1429429458.1607.10.camel@joachim-breitner.de>

Dear devs,

in  https://ghc.haskell.org/trac/ghc/ticket/10124 bgamari suggested that
code like
        
        f :: Int -> Bool
        f a = case a of
                1  -> True
                5  -> True
                8  -> True
                9  -> True
                11 -> True
                19 -> True
                _  -> False
        {-# NOINLINE f #-}

should not compile to a series of conditional jumps, but rather a
branchless code akin to

        let !p = a ==# 1 `orI#` a ==# 5 `orI#` a ==# 8 `orI#` a ==# 9
                         `orI#` a ==# 11 `orI#` a ==# 19
        case p of 
          1 -> do_something
          0 -> do_something_else

Subsequently, I refactored the way we produce Cmm code from STG, opening
the possibility to implement this optimization at that stage?.

But when I then added this implementation, I could not measure any
runtime improvement, see
https://ghc.haskell.org/trac/ghc/ticket/10124#comment:15

So my question to the general audience: Is such branchless code really
better than the current, branching code? Can someone provide us with an
example that shows that it is better? Do I need to produce different
branchless assembly?

If it is not better, I can again refactor the switch generation and
simplify it a bit again.

Hmm, only now I see that rwbarton has replied there. Not sure why I
missed that. Anyways, more voices are welcome :-)

Greetings,
Joachim

? This should not preclude an implementation on the Core level, which
SPJ preferred. But I improved other aspects of the code generation as
well, so this is worthwhile on its own.

-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150419/5073b96b/attachment.sig>

From johan.tibell at gmail.com  Sun Apr 19 12:56:26 2015
From: johan.tibell at gmail.com (Johan Tibell)
Date: Sun, 19 Apr 2015 14:56:26 +0200
Subject: =?UTF-8?Q?Re=3A_Branchless_implementation_for_literal_case_=E2=80=93_i?=
 =?UTF-8?Q?s_it_worth_it=3F?=
In-Reply-To: <1429429458.1607.10.camel@joachim-breitner.de>
References: <1429429458.1607.10.camel@joachim-breitner.de>
Message-ID: <CAK-tuPa1=9EoNojN_Bjy9uJMDEjM5Azj0-zrfbo4S+GqdjVvfQ@mail.gmail.com>

On Apr 19, 2015 09:44, "Joachim Breitner" <mail at joachim-breitner.de> wrote:

> Dear devs,
>
> in  https://ghc.haskell.org/trac/ghc/ticket/10124 bgamari suggested that
> code like
>
>         f :: Int -> Bool
>         f a = case a of
>                 1  -> True
>                 5  -> True
>                 8  -> True
>                 9  -> True
>                 11 -> True
>                 19 -> True
>                 _  -> False
>         {-# NOINLINE f #-}
>
> should not compile to a series of conditional jumps, but rather a
> branchless code akin to
>
>         let !p = a ==# 1 `orI#` a ==# 5 `orI#` a ==# 8 `orI#` a ==# 9
>                          `orI#` a ==# 11 `orI#` a ==# 19
>         case p of
>           1 -> do_something
>           0 -> do_something_else
>
> Subsequently, I refactored the way we produce Cmm code from STG, opening
> the possibility to implement this optimization at that stage?.
>
> But when I then added this implementation, I could not measure any
> runtime improvement, see
> https://ghc.haskell.org/trac/ghc/ticket/10124#comment:15
>
> So my question to the general audience: Is such branchless code really
> better than the current, branching code? Can someone provide us with an
> example that shows that it is better? Do I need to produce different
> branchless assembly?
>
> If it is not better, I can again refactor the switch generation and
> simplify it a bit again.
>
> Hmm, only now I see that rwbarton has replied there. Not sure why I
> missed that. Anyways, more voices are welcome :-)
>
> Greetings,
> Joachim
>
> ? This should not preclude an implementation on the Core level, which
> SPJ preferred. But I improved other aspects of the code generation as
> well, so this is worthwhile on its own.
>
> --
> Joachim ?nomeata? Breitner
>   mail at joachim-breitner.de ? http://www.joachim-breitner.de/
>   Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
>   Debian Developer: nomeata at debian.org
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150419/9b0943ac/attachment.html>

From ggreif at gmail.com  Sun Apr 19 14:21:01 2015
From: ggreif at gmail.com (Gabor Greif)
Date: Sun, 19 Apr 2015 16:21:01 +0200
Subject: =?UTF-8?Q?Re=3A_Branchless_implementation_for_literal_case_=E2=80=93_i?=
 =?UTF-8?Q?s_it_worth_it=3F?=
In-Reply-To: <1429429458.1607.10.camel@joachim-breitner.de>
References: <1429429458.1607.10.camel@joachim-breitner.de>
Message-ID: <CAK-hX0k18k1KSvizgQ1ur=44dco32p9fOxH=qprQ9aXAFBWM4g@mail.gmail.com>

Em domingo, 19 de abril de 2015, Joachim Breitner <mail at joachim-breitner.de>
escreveu:

> Dear devs,
>
> in  https://ghc.haskell.org/trac/ghc/ticket/10124 bgamari suggested that
> code like
>
>         f :: Int -> Bool
>         f a = case a of
>                 1  -> True
>                 5  -> True
>                 8  -> True
>                 9  -> True
>                 11 -> True
>                 19 -> True
>                 _  -> False
>         {-# NOINLINE f #-}
>
> should not compile to a series of conditional jumps, but rather a
> branchless code akin to
>
>         let !p = a ==# 1 `orI#` a ==# 5 `orI#` a ==# 8 `orI#` a ==# 9
>                          `orI#` a ==# 11 `orI#` a ==# 19
>         case p of
>           1 -> do_something
>           0 -> do_something_else


I'd suggest to compile this particular case as a bittest in a 32-bit word.

    Gabor


>
> Subsequently, I refactored the way we produce Cmm code from STG, opening
> the possibility to implement this optimization at that stage?.
>
> But when I then added this implementation, I could not measure any
> runtime improvement, see
> https://ghc.haskell.org/trac/ghc/ticket/10124#comment:15
>
> So my question to the general audience: Is such branchless code really
> better than the current, branching code? Can someone provide us with an
> example that shows that it is better? Do I need to produce different
> branchless assembly?
>
> If it is not better, I can again refactor the switch generation and
> simplify it a bit again.
>
> Hmm, only now I see that rwbarton has replied there. Not sure why I
> missed that. Anyways, more voices are welcome :-)
>
> Greetings,
> Joachim
>
> ? This should not preclude an implementation on the Core level, which
> SPJ preferred. But I improved other aspects of the code generation as
> well, so this is worthwhile on its own.
>
> --
> Joachim ?nomeata? Breitner
>   mail at joachim-breitner.de <javascript:;> ?
> http://www.joachim-breitner.de/
>   Jabber: nomeata at joachim-breitner.de <javascript:;>  ? GPG-Key:
> 0xF0FBF51F
>   Debian Developer: nomeata at debian.org <javascript:;>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150419/020ac442/attachment.html>

From ben at smart-cactus.org  Sun Apr 19 14:41:47 2015
From: ben at smart-cactus.org (Ben Gamari)
Date: Sun, 19 Apr 2015 10:41:47 -0400
Subject: Branchless implementation for literal case
 =?utf-8?Q?=E2=80=93?= is it worth it?
In-Reply-To: <1429429458.1607.10.camel@joachim-breitner.de>
References: <1429429458.1607.10.camel@joachim-breitner.de>
Message-ID: <87pp70b2ok.fsf@gmail.com>

Joachim Breitner <mail at joachim-breitner.de> writes:

> Dear devs,
>
> in  https://ghc.haskell.org/trac/ghc/ticket/10124 bgamari suggested that
> code like
>         
>         f :: Int -> Bool
>         f a = case a of
>                 1  -> True
>                 5  -> True
>                 8  -> True
>                 9  -> True
>                 11 -> True
>                 19 -> True
>                 _  -> False
>         {-# NOINLINE f #-}
>
> should not compile to a series of conditional jumps, but rather a
> branchless code akin to
>
>         let !p = a ==# 1 `orI#` a ==# 5 `orI#` a ==# 8 `orI#` a ==# 9
>                          `orI#` a ==# 11 `orI#` a ==# 19
>         case p of 
>           1 -> do_something
>           0 -> do_something_else
>
Hi Joachim,

Thanks for trying this and I'm sorry to hear that the optimization
hasn't yielded the improvement I would have expected. I've been a bit
silent on the issue as I've been working on finishing up my
PhD. Hopefully in a couple of months after I'm settled in Germany I'll
have time to delve into this more deeply.

> Subsequently, I refactored the way we produce Cmm code from STG, opening
> the possibility to implement this optimization at that stage?.
>
> But when I then added this implementation, I could not measure any
> runtime improvement, see
> https://ghc.haskell.org/trac/ghc/ticket/10124#comment:15
>
> So my question to the general audience: Is such branchless code really
> better than the current, branching code? Can someone provide us with an
> example that shows that it is better? Do I need to produce different
> branchless assembly?
>
Have you had a look at the Intel Optimization manual? I'll admit that I
haven't looked myself but I'd imagine they'd probably have a few things
to say about this.

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/ghc-devs/attachments/20150419/19eea45b/attachment.sig>

From carter.schonwald at gmail.com  Mon Apr 20 01:31:33 2015
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sun, 19 Apr 2015 21:31:33 -0400
Subject: =?UTF-8?Q?Re=3A_Branchless_implementation_for_literal_case_=E2=80=93_i?=
 =?UTF-8?Q?s_it_worth_it=3F?=
In-Reply-To: <87pp70b2ok.fsf@gmail.com>
References: <1429429458.1607.10.camel@joachim-breitner.de>
 <87pp70b2ok.fsf@gmail.com>
Message-ID: <CAHYVw0yAdO8-uaygjkm_vPtEzqbO=cmtL-=bHn3ouA2rZ8MArQ@mail.gmail.com>

the optimization manual ben mentions is
http://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-optimization-manual.html

it does a very good job laying out the scope of both *generality* and
*impact* for a huge range of systemsy tricks.

there are certain conditions when that transformation can be a win, but
they generally correspond with *inner loop* scenarios where bad branch
prediction heavily impacts performance. One class of algorithms that might
provide some grist for the optimization mill would be those in the hacker's
delight book http://www.hackersdelight.org/

I have written some code that has that bit fiddling vs bad branch
prediction encoding tradeoff before, i'll see if i can dig any of it up if
you'd like!

On Sun, Apr 19, 2015 at 10:41 AM, Ben Gamari <ben at smart-cactus.org> wrote:

> Joachim Breitner <mail at joachim-breitner.de> writes:
>
> > Dear devs,
> >
> > in  https://ghc.haskell.org/trac/ghc/ticket/10124 bgamari suggested that
> > code like
> >
> >         f :: Int -> Bool
> >         f a = case a of
> >                 1  -> True
> >                 5  -> True
> >                 8  -> True
> >                 9  -> True
> >                 11 -> True
> >                 19 -> True
> >                 _  -> False
> >         {-# NOINLINE f #-}
> >
> > should not compile to a series of conditional jumps, but rather a
> > branchless code akin to
> >
> >         let !p = a ==# 1 `orI#` a ==# 5 `orI#` a ==# 8 `orI#` a ==# 9
> >                          `orI#` a ==# 11 `orI#` a ==# 19
> >         case p of
> >           1 -> do_something
> >           0 -> do_something_else
> >
> Hi Joachim,
>
> Thanks for trying this and I'm sorry to hear that the optimization
> hasn't yielded the improvement I would have expected. I've been a bit
> silent on the issue as I've been working on finishing up my
> PhD. Hopefully in a couple of months after I'm settled in Germany I'll
> have time to delve into this more deeply.
>
> > Subsequently, I refactored the way we produce Cmm code from STG, opening
> > the possibility to implement this optimization at that stage?.
> >
> > But when I then added this implementation, I could not measure any
> > runtime improvement, see
> > https://ghc.haskell.org/trac/ghc/ticket/10124#comment:15
> >
> > So my question to the general audience: Is such branchless code really
> > better than the current, branching code? Can someone provide us with an
> > example that shows that it is better? Do I need to produce different
> > branchless assembly?
> >
> Have you had a look at the Intel Optimization manual? I'll admit that I
> haven't looked myself but I'd imagine they'd probably have a few things
> to say about this.
>
> Cheers,
>
> - Ben
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150419/817ab08f/attachment-0001.html>

From simonpj at microsoft.com  Mon Apr 20 08:12:07 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 20 Apr 2015 08:12:07 +0000
Subject: Cabal and simultaneous installations of the same package
In-Reply-To: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net>
References: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <c635e60512f043a09c20a1a9c096d969@DB4PR30MB030.064d.mgd.msft.net>

Friends



We started this thread (below) a month ago, but it has once more run out of steam.  The last contribution was from Vishal Agrawal



I am already planning to do a GSoC project based on it with a slightly larger aim. You can find my work in progress proposal at https://gist.github.com/fugyk/37510958b52589737274. Also I have written a patch to make cabal non-destructive at https://github.com/fugyk/cabal/commit/45ec5edbaada1fd063c67d6109e69efa0e732e6a. Can you review the proposal and give me suggestions.



I don't feel qualified to drive this process, but I do think it's important to complete it.  (I might be wrong about this too... please say so if so.) Nor do I understand why it's difficult to tie up the bow; the underlying infrastructure work is done.



Duncan especially: how can we make progress?  Do you think it's important to make progress, or are other things in cabal-land more important?  My reason for thinking that it's important is that it appears to be the root cause of many people's difficulties with Haskell and Cabal.  It might not be a panacea for all ills; but it might be a cheap remedy for a significant proportion of ills.  And that would be a Good Thing.



Thanks



Simon



|  -----Original Message-----

|  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Simon

|  Peyton Jones

|  Sent: 23 March 2015 08:46

|  To: cabal-devel at haskell.org

|  Cc: haskell-platform at projects.haskell.org; haskell-

|  infrastructure at community.galois.com; Haskell Libraries; ghc-

|  devs at haskell.org

|  Subject: Cabal and simultaneous installations of the same package

|

|  Dear Cabal developers

|

|  You'll probably have seen the thread about the Haskell Platform.

|

|  Among other things, this point arose:

|

|  |  Another thing we should fix is the (now false) impression that HP

|  | gets in  the way of installing other packages and versions due to

|  cabal hell.

|

|  People mean different things by "cabal hell", but the inability to

|     simultaneously install multiple versions of the same package,

|     compiled against different dependencies is certainly one of them,

|  and I think it is the one that Yitzchak is referring to here.

|

|  But some time now GHC has allowed multiple versions of the same package

|  (compiled against different dependencies) to be installed

|  simultaneously.  So all we need to do is to fix Cabal to allow it too,

|  and thereby kill of a huge class of cabal-hell problems at one blow.

|

|  But time has passed and it hasn't happened. Is this because I'm

|  misunderstanding?  Or because it is harder than I think?  Or because

|  there are much bigger problems?  Or because there is insufficient

|  effort available?  Or what?

|

|  Unless I'm way off beam, this "multiple installations of the same

|  package" thing has been a huge pain forever, and the solution is within

|  our grasp.  What's stopping us grasping it?

|

|  Simon

|

|  _______________________________________________

|  ghc-devs mailing list

|  ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>

|  http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150420/ecff8b8c/attachment.html>

From svenpanne at gmail.com  Mon Apr 20 14:29:12 2015
From: svenpanne at gmail.com (Sven Panne)
Date: Mon, 20 Apr 2015 16:29:12 +0200
Subject: =?UTF-8?Q?Re=3A_Branchless_implementation_for_literal_case_=E2=80=93_i?=
 =?UTF-8?Q?s_it_worth_it=3F?=
In-Reply-To: <1429429458.1607.10.camel@joachim-breitner.de>
References: <1429429458.1607.10.camel@joachim-breitner.de>
Message-ID: <CANBN=mvjauCYFsERMD9P4uR5B8MN4ainaGmmKXcL+NCRo=aoZw@mail.gmail.com>

2015-04-19 9:44 GMT+02:00 Joachim Breitner <mail at joachim-breitner.de>:
> [...] So my question to the general audience: Is such branchless code really
> better than the current, branching code? Can someone provide us with an
> example that shows that it is better? Do I need to produce different
> branchless assembly? [...]

Just a few war stories regarding this from the trenches (= Chrome's
JavaScript JIT):

   * Branchless code in itself is a non-goal. What you care about is
performance and/or code size, but both don't have a direct
relationship to using branches or not.

   * "Hacker's Delight" is a cool book, but don't use the bit fiddling
tricks in there blindly. We actually reverted to straightforward code
with branches from some seemingly "better" branchless code, because
even with branches the performance was better.

   * Even within a processor family like x64, performance
characteristics vary vastly. What can be a performance improvement for
the modern beefy Xeon machine you're benchmarking on, can make things
worse for a low-end Atom. The same holds in the other direction.

   * The same holds for different architectures, i.e. an
"optimization" which makes things fast on most Intel cores could make
things worse on e.g. ARM cores (and vice versa).

   * On more powerful cores with heavy out-of-order execution, it's
hard to beat a well-predicted branch.

   * On Linux, the perf tool is your best friend. Without it you don't
have a clue what's making your code slower than expected, it could be
bad branch prediction, stalled units with the CPU, bad luck with
caches, etc.

   * Micro-benchmarks can be highly misleading, e.g. due to totally
different branching patterns, cache usage, etc.

In a nutshell: If you don't know the details of the architecture
you're compiling for, you simply don't know if the "optimization" you
have in mind actually makes things better or worse. Therefore these
kind of decision have to be pushed very far towards the end of the
compiler pipeline. Having some kind of feedback about previous runs of
the same code is very helpful, too, but this is a bit complicated in a
batch compiler (but doable).

From mail at joachim-breitner.de  Mon Apr 20 14:41:00 2015
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 20 Apr 2015 16:41:00 +0200
Subject: Branchless implementation for literal case
 =?UTF-8?Q?=E2=80=93?= is it worth it?
In-Reply-To: <CANBN=mvjauCYFsERMD9P4uR5B8MN4ainaGmmKXcL+NCRo=aoZw@mail.gmail.com>
References: <1429429458.1607.10.camel@joachim-breitner.de>
 <CANBN=mvjauCYFsERMD9P4uR5B8MN4ainaGmmKXcL+NCRo=aoZw@mail.gmail.com>
Message-ID: <1429540860.1798.22.camel@joachim-breitner.de>

Hi,

Am Montag, den 20.04.2015, 16:29 +0200 schrieb Sven Panne:
> 2015-04-19 9:44 GMT+02:00 Joachim Breitner <mail at joachim-breitner.de>:
> > [...] So my question to the general audience: Is such branchless code really
> > better than the current, branching code? Can someone provide us with an
> > example that shows that it is better? Do I need to produce different
> > branchless assembly? [...]
> 
> Just a few war stories regarding this from the trenches (= Chrome's
> JavaScript JIT):

thanks a lot.

The conclusion I draw from your mail, at last for our case, is:
Don?t bother (and keep the compiler code simple). Is that a correct
reading?

Greetings,
Joachim


-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150420/9b87b4b2/attachment.sig>

From greg at gregorycollins.net  Mon Apr 20 16:10:02 2015
From: greg at gregorycollins.net (Gregory Collins)
Date: Mon, 20 Apr 2015 09:10:02 -0700
Subject: =?UTF-8?Q?Re=3A_Branchless_implementation_for_literal_case_=E2=80=93_i?=
 =?UTF-8?Q?s_it_worth_it=3F?=
In-Reply-To: <1429429458.1607.10.camel@joachim-breitner.de>
References: <1429429458.1607.10.camel@joachim-breitner.de>
Message-ID: <CAHZrzdp-a4nx+2gBu-tO4nWZ2doAwF5HcDN1Vk+B69n-KYb=Wg@mail.gmail.com>

I've gotten substantial speedups (>30%) in the past (e.g. in the hashtables
package) by replacing search loops with branchless code, but the technique
works best in situations where you have a long run of straight-line integer
code for the CPU to chew on; for branchless to be a win you need to feed
enough instructions into the pipeline such that the savings of getting 3
instructions per cycle and avoiding paying for branch mispredictions
outweighs the savings you would get from not doing the work. I don't think
the use case you posted falls into that category.

On Sun, Apr 19, 2015 at 12:44 AM, Joachim Breitner <mail at joachim-breitner.de
> wrote:

> Dear devs,
>
> in  https://ghc.haskell.org/trac/ghc/ticket/10124 bgamari suggested that
> code like
>
>         f :: Int -> Bool
>         f a = case a of
>                 1  -> True
>                 5  -> True
>                 8  -> True
>                 9  -> True
>                 11 -> True
>                 19 -> True
>                 _  -> False
>         {-# NOINLINE f #-}
>
> should not compile to a series of conditional jumps, but rather a
> branchless code akin to
>
>         let !p = a ==# 1 `orI#` a ==# 5 `orI#` a ==# 8 `orI#` a ==# 9
>                          `orI#` a ==# 11 `orI#` a ==# 19
>         case p of
>           1 -> do_something
>           0 -> do_something_else
>
> Subsequently, I refactored the way we produce Cmm code from STG, opening
> the possibility to implement this optimization at that stage?.
>
> But when I then added this implementation, I could not measure any
> runtime improvement, see
> https://ghc.haskell.org/trac/ghc/ticket/10124#comment:15
>
> So my question to the general audience: Is such branchless code really
> better than the current, branching code? Can someone provide us with an
> example that shows that it is better? Do I need to produce different
> branchless assembly?
>
> If it is not better, I can again refactor the switch generation and
> simplify it a bit again.
>
> Hmm, only now I see that rwbarton has replied there. Not sure why I
> missed that. Anyways, more voices are welcome :-)
>
> Greetings,
> Joachim
>
> ? This should not preclude an implementation on the Core level, which
> SPJ preferred. But I improved other aspects of the code generation as
> well, so this is worthwhile on its own.
>
> --
> Joachim ?nomeata? Breitner
>   mail at joachim-breitner.de ? http://www.joachim-breitner.de/
>   Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
>   Debian Developer: nomeata at debian.org
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>


-- 
Gregory Collins <greg at gregorycollins.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150420/7b6f6d04/attachment.html>

From svenpanne at gmail.com  Mon Apr 20 16:16:22 2015
From: svenpanne at gmail.com (Sven Panne)
Date: Mon, 20 Apr 2015 18:16:22 +0200
Subject: =?UTF-8?Q?Re=3A_Branchless_implementation_for_literal_case_=E2=80=93_i?=
 =?UTF-8?Q?s_it_worth_it=3F?=
In-Reply-To: <1429540860.1798.22.camel@joachim-breitner.de>
References: <1429429458.1607.10.camel@joachim-breitner.de>
 <CANBN=mvjauCYFsERMD9P4uR5B8MN4ainaGmmKXcL+NCRo=aoZw@mail.gmail.com>
 <1429540860.1798.22.camel@joachim-breitner.de>
Message-ID: <CANBN=mvtGuOiFUdCNk=GTfq4bSR7ZfHV76KfCb=8yu=C--T0yw@mail.gmail.com>

2015-04-20 16:41 GMT+02:00 Joachim Breitner <mail at joachim-breitner.de>:
> The conclusion I draw from your mail, at last for our case, is:
> Don?t bother (and keep the compiler code simple). Is that a correct
> reading?

Yes, I think that's the right approach. Do simple things like e.g. a
distinction between sparse cases (=> "if" cascade), lots of sparse
cases (=> some kind of decision tree) and a non-trivial number of
dense cases (jump table). For the jump table, consider computed jumps
(e.g. to a table of relative jumps, which is a common implementation
for PIC) and indirect jumps (the usual address table) in the backend.
The former could be faster than the latter (for some ARM cores IIRC),
which is not exactly intuitive. Your mileage may vary. :-)

As I said: This is our experience in a JIT, so I'd be interested in
other people's experience, too, especially for real-world programs,
not micro-benchmarks.

From mail at nh2.me  Mon Apr 20 16:29:52 2015
From: mail at nh2.me (Niklas =?utf-8?b?SGFtYsO8Y2hlbg==?=)
Date: Mon, 20 Apr 2015 16:29:52 +0000 (UTC)
Subject: Backporting srcLoc to the GHC 7.10 branch
References: <CAKA2JgJRPVE03CLr2HPRLs3Qh0wu99dgGWu-N+AJeRNDp2tu5g@mail.gmail.com>
 <CAEs96n1u37uoCZnOmtJbirXZ69nTb=Ay9mO=qrUu=TTUimECYQ@mail.gmail.com>
 <1427134456.180256.244160054.58D3091A@webmail.messagingengine.com>
Message-ID: <loom.20150420T172159-556@post.gmane.org>

Hello everybody,

I'm glad to announce that I performed the suggested backporting as part of 
my work for FP Complete!

With the help of Eric (thanks for your support in #ghc!) we now have this 
patch for 7.10 and 7.8.

As promised, here are the commits:

* https://github.com/nh2/ghc/commits/ghc-7.10.1-release-srcloc-ip
* https://github.com/nh2/ghc/commits/ghc-7.8.4-release-srcloc-ip

You can see in the history that I only needed to cherry-pick "Make the 
location in TcLclEnv and CtLoc into a RealSrcSpan" as a dependent commit, 
so the changes beyond the actual feature are fairly minimal.

For 7.8, I had to do a little more cleanup, see the "Use wrapIPTc instead 
of coercionToTcCoercion on wrapIP" commit.

Regarding the commit of the feature itself, I had to do quite some merge 
resolution, especially due to the (lack of) the -fwarn-redundant-
constraints patch https://github.com/nh2/ghc/commit/32973bf3 (alias "but it 
was Christmas, so I did some recreational programming that went much 
further").
However, the type checker had a strong opinion of what the right merge 
decision was, at least for the 7.10 backport; for 7.8 there was an 
ambiguity (whether to return `Nothing` or `Just` in `interactDict`), which 
was resolved with Eric's help.

Please be invited to review the two commits.

We would like to make 7.8 and 7.10 binaries with this feature available as 
well, and will do so after getting a review!

Niklas


From greg at gregweber.info  Mon Apr 20 17:07:34 2015
From: greg at gregweber.info (Greg Weber)
Date: Mon, 20 Apr 2015 10:07:34 -0700
Subject: Backporting srcLoc to the GHC 7.10 branch
In-Reply-To: <loom.20150420T172159-556@post.gmane.org>
References: <CAKA2JgJRPVE03CLr2HPRLs3Qh0wu99dgGWu-N+AJeRNDp2tu5g@mail.gmail.com>
 <CAEs96n1u37uoCZnOmtJbirXZ69nTb=Ay9mO=qrUu=TTUimECYQ@mail.gmail.com>
 <1427134456.180256.244160054.58D3091A@webmail.messagingengine.com>
 <loom.20150420T172159-556@post.gmane.org>
Message-ID: <CAKRanNDeeOnqi6dzYQLyH+euuwWvsYqt83qf=WimR+t+qqT1wA@mail.gmail.com>

Thanks a lot! Is there any plan to make error or other partial functions in
the base libraries use this feature?

On Mon, Apr 20, 2015 at 9:29 AM, Niklas Hamb?chen <mail at nh2.me> wrote:

> Hello everybody,
>
> I'm glad to announce that I performed the suggested backporting as part of
> my work for FP Complete!
>
> With the help of Eric (thanks for your support in #ghc!) we now have this
> patch for 7.10 and 7.8.
>
> As promised, here are the commits:
>
> * https://github.com/nh2/ghc/commits/ghc-7.10.1-release-srcloc-ip
> * https://github.com/nh2/ghc/commits/ghc-7.8.4-release-srcloc-ip
>
> You can see in the history that I only needed to cherry-pick "Make the
> location in TcLclEnv and CtLoc into a RealSrcSpan" as a dependent commit,
> so the changes beyond the actual feature are fairly minimal.
>
> For 7.8, I had to do a little more cleanup, see the "Use wrapIPTc instead
> of coercionToTcCoercion on wrapIP" commit.
>
> Regarding the commit of the feature itself, I had to do quite some merge
> resolution, especially due to the (lack of) the -fwarn-redundant-
> constraints patch https://github.com/nh2/ghc/commit/32973bf3 (alias "but
> it
> was Christmas, so I did some recreational programming that went much
> further").
> However, the type checker had a strong opinion of what the right merge
> decision was, at least for the 7.10 backport; for 7.8 there was an
> ambiguity (whether to return `Nothing` or `Just` in `interactDict`), which
> was resolved with Eric's help.
>
> Please be invited to review the two commits.
>
> We would like to make 7.8 and 7.10 binaries with this feature available as
> well, and will do so after getting a review!
>
> Niklas
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150420/dab07bf4/attachment-0001.html>

From nicu at ionita.at  Mon Apr 20 17:45:22 2015
From: nicu at ionita.at (Niculae Ionita)
Date: Mon, 20 Apr 2015 19:45:22 +0200
Subject: =?windows-1252?Q?Fwd=3A_Re=3A_Branchless_implementation_?=
 =?windows-1252?Q?for_literal_case_=96_is_it_worth_it=3F?=
In-Reply-To: <55351CA7.3080601@ionita.at>
References: <55351CA7.3080601@ionita.at>
Message-ID: <55353B32.3020206@ionita.at>

Sorry, I forgot to answer to the list.

If the code is already there and some architectures can profit of it, 
especially in inner loops - why not just make it an optimisation flag?

Nicu

Am 20.04.2015 um 16:41 schrieb Joachim Breitner:
> Hi,
>
> Am Montag, den 20.04.2015, 16:29 +0200 schrieb Sven Panne:
>> 2015-04-19 9:44 GMT+02:00 Joachim Breitner<mail at joachim-breitner.de>:
>>> [...] So my question to the general audience: Is such branchless code really
>>> better than the current, branching code? Can someone provide us with an
>>> example that shows that it is better? Do I need to produce different
>>> branchless assembly? [...]
>> Just a few war stories regarding this from the trenches (= Chrome's
>> JavaScript JIT):
> thanks a lot.
>
> The conclusion I draw from your mail, at last for our case, is:
> Don?t bother (and keep the compiler code simple). Is that a correct
> reading?
>
> Greetings,
> Joachim
>
>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs




From mail at joachim-breitner.de  Mon Apr 20 18:05:18 2015
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 20 Apr 2015 20:05:18 +0200
Subject: Fwd: Re: Branchless implementation for literal case
 =?UTF-8?Q?=E2=80=93?= is it worth it?
In-Reply-To: <55353B32.3020206@ionita.at>
References: <55351CA7.3080601@ionita.at> <55353B32.3020206@ionita.at>
Message-ID: <1429553118.15613.2.camel@joachim-breitner.de>

Hi,

Am Montag, den 20.04.2015, 19:45 +0200 schrieb Niculae Ionita:
> Sorry, I forgot to answer to the list.

ah, and sorry for telling you so before looking on the list.

> If the code is already there and some architectures can profit of it, 
> especially in inner loops - why not just make it an optimisation flag?

Without even one good example where it is an improvement, this does not
make sense. And even with an example: It degrades performance in other
cases, so a module-wide flag would probably not cut it.


Greetings,
Joachim
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150420/0bb3c641/attachment.sig>

From dan.doel at gmail.com  Mon Apr 20 18:39:59 2015
From: dan.doel at gmail.com (Dan Doel)
Date: Mon, 20 Apr 2015 14:39:59 -0400
Subject: =?UTF-8?Q?Re=3A_Branchless_implementation_for_literal_case_=E2=80=93_i?=
 =?UTF-8?Q?s_it_worth_it=3F?=
In-Reply-To: <CANBN=mvjauCYFsERMD9P4uR5B8MN4ainaGmmKXcL+NCRo=aoZw@mail.gmail.com>
References: <1429429458.1607.10.camel@joachim-breitner.de>
 <CANBN=mvjauCYFsERMD9P4uR5B8MN4ainaGmmKXcL+NCRo=aoZw@mail.gmail.com>
Message-ID: <CAHEA9tNtshDbEu7pomjb0USc_Es_MZ4NfwSv2r-AUUzRQ1j1mw@mail.gmail.com>

On Mon, Apr 20, 2015 at 10:29 AM, Sven Panne <svenpanne at gmail.com> wrote:

>    * On more powerful cores with heavy out-of-order execution, it's
> hard to beat a well-predicted branch.
>

?With regard to this, I was wondering if we have a way of arranging for
good branch prediction in GHC.

For instance (and I think I've discussed this with Carter before), we've
had issues filed against vector (I think) saying that we do branches for
certain things that could be branchless. Bounds checks are the first thing
that comes to mind, for instance (I.E. we don't use orI# for the lower and
upper bound checks). However, so long as branch prediction decides that the
bounds checks should succeed, I'd expect them to not be much of a cost
anyway---and ideally it will always decide that, because we're inclined not
to care about the performance when the checks fail and the program is
bombing.

However, from what I've read, there's basically no easy hinting that can
ensure this. The heuristics require moving generated code around if you
want to try and influence the branch predictor one way. And we also have no
way of indicating to GHC that branches of a case should be preferred
anyway. Unless writing things in a certain order accomplishes this?

-- Dan
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150420/3c644e27/attachment.html>

From simonpj at microsoft.com  Mon Apr 20 19:29:34 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 20 Apr 2015 19:29:34 +0000
Subject: =?Windows-1252?Q?RE:_Fwd:_Re:_Branchless_implementation_for_literal_case_?=
 =?Windows-1252?Q?=96_is_it_worth_it=3F?=
In-Reply-To: <1429553118.15613.2.camel@joachim-breitner.de>
References: <55351CA7.3080601@ionita.at> <55353B32.3020206@ionita.at>
 <1429553118.15613.2.camel@joachim-breitner.de>
Message-ID: <55b328e14a3a4ac8b340e38728de21e5@DB4PR30MB030.064d.mgd.msft.net>


| > If the code is already there and some architectures can profit of it,
| > especially in inner loops - why not just make it an optimisation flag?
| 
| Without even one good example where it is an improvement, this does not
| make sense. And even with an example: It degrades performance in other
| cases, so a module-wide flag would probably not cut it.

Moreover code complexity in the compiler carries a real cost. Don't underestimate it!

Simon

From mail at nh2.me  Tue Apr 21 16:33:17 2015
From: mail at nh2.me (=?UTF-8?B?TmlrbGFzIEhhbWLDvGNoZW4=?=)
Date: Wed, 22 Apr 2015 01:33:17 +0900
Subject: Backporting srcLoc to the GHC 7.10 branch
In-Reply-To: <CAKRanNDeeOnqi6dzYQLyH+euuwWvsYqt83qf=WimR+t+qqT1wA@mail.gmail.com>
References: <CAKA2JgJRPVE03CLr2HPRLs3Qh0wu99dgGWu-N+AJeRNDp2tu5g@mail.gmail.com>
 <CAEs96n1u37uoCZnOmtJbirXZ69nTb=Ay9mO=qrUu=TTUimECYQ@mail.gmail.com>
 <1427134456.180256.244160054.58D3091A@webmail.messagingengine.com>
 <loom.20150420T172159-556@post.gmane.org>
 <CAKRanNDeeOnqi6dzYQLyH+euuwWvsYqt83qf=WimR+t+qqT1wA@mail.gmail.com>
Message-ID: <55367BCD.7070009@nh2.me>

Yes, I do have work in progress on using this feature in `error` and
`undefined`.

I will upload that as a Phabricator Diff soon, and mention the URL here.

Niklas

On 21/04/15 02:07, Greg Weber wrote:
> Thanks a lot! Is there any plan to make error or other partial functions
> in the base libraries use this feature?

From dev at rodlogic.net  Tue Apr 21 17:42:09 2015
From: dev at rodlogic.net (RodLogic)
Date: Tue, 21 Apr 2015 13:42:09 -0400
Subject: Backporting srcLoc to the GHC 7.10 branch
In-Reply-To: <55367BCD.7070009@nh2.me>
References: <CAKA2JgJRPVE03CLr2HPRLs3Qh0wu99dgGWu-N+AJeRNDp2tu5g@mail.gmail.com>
 <CAEs96n1u37uoCZnOmtJbirXZ69nTb=Ay9mO=qrUu=TTUimECYQ@mail.gmail.com>
 <1427134456.180256.244160054.58D3091A@webmail.messagingengine.com>
 <loom.20150420T172159-556@post.gmane.org>
 <CAKRanNDeeOnqi6dzYQLyH+euuwWvsYqt83qf=WimR+t+qqT1wA@mail.gmail.com>
 <55367BCD.7070009@nh2.me>
Message-ID: <CA++tqLb_Zx8dTwWz_s7mOEGWg64_61A5z=HDtW5QAeEA9BN2Yw@mail.gmail.com>

Hi Niklas,

Fyi: what about assert? Afaik, there is special treatment in the compiler
for the assert that could be replaced by this (?).

On Tuesday, April 21, 2015, Niklas Hamb?chen <mail at nh2.me> wrote:

> Yes, I do have work in progress on using this feature in `error` and
> `undefined`.
>
> I will upload that as a Phabricator Diff soon, and mention the URL here.
>
> Niklas
>
> On 21/04/15 02:07, Greg Weber wrote:
> > Thanks a lot! Is there any plan to make error or other partial functions
> > in the base libraries use this feature?
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org <javascript:;>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150421/ca64dd00/attachment.html>

From mail at nh2.me  Tue Apr 21 18:03:59 2015
From: mail at nh2.me (=?UTF-8?B?TmlrbGFzIEhhbWLDvGNoZW4=?=)
Date: Wed, 22 Apr 2015 03:03:59 +0900
Subject: Backporting srcLoc to the GHC 7.10 branch
In-Reply-To: <55367BCD.7070009@nh2.me>
References: <CAKA2JgJRPVE03CLr2HPRLs3Qh0wu99dgGWu-N+AJeRNDp2tu5g@mail.gmail.com>
 <CAEs96n1u37uoCZnOmtJbirXZ69nTb=Ay9mO=qrUu=TTUimECYQ@mail.gmail.com>
 <1427134456.180256.244160054.58D3091A@webmail.messagingengine.com>
 <loom.20150420T172159-556@post.gmane.org>
 <CAKRanNDeeOnqi6dzYQLyH+euuwWvsYqt83qf=WimR+t+qqT1wA@mail.gmail.com>
 <55367BCD.7070009@nh2.me>
Message-ID: <5536910F.90402@nh2.me>

On 22/04/15 01:33, Niklas Hamb?chen wrote:
> I will upload that as a Phabricator Diff soon, and mention the URL here.

Here it is: https://phabricator.haskell.org/D861

From mail at nh2.me  Tue Apr 21 18:04:52 2015
From: mail at nh2.me (=?UTF-8?B?TmlrbGFzIEhhbWLDvGNoZW4=?=)
Date: Wed, 22 Apr 2015 03:04:52 +0900
Subject: Backporting srcLoc to the GHC 7.10 branch
In-Reply-To: <CA++tqLb_Zx8dTwWz_s7mOEGWg64_61A5z=HDtW5QAeEA9BN2Yw@mail.gmail.com>
References: <CAKA2JgJRPVE03CLr2HPRLs3Qh0wu99dgGWu-N+AJeRNDp2tu5g@mail.gmail.com>	<CAEs96n1u37uoCZnOmtJbirXZ69nTb=Ay9mO=qrUu=TTUimECYQ@mail.gmail.com>	<1427134456.180256.244160054.58D3091A@webmail.messagingengine.com>	<loom.20150420T172159-556@post.gmane.org>	<CAKRanNDeeOnqi6dzYQLyH+euuwWvsYqt83qf=WimR+t+qqT1wA@mail.gmail.com>	<55367BCD.7070009@nh2.me>
 <CA++tqLb_Zx8dTwWz_s7mOEGWg64_61A5z=HDtW5QAeEA9BN2Yw@mail.gmail.com>
Message-ID: <55369144.1060008@nh2.me>

On 22/04/15 02:42, RodLogic wrote:
> Fyi: what about assert? Afaik, there is special treatment in the
> compiler for the assert that could be replaced by this (?).

Yes, replacing the custom code for `assert` was also on Eric's plan, see
the comment he just made:

  https://phabricator.haskell.org/D861#23250

From mail at nh2.me  Tue Apr 21 18:27:00 2015
From: mail at nh2.me (=?windows-1252?Q?Niklas_Hamb=FCchen?=)
Date: Wed, 22 Apr 2015 03:27:00 +0900
Subject: Backporting srcLoc to the GHC 7.10 branch
In-Reply-To: <loom.20150420T172159-556@post.gmane.org>
References: <CAKA2JgJRPVE03CLr2HPRLs3Qh0wu99dgGWu-N+AJeRNDp2tu5g@mail.gmail.com>
 <CAEs96n1u37uoCZnOmtJbirXZ69nTb=Ay9mO=qrUu=TTUimECYQ@mail.gmail.com>
 <1427134456.180256.244160054.58D3091A@webmail.messagingengine.com>
 <loom.20150420T172159-556@post.gmane.org>
Message-ID: <55369674.7070706@nh2.me>

On 21/04/15 01:29, Niklas Hamb?chen wrote:
> We would like to make 7.8 and 7.10 binaries with this feature available as 
> well, and will do so after getting a review!

Here's a 64-bit Linux binary distribution of 7.10 including this backport:

  https://github.com/nh2/ghc/releases/tag/ghc-7.10.1-release-srcloc-ip

Please have a review of the backport still :)

From afarmer at ittc.ku.edu  Wed Apr 22 21:10:12 2015
From: afarmer at ittc.ku.edu (Andrew Farmer)
Date: Wed, 22 Apr 2015 16:10:12 -0500
Subject: OS X bindist
Message-ID: <CAJ14jR_LFNWg2SgZ7Yc3wh9OhZJCbX0S2Ld8ccxhyHa0zqj50Q@mail.gmail.com>

Forgive me if this has been answered somewhere, but is there an
officially sanctioned bindist of 7.10.1 for OS X yet? The page I
usually visit [1] doesn't list one yet.

Thanks!
Andrew

[1] https://www.haskell.org/ghc/download_ghc_7_10_1

From bob at redivi.com  Wed Apr 22 22:05:09 2015
From: bob at redivi.com (Bob Ippolito)
Date: Wed, 22 Apr 2015 18:05:09 -0400
Subject: OS X bindist
In-Reply-To: <CAJ14jR_LFNWg2SgZ7Yc3wh9OhZJCbX0S2Ld8ccxhyHa0zqj50Q@mail.gmail.com>
References: <CAJ14jR_LFNWg2SgZ7Yc3wh9OhZJCbX0S2Ld8ccxhyHa0zqj50Q@mail.gmail.com>
Message-ID: <CACwMPm9fcdybTg=ueGosEoXeFYxk1qs-UhZjsHucb82yXtfpcw@mail.gmail.com>

https://halcyon.global.ssl.fastly.net/original/ghc-7.10.1-x86_64-apple-darwin.tar.bz2
is the build that http://ghcformacosx.github.io/ used.

On Wed, Apr 22, 2015 at 5:10 PM, Andrew Farmer <afarmer at ittc.ku.edu> wrote:

> Forgive me if this has been answered somewhere, but is there an
> officially sanctioned bindist of 7.10.1 for OS X yet? The page I
> usually visit [1] doesn't list one yet.
>
> Thanks!
> Andrew
>
> [1] https://www.haskell.org/ghc/download_ghc_7_10_1
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150422/a49dfd38/attachment.html>

From carter.schonwald at gmail.com  Thu Apr 23 00:23:47 2015
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Wed, 22 Apr 2015 20:23:47 -0400
Subject: OS X bindist
In-Reply-To: <CAJ14jR_LFNWg2SgZ7Yc3wh9OhZJCbX0S2Ld8ccxhyHa0zqj50Q@mail.gmail.com>
References: <CAJ14jR_LFNWg2SgZ7Yc3wh9OhZJCbX0S2Ld8ccxhyHa0zqj50Q@mail.gmail.com>
Message-ID: <CAHYVw0zwEmyRZiToAPnKBd5fDawEUv4n=Ycb4OZfOTBieFWM_w@mail.gmail.com>

I can do one if folks want.

On Wednesday, April 22, 2015, Andrew Farmer <afarmer at ittc.ku.edu> wrote:

> Forgive me if this has been answered somewhere, but is there an
> officially sanctioned bindist of 7.10.1 for OS X yet? The page I
> usually visit [1] doesn't list one yet.
>
> Thanks!
> Andrew
>
> [1] https://www.haskell.org/ghc/download_ghc_7_10_1
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org <javascript:;>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150422/04e47efb/attachment.html>

From eir at cis.upenn.edu  Thu Apr 23 00:32:17 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Wed, 22 Apr 2015 20:32:17 -0400
Subject: OS X bindist
In-Reply-To: <CAJ14jR_LFNWg2SgZ7Yc3wh9OhZJCbX0S2Ld8ccxhyHa0zqj50Q@mail.gmail.com>
References: <CAJ14jR_LFNWg2SgZ7Yc3wh9OhZJCbX0S2Ld8ccxhyHa0zqj50Q@mail.gmail.com>
Message-ID: <FA9B41F7-4A58-4BAD-852A-D8935AAB6D5A@cis.upenn.edu>

Speaking of this, is it possible to get an official build put up on the page Andrew links to? In my opinion, we shouldn't announce a new release until binaries are available at haskell.org for all Tier-1 platforms.

Thanks!
Richard

On Apr 22, 2015, at 5:10 PM, Andrew Farmer <afarmer at ittc.ku.edu> wrote:

> Forgive me if this has been answered somewhere, but is there an
> officially sanctioned bindist of 7.10.1 for OS X yet? The page I
> usually visit [1] doesn't list one yet.
> 
> Thanks!
> Andrew
> 
> [1] https://www.haskell.org/ghc/download_ghc_7_10_1
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


From mietek at bak.io  Thu Apr 23 00:47:38 2015
From: mietek at bak.io (=?iso-8859-1?Q?Mi=EBtek_Bak?=)
Date: Thu, 23 Apr 2015 01:47:38 +0100
Subject: OS X bindist
In-Reply-To: <CACwMPm9fcdybTg=ueGosEoXeFYxk1qs-UhZjsHucb82yXtfpcw@mail.gmail.com>
References: <CAJ14jR_LFNWg2SgZ7Yc3wh9OhZJCbX0S2Ld8ccxhyHa0zqj50Q@mail.gmail.com>
 <CACwMPm9fcdybTg=ueGosEoXeFYxk1qs-UhZjsHucb82yXtfpcw@mail.gmail.com>
Message-ID: <DEC84CCC-A857-4D1C-ABBA-A798353DD8F1@bak.io>

The same 7.10.1 bindist is also available on the official downloads site; it?s just not linked from the GHC page yet:
https://downloads.haskell.org/~ghc/7.10.1/


-- 
Mi?tek
https://mietek.io




On 2015-04-22, at 23:05, Bob Ippolito <bob at redivi.com> wrote:

> https://halcyon.global.ssl.fastly.net/original/ghc-7.10.1-x86_64-apple-darwin.tar.bz2 is the build that http://ghcformacosx.github.io/ used.
> 
> 
> On Wed, Apr 22, 2015 at 5:10 PM, Andrew Farmer <afarmer at ittc.ku.edu> wrote:
> Forgive me if this has been answered somewhere, but is there an
> officially sanctioned bindist of 7.10.1 for OS X yet? The page I
> usually visit [1] doesn't list one yet.
> 
> Thanks!
> Andrew
> 
> [1] https://www.haskell.org/ghc/download_ghc_7_10_1
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4203 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150423/80b3b27f/attachment.bin>

From eir at cis.upenn.edu  Thu Apr 23 02:07:23 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Thu, 23 Apr 2015 02:07:23 -0000
Subject: Bug: GHC creates incorrect code which throws <<loop>>
In-Reply-To: <CAKF_vo7NH0oWd2jyRAUesq4z-PGzFoE2g07BfWW_TNdnYefs5w@mail.gmail.com>
References: <CAKF_vo7NH0oWd2jyRAUesq4z-PGzFoE2g07BfWW_TNdnYefs5w@mail.gmail.com>
Message-ID: <936EE260-C8EA-4B0C-BF2A-3ED3EFF97DD4@cis.upenn.edu>

Thanks for posting the bug and bringing it to our attention. The reason the report may not have gotten attention is that I believe this falls in Simon PJ's domain, and he's on holiday right now. I took a quick look, but I haven't a clue about this area of GHC, so there's not much I can contribute. Unless someone else out there knows much about black-holing, you may have to wait a bit. Sorry!

Richard

On Mar 31, 2015, at 9:48 PM, Yongqian Li <yongqli at kerrmetric.com> wrote:

> Hi all,
> 
> I wanted to bring to your attention this bug,
> https://ghc.haskell.org/trac/ghc/ticket/10218 , which I filed about
> two days ago but hasn't gotten any replies to yet.
> 
> 
> In my opinion, this is a rather serious bug since GHC is producing
> incorrect code. While there is a workaround, it makes my program take
> about 2 hours to compile.
> 
> 
> Since reporting the bug, I've also seen "strange closure type"
> exceptions, which I believe are also caused by this bug, although I do
> not have a test case. Based on my limited understanding of GHC
> internals, I suspect the problem lies in how type class dictionaries
> are looked up at run time, as the problem disappears if GHC can fully
> resolve the types.
> 
> 
> Can others see if they can reproduce this bug? If there is any way I
> can help, please let me know.
> 
> 
> Sincerely,
> Yongqian Li
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


From simonpj at microsoft.com  Thu Apr 23 08:10:17 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 23 Apr 2015 08:10:17 +0000
Subject: Bug: GHC creates incorrect code which throws <<loop>>
In-Reply-To: <936EE260-C8EA-4B0C-BF2A-3ED3EFF97DD4@cis.upenn.edu>
References: <CAKF_vo7NH0oWd2jyRAUesq4z-PGzFoE2g07BfWW_TNdnYefs5w@mail.gmail.com>
 <936EE260-C8EA-4B0C-BF2A-3ED3EFF97DD4@cis.upenn.edu>
Message-ID: <8129cd2581974303af7cc43a0a2fa47b@DB4PR30MB030.064d.mgd.msft.net>

#10218 is fully fixed, so are we good on this one now?

Simon

|  -----Original Message-----
|  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
|  Richard Eisenberg
|  Sent: 01 April 2015 17:52
|  To: Yongqian Li
|  Cc: ghc-devs at haskell.org
|  Subject: Re: Bug: GHC creates incorrect code which throws <<loop>>
|  
|  Thanks for posting the bug and bringing it to our attention. The reason
|  the report may not have gotten attention is that I believe this falls
|  in Simon PJ's domain, and he's on holiday right now. I took a quick
|  look, but I haven't a clue about this area of GHC, so there's not much
|  I can contribute. Unless someone else out there knows much about black-
|  holing, you may have to wait a bit. Sorry!
|  
|  Richard
|  
|  On Mar 31, 2015, at 9:48 PM, Yongqian Li <yongqli at kerrmetric.com>
|  wrote:
|  
|  > Hi all,
|  >
|  > I wanted to bring to your attention this bug,
|  > https://ghc.haskell.org/trac/ghc/ticket/10218 , which I filed about
|  > two days ago but hasn't gotten any replies to yet.
|  >
|  >
|  > In my opinion, this is a rather serious bug since GHC is producing
|  > incorrect code. While there is a workaround, it makes my program take
|  > about 2 hours to compile.
|  >
|  >
|  > Since reporting the bug, I've also seen "strange closure type"
|  > exceptions, which I believe are also caused by this bug, although I
|  do
|  > not have a test case. Based on my limited understanding of GHC
|  > internals, I suspect the problem lies in how type class dictionaries
|  > are looked up at run time, as the problem disappears if GHC can fully
|  > resolve the types.
|  >
|  >
|  > Can others see if they can reproduce this bug? If there is any way I
|  > can help, please let me know.
|  >
|  >
|  > Sincerely,
|  > Yongqian Li
|  > _______________________________________________
|  > ghc-devs mailing list
|  > ghc-devs at haskell.org
|  > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
|  
|  _______________________________________________
|  ghc-devs mailing list
|  ghc-devs at haskell.org
|  http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From mail at joachim-breitner.de  Thu Apr 23 08:39:11 2015
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 23 Apr 2015 10:39:11 +0200
Subject: Bug: GHC creates incorrect code which throws <<loop>>
In-Reply-To: <8129cd2581974303af7cc43a0a2fa47b@DB4PR30MB030.064d.mgd.msft.net>
References: <CAKF_vo7NH0oWd2jyRAUesq4z-PGzFoE2g07BfWW_TNdnYefs5w@mail.gmail.com>
 <936EE260-C8EA-4B0C-BF2A-3ED3EFF97DD4@cis.upenn.edu>
 <8129cd2581974303af7cc43a0a2fa47b@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <1429778351.1664.7.camel@joachim-breitner.de>

HI,

Am Donnerstag, den 23.04.2015, 08:10 +0000 schrieb Simon Peyton Jones:
> #10218 is fully fixed, so are we good on this one now?

note the date of Richard?s message: April 1st. Looks like it got stuck
in the internets for a long time...

(I was confused at first as well.)


Greetings,
Joachim

-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150423/b89ea604/attachment.sig>

From yongqli at kerrmetric.com  Thu Apr 23 09:00:40 2015
From: yongqli at kerrmetric.com (Yongqian Li)
Date: Thu, 23 Apr 2015 02:00:40 -0700
Subject: Bug: GHC creates incorrect code which throws <<loop>>
In-Reply-To: <8129cd2581974303af7cc43a0a2fa47b@DB4PR30MB030.064d.mgd.msft.net>
References: <CAKF_vo7NH0oWd2jyRAUesq4z-PGzFoE2g07BfWW_TNdnYefs5w@mail.gmail.com>
 <936EE260-C8EA-4B0C-BF2A-3ED3EFF97DD4@cis.upenn.edu>
 <8129cd2581974303af7cc43a0a2fa47b@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <CAKF_vo4n2=AKX9x_d4DZbU1-C_oGftWnN3cy=qOmwXmAFuyGPA@mail.gmail.com>

Yes, looks good. I haven't had a chance to test it yet though.

On Thu, Apr 23, 2015 at 1:10 AM, Simon Peyton Jones
<simonpj at microsoft.com> wrote:
> #10218 is fully fixed, so are we good on this one now?
>
> Simon
>
> |  -----Original Message-----
> |  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
> |  Richard Eisenberg
> |  Sent: 01 April 2015 17:52
> |  To: Yongqian Li
> |  Cc: ghc-devs at haskell.org
> |  Subject: Re: Bug: GHC creates incorrect code which throws <<loop>>
> |
> |  Thanks for posting the bug and bringing it to our attention. The reason
> |  the report may not have gotten attention is that I believe this falls
> |  in Simon PJ's domain, and he's on holiday right now. I took a quick
> |  look, but I haven't a clue about this area of GHC, so there's not much
> |  I can contribute. Unless someone else out there knows much about black-
> |  holing, you may have to wait a bit. Sorry!
> |
> |  Richard
> |
> |  On Mar 31, 2015, at 9:48 PM, Yongqian Li <yongqli at kerrmetric.com>
> |  wrote:
> |
> |  > Hi all,
> |  >
> |  > I wanted to bring to your attention this bug,
> |  > https://ghc.haskell.org/trac/ghc/ticket/10218 , which I filed about
> |  > two days ago but hasn't gotten any replies to yet.
> |  >
> |  >
> |  > In my opinion, this is a rather serious bug since GHC is producing
> |  > incorrect code. While there is a workaround, it makes my program take
> |  > about 2 hours to compile.
> |  >
> |  >
> |  > Since reporting the bug, I've also seen "strange closure type"
> |  > exceptions, which I believe are also caused by this bug, although I
> |  do
> |  > not have a test case. Based on my limited understanding of GHC
> |  > internals, I suspect the problem lies in how type class dictionaries
> |  > are looked up at run time, as the problem disappears if GHC can fully
> |  > resolve the types.
> |  >
> |  >
> |  > Can others see if they can reproduce this bug? If there is any way I
> |  > can help, please let me know.
> |  >
> |  >
> |  > Sincerely,
> |  > Yongqian Li
> |  > _______________________________________________
> |  > ghc-devs mailing list
> |  > ghc-devs at haskell.org
> |  > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> |
> |  _______________________________________________
> |  ghc-devs mailing list
> |  ghc-devs at haskell.org
> |  http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From ggreif at gmail.com  Thu Apr 23 14:04:31 2015
From: ggreif at gmail.com (Gabor Greif)
Date: Thu, 23 Apr 2015 16:04:31 +0200
Subject: deriving Typeable and Nat kinds
Message-ID: <CAK-hX0kFGEHrWEKR6g1qzn0nqj9E9O35LzpA0V5_nEha2U=QMQ@mail.gmail.com>

Hi devs,

between ghc-7.11.20150215 and ghc-7.11.20150407 I experienced a
strange regression with deriving Typeable for data with Nat-kinded
indices.

Something like this used to work (I cannot post the whole thing, unfortunately)

{{{
data OTU (p :: Nat) (o :: Nat) = OTU { ...fields... } deriving (Show, Typeable)
}}}

With my ghc-7.11.20150407 (and later) strange obligations of the form
`Typeable p` appear, rendering my code uncompilable. But there is no
way I can see how I can convince the type checker that the Nat index
is indeed Typeable. I *do* have a `KnownNat p` constraint around,
though.

The relevant changes to mainline appear to be
https://github.com/ghc/ghc/commit/b359c886cd7578ed083bcedcea05d315ecaeeb54
https://github.com/ghc/ghc/commit/3a0019e3672097761e7ce09c811018f774febfd2

both by Iavor.

So now my questions:

1) Is this a regression on mainline? (I surely hope so!) How did this
work before?
2) Should `KnownNat p` imply `Typeable p` for the ability to have my
`Typeable (OTU p o)`
3) if 2) is answered with "NO", how am I supposed to satisfy those constraints?

Thanks and cheers,

    Gabor


PS: Sometimes I feel like a canary doing my research-like programming
with GHC-HEAD, and it is a mostly positive experience, but events like
this make me shiver...

From iavor.diatchki at gmail.com  Thu Apr 23 15:00:14 2015
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Thu, 23 Apr 2015 08:00:14 -0700
Subject: deriving Typeable and Nat kinds
In-Reply-To: <CAK-hX0kFGEHrWEKR6g1qzn0nqj9E9O35LzpA0V5_nEha2U=QMQ@mail.gmail.com>
References: <CAK-hX0kFGEHrWEKR6g1qzn0nqj9E9O35LzpA0V5_nEha2U=QMQ@mail.gmail.com>
Message-ID: <CAGK9nuqk7x3B_UxZwB0Du5Bxidc0iO7TxBMnXgLQji2bS55s6w@mail.gmail.com>

Hello,

Apologies if my changes caused difficulties with your work---we made the
changes to `Typable` to preserve the soundness of the type system,
hopefully the new behavior is exactly equivalent to the old in the safe
cases.

Could you post an example of the code where the unwanted `Typeable p`
constraint appears?  It seems entirely reasonable that if you want to solve
`Typeable (OUT p o)`, you'll have to provide `Typealbe p`, so I am not
seeing the whole picture.

To answer your question about `KnownNat p`---there is no relation between
it and `Typeable`.   You may think if a `KnownNat x` constraint as just the
integer `x`.  As it happens, the integer is closely related to the
`Typeable` instance for the number, so I think we *could* make it work so
that if you have `KnownNat p`, then you can get `Typeable p`, but this has
never worked previosly, so perhaps there is another issue.

-Iavor



On Thu, Apr 23, 2015 at 7:04 AM, Gabor Greif <ggreif at gmail.com> wrote:

> Hi devs,
>
> between ghc-7.11.20150215 and ghc-7.11.20150407 I experienced a
> strange regression with deriving Typeable for data with Nat-kinded
> indices.
>
> Something like this used to work (I cannot post the whole thing,
> unfortunately)
>
> {{{
> data OTU (p :: Nat) (o :: Nat) = OTU { ...fields... } deriving (Show,
> Typeable)
> }}}
>
> With my ghc-7.11.20150407 (and later) strange obligations of the form
> `Typeable p` appear, rendering my code uncompilable. But there is no
> way I can see how I can convince the type checker that the Nat index
> is indeed Typeable. I *do* have a `KnownNat p` constraint around,
> though.
>
> The relevant changes to mainline appear to be
> https://github.com/ghc/ghc/commit/b359c886cd7578ed083bcedcea05d315ecaeeb54
> https://github.com/ghc/ghc/commit/3a0019e3672097761e7ce09c811018f774febfd2
>
> both by Iavor.
>
> So now my questions:
>
> 1) Is this a regression on mainline? (I surely hope so!) How did this
> work before?
> 2) Should `KnownNat p` imply `Typeable p` for the ability to have my
> `Typeable (OTU p o)`
> 3) if 2) is answered with "NO", how am I supposed to satisfy those
> constraints?
>
> Thanks and cheers,
>
>     Gabor
>
>
> PS: Sometimes I feel like a canary doing my research-like programming
> with GHC-HEAD, and it is a mostly positive experience, but events like
> this make me shiver...
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150423/756d4828/attachment.html>

From ggreif at gmail.com  Thu Apr 23 15:37:31 2015
From: ggreif at gmail.com (Gabor Greif)
Date: Thu, 23 Apr 2015 17:37:31 +0200
Subject: deriving Typeable and Nat kinds
In-Reply-To: <CAGK9nuqk7x3B_UxZwB0Du5Bxidc0iO7TxBMnXgLQji2bS55s6w@mail.gmail.com>
References: <CAK-hX0kFGEHrWEKR6g1qzn0nqj9E9O35LzpA0V5_nEha2U=QMQ@mail.gmail.com>
 <CAGK9nuqk7x3B_UxZwB0Du5Bxidc0iO7TxBMnXgLQji2bS55s6w@mail.gmail.com>
Message-ID: <CAK-hX0nKbcnQrP0Au0ySQ9uDOqNn=27J4xkLRTPPOpwZNK2p8g@mail.gmail.com>

On 4/23/15, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
> Hello,
>

Hi Iavor,

> Apologies if my changes caused difficulties with your work---we made the
> changes to `Typable` to preserve the soundness of the type system,
> hopefully the new behavior is exactly equivalent to the old in the safe
> cases.

No need to apologize, I chose this way to be able to intervene fast
when something breaks :-) The old behaviour might have been unsafe,
though I cannot see why.

>
> Could you post an example of the code where the unwanted `Typeable p`
> constraint appears?  It seems entirely reasonable that if you want to solve
> `Typeable (OUT p o)`, you'll have to provide `Typealbe p`, so I am not
> seeing the whole picture.

Here is a small example where an additional constraint surfaces:

------------------------------------------------------------------------------
{-# LANGUAGE AutoDeriveTypeable, GADTs, DataKinds, KindSignatures,
StandaloneDeriving #-}

import GHC.TypeLits
import Data.Typeable

data Foo (n :: Nat) where
  Hey :: KnownNat n => Foo n

deriving instance Show (Foo n)

data T t where
  T :: (Show t, Typeable t) => t -> T t

deriving instance Show (T n)

{-

-------------------  WITH ghci-7.11.20150407 (and newer)
*Main> :t T Hey
T Hey :: (Typeable n, KnownNat n) => T (Foo n)

-------------------  WITH ghci-7.11.20150215 (old)
*Main> :t T Hey
T Hey :: KnownNat n => T (Foo n)

-}
------------------------------------------------------------------------------


>
> To answer your question about `KnownNat p`---there is no relation between
> it and `Typeable`.   You may think if a `KnownNat x` constraint as just the
> integer `x`.  As it happens, the integer is closely related to the
> `Typeable` instance for the number, so I think we *could* make it work so

Yes, this relation I was alluding to.

> that if you have `KnownNat p`, then you can get `Typeable p`, but this has
> never worked previosly, so perhaps there is another issue.

Maybe with my example from above it might be easier to debug it.

>
> -Iavor

Thanks,

    Gabor

>
>
>
> On Thu, Apr 23, 2015 at 7:04 AM, Gabor Greif <ggreif at gmail.com> wrote:
>
>> Hi devs,
>>
>> between ghc-7.11.20150215 and ghc-7.11.20150407 I experienced a
>> strange regression with deriving Typeable for data with Nat-kinded
>> indices.
>>
>> Something like this used to work (I cannot post the whole thing,
>> unfortunately)
>>
>> {{{
>> data OTU (p :: Nat) (o :: Nat) = OTU { ...fields... } deriving (Show,
>> Typeable)
>> }}}
>>
>> With my ghc-7.11.20150407 (and later) strange obligations of the form
>> `Typeable p` appear, rendering my code uncompilable. But there is no
>> way I can see how I can convince the type checker that the Nat index
>> is indeed Typeable. I *do* have a `KnownNat p` constraint around,
>> though.
>>
>> The relevant changes to mainline appear to be
>> https://github.com/ghc/ghc/commit/b359c886cd7578ed083bcedcea05d315ecaeeb54
>> https://github.com/ghc/ghc/commit/3a0019e3672097761e7ce09c811018f774febfd2
>>
>> both by Iavor.
>>
>> So now my questions:
>>
>> 1) Is this a regression on mainline? (I surely hope so!) How did this
>> work before?
>> 2) Should `KnownNat p` imply `Typeable p` for the ability to have my
>> `Typeable (OTU p o)`
>> 3) if 2) is answered with "NO", how am I supposed to satisfy those
>> constraints?
>>
>> Thanks and cheers,
>>
>>     Gabor
>>
>>
>> PS: Sometimes I feel like a canary doing my research-like programming
>> with GHC-HEAD, and it is a mostly positive experience, but events like
>> this make me shiver...
>>
>

From iavor.diatchki at gmail.com  Thu Apr 23 16:59:04 2015
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Thu, 23 Apr 2015 09:59:04 -0700
Subject: deriving Typeable and Nat kinds
In-Reply-To: <CAK-hX0nKbcnQrP0Au0ySQ9uDOqNn=27J4xkLRTPPOpwZNK2p8g@mail.gmail.com>
References: <CAK-hX0kFGEHrWEKR6g1qzn0nqj9E9O35LzpA0V5_nEha2U=QMQ@mail.gmail.com>
 <CAGK9nuqk7x3B_UxZwB0Du5Bxidc0iO7TxBMnXgLQji2bS55s6w@mail.gmail.com>
 <CAK-hX0nKbcnQrP0Au0ySQ9uDOqNn=27J4xkLRTPPOpwZNK2p8g@mail.gmail.com>
Message-ID: <CAGK9nuoGyOZuBS3xDeBKVhvGyvzYKy5ADgGQtA+ZAxtKm98uKA@mail.gmail.com>

Aha, I see what happened.  What I said before was wrong---indeed the
`Typeable` instance for type-nats (and symbols) used to be implemented in
terms of `KnownNat` and `KnownSymbol`:

instance KnownNat n => Typeable (n :: Nat) where ...

When I updated the `Typeable` solver, I forgot about that special
case---I'll have a go at a fix.

-Iavor




On Thu, Apr 23, 2015 at 8:37 AM, Gabor Greif <ggreif at gmail.com> wrote:

> On 4/23/15, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
> > Hello,
> >
>
> Hi Iavor,
>
> > Apologies if my changes caused difficulties with your work---we made the
> > changes to `Typable` to preserve the soundness of the type system,
> > hopefully the new behavior is exactly equivalent to the old in the safe
> > cases.
>
> No need to apologize, I chose this way to be able to intervene fast
> when something breaks :-) The old behaviour might have been unsafe,
> though I cannot see why.
>
> >
> > Could you post an example of the code where the unwanted `Typeable p`
> > constraint appears?  It seems entirely reasonable that if you want to
> solve
> > `Typeable (OUT p o)`, you'll have to provide `Typealbe p`, so I am not
> > seeing the whole picture.
>
> Here is a small example where an additional constraint surfaces:
>
>
> ------------------------------------------------------------------------------
> {-# LANGUAGE AutoDeriveTypeable, GADTs, DataKinds, KindSignatures,
> StandaloneDeriving #-}
>
> import GHC.TypeLits
> import Data.Typeable
>
> data Foo (n :: Nat) where
>   Hey :: KnownNat n => Foo n
>
> deriving instance Show (Foo n)
>
> data T t where
>   T :: (Show t, Typeable t) => t -> T t
>
> deriving instance Show (T n)
>
> {-
>
> -------------------  WITH ghci-7.11.20150407 (and newer)
> *Main> :t T Hey
> T Hey :: (Typeable n, KnownNat n) => T (Foo n)
>
> -------------------  WITH ghci-7.11.20150215 (old)
> *Main> :t T Hey
> T Hey :: KnownNat n => T (Foo n)
>
> -}
>
> ------------------------------------------------------------------------------
>
>
> >
> > To answer your question about `KnownNat p`---there is no relation between
> > it and `Typeable`.   You may think if a `KnownNat x` constraint as just
> the
> > integer `x`.  As it happens, the integer is closely related to the
> > `Typeable` instance for the number, so I think we *could* make it work so
>
> Yes, this relation I was alluding to.
>
> > that if you have `KnownNat p`, then you can get `Typeable p`, but this
> has
> > never worked previosly, so perhaps there is another issue.
>
> Maybe with my example from above it might be easier to debug it.
>
> >
> > -Iavor
>
> Thanks,
>
>     Gabor
>
> >
> >
> >
> > On Thu, Apr 23, 2015 at 7:04 AM, Gabor Greif <ggreif at gmail.com> wrote:
> >
> >> Hi devs,
> >>
> >> between ghc-7.11.20150215 and ghc-7.11.20150407 I experienced a
> >> strange regression with deriving Typeable for data with Nat-kinded
> >> indices.
> >>
> >> Something like this used to work (I cannot post the whole thing,
> >> unfortunately)
> >>
> >> {{{
> >> data OTU (p :: Nat) (o :: Nat) = OTU { ...fields... } deriving (Show,
> >> Typeable)
> >> }}}
> >>
> >> With my ghc-7.11.20150407 (and later) strange obligations of the form
> >> `Typeable p` appear, rendering my code uncompilable. But there is no
> >> way I can see how I can convince the type checker that the Nat index
> >> is indeed Typeable. I *do* have a `KnownNat p` constraint around,
> >> though.
> >>
> >> The relevant changes to mainline appear to be
> >>
> https://github.com/ghc/ghc/commit/b359c886cd7578ed083bcedcea05d315ecaeeb54
> >>
> https://github.com/ghc/ghc/commit/3a0019e3672097761e7ce09c811018f774febfd2
> >>
> >> both by Iavor.
> >>
> >> So now my questions:
> >>
> >> 1) Is this a regression on mainline? (I surely hope so!) How did this
> >> work before?
> >> 2) Should `KnownNat p` imply `Typeable p` for the ability to have my
> >> `Typeable (OTU p o)`
> >> 3) if 2) is answered with "NO", how am I supposed to satisfy those
> >> constraints?
> >>
> >> Thanks and cheers,
> >>
> >>     Gabor
> >>
> >>
> >> PS: Sometimes I feel like a canary doing my research-like programming
> >> with GHC-HEAD, and it is a mostly positive experience, but events like
> >> this make me shiver...
> >>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150423/09a7345b/attachment.html>

From iavor.diatchki at gmail.com  Thu Apr 23 17:00:07 2015
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Thu, 23 Apr 2015 10:00:07 -0700
Subject: deriving Typeable and Nat kinds
In-Reply-To: <CAGK9nuoGyOZuBS3xDeBKVhvGyvzYKy5ADgGQtA+ZAxtKm98uKA@mail.gmail.com>
References: <CAK-hX0kFGEHrWEKR6g1qzn0nqj9E9O35LzpA0V5_nEha2U=QMQ@mail.gmail.com>
 <CAGK9nuqk7x3B_UxZwB0Du5Bxidc0iO7TxBMnXgLQji2bS55s6w@mail.gmail.com>
 <CAK-hX0nKbcnQrP0Au0ySQ9uDOqNn=27J4xkLRTPPOpwZNK2p8g@mail.gmail.com>
 <CAGK9nuoGyOZuBS3xDeBKVhvGyvzYKy5ADgGQtA+ZAxtKm98uKA@mail.gmail.com>
Message-ID: <CAGK9nup+QqxUzgp=H54tWY+UudWwi2JSiGH-mnG2OeogGBV60A@mail.gmail.com>

Could you please make a ticket for this, so that we have a reference and it
does not get lost?

On Thu, Apr 23, 2015 at 9:59 AM, Iavor Diatchki <iavor.diatchki at gmail.com>
wrote:

> Aha, I see what happened.  What I said before was wrong---indeed the
> `Typeable` instance for type-nats (and symbols) used to be implemented in
> terms of `KnownNat` and `KnownSymbol`:
>
> instance KnownNat n => Typeable (n :: Nat) where ...
>
> When I updated the `Typeable` solver, I forgot about that special
> case---I'll have a go at a fix.
>
> -Iavor
>
>
>
>
> On Thu, Apr 23, 2015 at 8:37 AM, Gabor Greif <ggreif at gmail.com> wrote:
>
>> On 4/23/15, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
>> > Hello,
>> >
>>
>> Hi Iavor,
>>
>> > Apologies if my changes caused difficulties with your work---we made the
>> > changes to `Typable` to preserve the soundness of the type system,
>> > hopefully the new behavior is exactly equivalent to the old in the safe
>> > cases.
>>
>> No need to apologize, I chose this way to be able to intervene fast
>> when something breaks :-) The old behaviour might have been unsafe,
>> though I cannot see why.
>>
>> >
>> > Could you post an example of the code where the unwanted `Typeable p`
>> > constraint appears?  It seems entirely reasonable that if you want to
>> solve
>> > `Typeable (OUT p o)`, you'll have to provide `Typealbe p`, so I am not
>> > seeing the whole picture.
>>
>> Here is a small example where an additional constraint surfaces:
>>
>>
>> ------------------------------------------------------------------------------
>> {-# LANGUAGE AutoDeriveTypeable, GADTs, DataKinds, KindSignatures,
>> StandaloneDeriving #-}
>>
>> import GHC.TypeLits
>> import Data.Typeable
>>
>> data Foo (n :: Nat) where
>>   Hey :: KnownNat n => Foo n
>>
>> deriving instance Show (Foo n)
>>
>> data T t where
>>   T :: (Show t, Typeable t) => t -> T t
>>
>> deriving instance Show (T n)
>>
>> {-
>>
>> -------------------  WITH ghci-7.11.20150407 (and newer)
>> *Main> :t T Hey
>> T Hey :: (Typeable n, KnownNat n) => T (Foo n)
>>
>> -------------------  WITH ghci-7.11.20150215 (old)
>> *Main> :t T Hey
>> T Hey :: KnownNat n => T (Foo n)
>>
>> -}
>>
>> ------------------------------------------------------------------------------
>>
>>
>> >
>> > To answer your question about `KnownNat p`---there is no relation
>> between
>> > it and `Typeable`.   You may think if a `KnownNat x` constraint as just
>> the
>> > integer `x`.  As it happens, the integer is closely related to the
>> > `Typeable` instance for the number, so I think we *could* make it work
>> so
>>
>> Yes, this relation I was alluding to.
>>
>> > that if you have `KnownNat p`, then you can get `Typeable p`, but this
>> has
>> > never worked previosly, so perhaps there is another issue.
>>
>> Maybe with my example from above it might be easier to debug it.
>>
>> >
>> > -Iavor
>>
>> Thanks,
>>
>>     Gabor
>>
>> >
>> >
>> >
>> > On Thu, Apr 23, 2015 at 7:04 AM, Gabor Greif <ggreif at gmail.com> wrote:
>> >
>> >> Hi devs,
>> >>
>> >> between ghc-7.11.20150215 and ghc-7.11.20150407 I experienced a
>> >> strange regression with deriving Typeable for data with Nat-kinded
>> >> indices.
>> >>
>> >> Something like this used to work (I cannot post the whole thing,
>> >> unfortunately)
>> >>
>> >> {{{
>> >> data OTU (p :: Nat) (o :: Nat) = OTU { ...fields... } deriving (Show,
>> >> Typeable)
>> >> }}}
>> >>
>> >> With my ghc-7.11.20150407 (and later) strange obligations of the form
>> >> `Typeable p` appear, rendering my code uncompilable. But there is no
>> >> way I can see how I can convince the type checker that the Nat index
>> >> is indeed Typeable. I *do* have a `KnownNat p` constraint around,
>> >> though.
>> >>
>> >> The relevant changes to mainline appear to be
>> >>
>> https://github.com/ghc/ghc/commit/b359c886cd7578ed083bcedcea05d315ecaeeb54
>> >>
>> https://github.com/ghc/ghc/commit/3a0019e3672097761e7ce09c811018f774febfd2
>> >>
>> >> both by Iavor.
>> >>
>> >> So now my questions:
>> >>
>> >> 1) Is this a regression on mainline? (I surely hope so!) How did this
>> >> work before?
>> >> 2) Should `KnownNat p` imply `Typeable p` for the ability to have my
>> >> `Typeable (OTU p o)`
>> >> 3) if 2) is answered with "NO", how am I supposed to satisfy those
>> >> constraints?
>> >>
>> >> Thanks and cheers,
>> >>
>> >>     Gabor
>> >>
>> >>
>> >> PS: Sometimes I feel like a canary doing my research-like programming
>> >> with GHC-HEAD, and it is a mostly positive experience, but events like
>> >> this make me shiver...
>> >>
>> >
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150423/7f92a5a2/attachment-0001.html>

From ggreif at gmail.com  Thu Apr 23 17:19:30 2015
From: ggreif at gmail.com (Gabor Greif)
Date: Thu, 23 Apr 2015 19:19:30 +0200
Subject: deriving Typeable and Nat kinds
In-Reply-To: <CAGK9nup+QqxUzgp=H54tWY+UudWwi2JSiGH-mnG2OeogGBV60A@mail.gmail.com>
References: <CAK-hX0kFGEHrWEKR6g1qzn0nqj9E9O35LzpA0V5_nEha2U=QMQ@mail.gmail.com>
 <CAGK9nuqk7x3B_UxZwB0Du5Bxidc0iO7TxBMnXgLQji2bS55s6w@mail.gmail.com>
 <CAK-hX0nKbcnQrP0Au0ySQ9uDOqNn=27J4xkLRTPPOpwZNK2p8g@mail.gmail.com>
 <CAGK9nuoGyOZuBS3xDeBKVhvGyvzYKy5ADgGQtA+ZAxtKm98uKA@mail.gmail.com>
 <CAGK9nup+QqxUzgp=H54tWY+UudWwi2JSiGH-mnG2OeogGBV60A@mail.gmail.com>
Message-ID: <CAK-hX0=77cMHKLh5cRpEop83cjCr3NNaR8=qiNBpjmPFu7ebiQ@mail.gmail.com>

Here you go: https://ghc.haskell.org/trac/ghc/ticket/10348

Thanks for looking into this!

Cheers,

    Gabor

On 4/23/15, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
> Could you please make a ticket for this, so that we have a reference and it
> does not get lost?
>
> On Thu, Apr 23, 2015 at 9:59 AM, Iavor Diatchki <iavor.diatchki at gmail.com>
> wrote:
>
>> Aha, I see what happened.  What I said before was wrong---indeed the
>> `Typeable` instance for type-nats (and symbols) used to be implemented in
>> terms of `KnownNat` and `KnownSymbol`:
>>
>> instance KnownNat n => Typeable (n :: Nat) where ...
>>
>> When I updated the `Typeable` solver, I forgot about that special
>> case---I'll have a go at a fix.
>>
>> -Iavor
>>
>>
>>
>>
>> On Thu, Apr 23, 2015 at 8:37 AM, Gabor Greif <ggreif at gmail.com> wrote:
>>
>>> On 4/23/15, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
>>> > Hello,
>>> >
>>>
>>> Hi Iavor,
>>>
>>> > Apologies if my changes caused difficulties with your work---we made
>>> > the
>>> > changes to `Typable` to preserve the soundness of the type system,
>>> > hopefully the new behavior is exactly equivalent to the old in the
>>> > safe
>>> > cases.
>>>
>>> No need to apologize, I chose this way to be able to intervene fast
>>> when something breaks :-) The old behaviour might have been unsafe,
>>> though I cannot see why.
>>>
>>> >
>>> > Could you post an example of the code where the unwanted `Typeable p`
>>> > constraint appears?  It seems entirely reasonable that if you want to
>>> solve
>>> > `Typeable (OUT p o)`, you'll have to provide `Typealbe p`, so I am not
>>> > seeing the whole picture.
>>>
>>> Here is a small example where an additional constraint surfaces:
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> {-# LANGUAGE AutoDeriveTypeable, GADTs, DataKinds, KindSignatures,
>>> StandaloneDeriving #-}
>>>
>>> import GHC.TypeLits
>>> import Data.Typeable
>>>
>>> data Foo (n :: Nat) where
>>>   Hey :: KnownNat n => Foo n
>>>
>>> deriving instance Show (Foo n)
>>>
>>> data T t where
>>>   T :: (Show t, Typeable t) => t -> T t
>>>
>>> deriving instance Show (T n)
>>>
>>> {-
>>>
>>> -------------------  WITH ghci-7.11.20150407 (and newer)
>>> *Main> :t T Hey
>>> T Hey :: (Typeable n, KnownNat n) => T (Foo n)
>>>
>>> -------------------  WITH ghci-7.11.20150215 (old)
>>> *Main> :t T Hey
>>> T Hey :: KnownNat n => T (Foo n)
>>>
>>> -}
>>>
>>> ------------------------------------------------------------------------------
>>>
>>>
>>> >
>>> > To answer your question about `KnownNat p`---there is no relation
>>> between
>>> > it and `Typeable`.   You may think if a `KnownNat x` constraint as
>>> > just
>>> the
>>> > integer `x`.  As it happens, the integer is closely related to the
>>> > `Typeable` instance for the number, so I think we *could* make it work
>>> so
>>>
>>> Yes, this relation I was alluding to.
>>>
>>> > that if you have `KnownNat p`, then you can get `Typeable p`, but this
>>> has
>>> > never worked previosly, so perhaps there is another issue.
>>>
>>> Maybe with my example from above it might be easier to debug it.
>>>
>>> >
>>> > -Iavor
>>>
>>> Thanks,
>>>
>>>     Gabor
>>>
>>> >
>>> >
>>> >
>>> > On Thu, Apr 23, 2015 at 7:04 AM, Gabor Greif <ggreif at gmail.com> wrote:
>>> >
>>> >> Hi devs,
>>> >>
>>> >> between ghc-7.11.20150215 and ghc-7.11.20150407 I experienced a
>>> >> strange regression with deriving Typeable for data with Nat-kinded
>>> >> indices.
>>> >>
>>> >> Something like this used to work (I cannot post the whole thing,
>>> >> unfortunately)
>>> >>
>>> >> {{{
>>> >> data OTU (p :: Nat) (o :: Nat) = OTU { ...fields... } deriving (Show,
>>> >> Typeable)
>>> >> }}}
>>> >>
>>> >> With my ghc-7.11.20150407 (and later) strange obligations of the form
>>> >> `Typeable p` appear, rendering my code uncompilable. But there is no
>>> >> way I can see how I can convince the type checker that the Nat index
>>> >> is indeed Typeable. I *do* have a `KnownNat p` constraint around,
>>> >> though.
>>> >>
>>> >> The relevant changes to mainline appear to be
>>> >>
>>> https://github.com/ghc/ghc/commit/b359c886cd7578ed083bcedcea05d315ecaeeb54
>>> >>
>>> https://github.com/ghc/ghc/commit/3a0019e3672097761e7ce09c811018f774febfd2
>>> >>
>>> >> both by Iavor.
>>> >>
>>> >> So now my questions:
>>> >>
>>> >> 1) Is this a regression on mainline? (I surely hope so!) How did this
>>> >> work before?
>>> >> 2) Should `KnownNat p` imply `Typeable p` for the ability to have my
>>> >> `Typeable (OTU p o)`
>>> >> 3) if 2) is answered with "NO", how am I supposed to satisfy those
>>> >> constraints?
>>> >>
>>> >> Thanks and cheers,
>>> >>
>>> >>     Gabor
>>> >>
>>> >>
>>> >> PS: Sometimes I feel like a canary doing my research-like programming
>>> >> with GHC-HEAD, and it is a mostly positive experience, but events
>>> >> like
>>> >> this make me shiver...
>>> >>
>>> >
>>>
>>
>>
>

From carter.schonwald at gmail.com  Thu Apr 23 20:03:06 2015
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Thu, 23 Apr 2015 16:03:06 -0400
Subject: validate failures for OSX on current head
Message-ID: <CAHYVw0xwaPROjqgN=fjmsyc8qtUp6+J86U2mLzPY5Q6x9Agrmw@mail.gmail.com>

hey all, on ghc head today
specifically commit a55bfabbed21f17064f863450f9d94d45db9c478
i did a run of ./validate --slow

here are the following unexpected failures (i know the static pointer GHCI
ones are expected, but i'm not sure about the rest). Could someone care to
opine on which ones are truely unexpected?

i'll be doing a bit of digging on some of these as I have time over the
coming week, but i thought I should share this with everyone just in case
something important is amidst them

cheers
-Carter


Unexpected results from:
TEST="tc165 retc001 dsrun014 DsStaticPointers GcStaticPointers
ListStaticPointers T7919 retc002 tcrun024 tcrun025 T7861 T5751 T3500a T7126
tcrun037 readRun004 rn041 TH_StaticPointers recomp001 setnumcapabilities001
allocLimit4 ghci024 termination enum01 enum03 enum02 sigcabal01 sigcabal02
CgStaticPointers recomp014 qq007 qq008 mul2 quotRem2 add2 read029"

OVERALL SUMMARY for test run started at Thu Apr 23 15:02:33 2015 EDT
 0:20:10 spent to go through
    4483 total tests, which gave rise to
   14464 test cases, of which
    2785 were skipped

     267 had missing libraries
   11140 expected passes
     170 expected failures

       0 caused framework failures
       0 unexpected passes
     102 unexpected failures
       0 unexpected stat failures

Unexpected failures:
   ../../libraries/base/tests  enum01 [exit code non-0]
(normal,hpc,optasm,threaded1,threaded2,dyn)
   ../../libraries/base/tests  enum01 [bad stdout or stderr] (ghci)
   ../../libraries/base/tests  enum02 [exit code non-0]
(normal,hpc,optasm,threaded1,threaded2,dyn)
   ../../libraries/base/tests  enum02 [bad stdout or stderr] (ghci)
   ../../libraries/base/tests  enum03 [exit code non-0]
(normal,hpc,optasm,threaded1,threaded2,dyn)
   ../../libraries/base/tests  enum03 [bad stdout or stderr] (ghci)
   cabal/sigcabal01            sigcabal01 [bad stderr] (normal)
   cabal/sigcabal02            sigcabal02 [bad stderr] (normal)
   codeGen/should_run          CgStaticPointers [bad stdout or stderr]
(ghci)
   concurrent/should_run       allocLimit4 [bad exit code] (ghci)
   concurrent/should_run       setnumcapabilities001 [bad exit code]
(threaded2)
   deSugar/should_run          DsStaticPointers [bad stdout or stderr]
(ghci)
   deSugar/should_run          dsrun014 [bad exit code] (ghci)
   driver/recomp001            recomp001 [bad stderr] (normal)
   driver/recomp014            recomp014 [bad stdout] (normal)
   driver/retc001              retc001 [bad exit code] (normal)
   driver/retc002              retc002 [bad exit code] (normal)
   gadt                        termination [exit code non-0] (optasm)
   ghci/scripts                ghci024 [bad stdout] (normal)
   numeric/should_run          add2 [bad exit code] (ghci)
   numeric/should_run          mul2 [bad exit code] (ghci)
   numeric/should_run          quotRem2 [bad exit code] (ghci)
   parser/should_compile       read029 [exit code non-0] (optasm)
   parser/should_run           readRun004 [bad exit code] (ghci)
   quasiquotation/qq007        qq007 [exit code non-0] (normal,hpc,optasm)
   quasiquotation/qq008        qq008 [exit code non-0] (normal,hpc,optasm)
   rename/should_compile       rn041 [exit code non-0] (optasm)
   rts                         GcStaticPointers [bad stdout or stderr]
(ghci)
   rts                         ListStaticPointers [bad stdout or stderr]
(ghci)
   rts                         T7919 [bad exit code] (optasm,threaded1,dyn)
   th                          TH_StaticPointers [bad stdout or stderr]
(ghci)
   typecheck/should_compile    tc165 [exit code non-0] (optasm)
   typecheck/should_run        T3500a [exit code non-0]
(normal,hpc,optasm,threaded1,threaded2,dyn)
   typecheck/should_run        T3500a [bad stdout or stderr] (ghci)
   typecheck/should_run        T5751 [exit code non-0]
(normal,hpc,optasm,threaded1,threaded2,dyn)
   typecheck/should_run        T5751 [bad stdout or stderr] (ghci)
   typecheck/should_run        T7126 [exit code non-0]
(normal,hpc,optasm,threaded1,threaded2,dyn)
   typecheck/should_run        T7126 [bad stdout or stderr] (ghci)
   typecheck/should_run        T7861 [bad stderr]
(normal,hpc,optasm,threaded1,threaded2,dyn)
   typecheck/should_run        T7861 [bad stdout or stderr] (ghci)
   typecheck/should_run        tcrun024 [exit code non-0]
(normal,hpc,optasm,threaded1,threaded2,dyn)
   typecheck/should_run        tcrun024 [bad stdout or stderr] (ghci)
   typecheck/should_run        tcrun025 [exit code non-0]
(normal,hpc,optasm,threaded1,threaded2,dyn)
   typecheck/should_run        tcrun025 [bad stdout or stderr] (ghci)
   typecheck/should_run        tcrun037 [exit code non-0]
(normal,hpc,optasm,threaded1,threaded2,dyn)
   typecheck/should_run        tcrun037 [bad stdout or stderr] (ghci)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150423/038b2eb9/attachment.html>

From ezyang at mit.edu  Fri Apr 24 13:54:41 2015
From: ezyang at mit.edu (Edward Z. Yang)
Date: Fri, 24 Apr 2015 14:54:41 +0100
Subject: Can we fix our Trac that doesn't lose new ticket text
Message-ID: <1429883680-sup-8002@sabre>

Steps to reproduce:

1. Click "New Ticket"
2. Type some text into the box
3. Press "Back" in your browser
4. Press "Forward" in your browser

If you try this with an official Trac this doesn't happen, so either
this was fixed in a new version, or we have a plugin installed which
is causing this to happen.

Current version of Trac is 1.0.5, we're currently running 1.0.1

Thanks,
Edward

From ecrockett0 at gmail.com  Fri Apr 24 14:02:35 2015
From: ecrockett0 at gmail.com (Eric Crockett)
Date: Fri, 24 Apr 2015 10:02:35 -0400
Subject: Can we fix our Trac that doesn't lose new ticket text
In-Reply-To: <1429883680-sup-8002@sabre>
References: <1429883680-sup-8002@sabre>
Message-ID: <CAApao_==6m770eihH035TWGyYHrP9gGUWdBfBWMUr3xnSuxNTQ@mail.gmail.com>

On the contrary, I did precisely that just a few days ago (
https://ghc.haskell.org/trac/ghc/ticket/10338), and to my surprise, trac
*did* save my new ticket text. Perhaps this is a browser-specific issue?
I'm using 64-bit Chrome 42.0.2311.90.

On Fri, Apr 24, 2015 at 9:54 AM, Edward Z. Yang <ezyang at mit.edu> wrote:

> Steps to reproduce:
>
> 1. Click "New Ticket"
> 2. Type some text into the box
> 3. Press "Back" in your browser
> 4. Press "Forward" in your browser
>
> If you try this with an official Trac this doesn't happen, so either
> this was fixed in a new version, or we have a plugin installed which
> is causing this to happen.
>
> Current version of Trac is 1.0.5, we're currently running 1.0.1
>
> Thanks,
> Edward
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150424/c430e6d5/attachment.html>

From ggreif at gmail.com  Fri Apr 24 14:04:55 2015
From: ggreif at gmail.com (Gabor Greif)
Date: Fri, 24 Apr 2015 16:04:55 +0200
Subject: Can we fix our Trac that doesn't lose new ticket text
In-Reply-To: <CAApao_==6m770eihH035TWGyYHrP9gGUWdBfBWMUr3xnSuxNTQ@mail.gmail.com>
References: <1429883680-sup-8002@sabre>
 <CAApao_==6m770eihH035TWGyYHrP9gGUWdBfBWMUr3xnSuxNTQ@mail.gmail.com>
Message-ID: <CAK-hX0kPa4JGGXQ6RP9q1xLoUGMstem8F3uEc3_tD0vH5wEgJA@mail.gmail.com>

On 4/24/15, Eric Crockett <ecrockett0 at gmail.com> wrote:
> On the contrary, I did precisely that just a few days ago (
> https://ghc.haskell.org/trac/ghc/ticket/10338), and to my surprise, trac
> *did* save my new ticket text. Perhaps this is a browser-specific issue?
> I'm using 64-bit Chrome 42.0.2311.90.

With a recent Firefox, I lost the text by clicking into "Formatting
Hints" and surfing back. I was not amused.

Cheers,

    Gabor

>
> On Fri, Apr 24, 2015 at 9:54 AM, Edward Z. Yang <ezyang at mit.edu> wrote:
>
>> Steps to reproduce:
>>
>> 1. Click "New Ticket"
>> 2. Type some text into the box
>> 3. Press "Back" in your browser
>> 4. Press "Forward" in your browser
>>
>> If you try this with an official Trac this doesn't happen, so either
>> this was fixed in a new version, or we have a plugin installed which
>> is causing this to happen.
>>
>> Current version of Trac is 1.0.5, we're currently running 1.0.1
>>
>> Thanks,
>> Edward
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>

From ezyang at mit.edu  Fri Apr 24 14:07:26 2015
From: ezyang at mit.edu (Edward Z. Yang)
Date: Fri, 24 Apr 2015 15:07:26 +0100
Subject: Can we fix our Trac that doesn't lose new ticket text
In-Reply-To: <CAApao_==6m770eihH035TWGyYHrP9gGUWdBfBWMUr3xnSuxNTQ@mail.gmail.com>
References: <1429883680-sup-8002@sabre>
 <CAApao_==6m770eihH035TWGyYHrP9gGUWdBfBWMUr3xnSuxNTQ@mail.gmail.com>
Message-ID: <1429884427-sup-5668@sabre>

Whatever the case, it affects me, it affects SPJ, so we ought to fix it!
(Change your browser is not a good answer :)

Edward

Excerpts from Eric Crockett's message of 2015-04-24 15:02:35 +0100:
> On the contrary, I did precisely that just a few days ago (
> https://ghc.haskell.org/trac/ghc/ticket/10338), and to my surprise, trac
> *did* save my new ticket text. Perhaps this is a browser-specific issue?
> I'm using 64-bit Chrome 42.0.2311.90.
> 
> On Fri, Apr 24, 2015 at 9:54 AM, Edward Z. Yang <ezyang at mit.edu> wrote:
> 
> > Steps to reproduce:
> >
> > 1. Click "New Ticket"
> > 2. Type some text into the box
> > 3. Press "Back" in your browser
> > 4. Press "Forward" in your browser
> >
> > If you try this with an official Trac this doesn't happen, so either
> > this was fixed in a new version, or we have a plugin installed which
> > is causing this to happen.
> >
> > Current version of Trac is 1.0.5, we're currently running 1.0.1
> >
> > Thanks,
> > Edward
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >

From ecrockett0 at gmail.com  Fri Apr 24 14:13:07 2015
From: ecrockett0 at gmail.com (Eric Crockett)
Date: Fri, 24 Apr 2015 10:13:07 -0400
Subject: Can we fix our Trac that doesn't lose new ticket text
In-Reply-To: <1429884427-sup-5668@sabre>
References: <1429883680-sup-8002@sabre>
 <CAApao_==6m770eihH035TWGyYHrP9gGUWdBfBWMUr3xnSuxNTQ@mail.gmail.com>
 <1429884427-sup-5668@sabre>
Message-ID: <CAApao_kEXJEgqbeqnOCeTrGrFbFYg30B-5OeDLt_-4SpbDn5hg@mail.gmail.com>

My Firefox also has this issue. So it seems the problem is the browser
itself. How can this be fixed on the server side?

On Fri, Apr 24, 2015 at 10:07 AM, Edward Z. Yang <ezyang at mit.edu> wrote:

> Whatever the case, it affects me, it affects SPJ, so we ought to fix it!
> (Change your browser is not a good answer :)
>
> Edward
>
> Excerpts from Eric Crockett's message of 2015-04-24 15:02:35 +0100:
> > On the contrary, I did precisely that just a few days ago (
> > https://ghc.haskell.org/trac/ghc/ticket/10338), and to my surprise, trac
> > *did* save my new ticket text. Perhaps this is a browser-specific issue?
> > I'm using 64-bit Chrome 42.0.2311.90.
> >
> > On Fri, Apr 24, 2015 at 9:54 AM, Edward Z. Yang <ezyang at mit.edu> wrote:
> >
> > > Steps to reproduce:
> > >
> > > 1. Click "New Ticket"
> > > 2. Type some text into the box
> > > 3. Press "Back" in your browser
> > > 4. Press "Forward" in your browser
> > >
> > > If you try this with an official Trac this doesn't happen, so either
> > > this was fixed in a new version, or we have a plugin installed which
> > > is causing this to happen.
> > >
> > > Current version of Trac is 1.0.5, we're currently running 1.0.1
> > >
> > > Thanks,
> > > Edward
> > > _______________________________________________
> > > ghc-devs mailing list
> > > ghc-devs at haskell.org
> > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> > >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150424/5fc4d0c1/attachment.html>

From fryguybob at gmail.com  Fri Apr 24 14:15:37 2015
From: fryguybob at gmail.com (Ryan Yates)
Date: Fri, 24 Apr 2015 10:15:37 -0400
Subject: Can we fix our Trac that doesn't lose new ticket text
In-Reply-To: <CAApao_kEXJEgqbeqnOCeTrGrFbFYg30B-5OeDLt_-4SpbDn5hg@mail.gmail.com>
References: <1429883680-sup-8002@sabre>
 <CAApao_==6m770eihH035TWGyYHrP9gGUWdBfBWMUr3xnSuxNTQ@mail.gmail.com>
 <1429884427-sup-5668@sabre>
 <CAApao_kEXJEgqbeqnOCeTrGrFbFYg30B-5OeDLt_-4SpbDn5hg@mail.gmail.com>
Message-ID: <CAO27hRrLkjX84yLjaWQk-b8p-LdoGJ+b6fM4=_uWZ1iFLnZ80A@mail.gmail.com>

My very pessimistic rule of thumb is don't trust a form field unless the
site actively saves a draft as you type.

On Fri, Apr 24, 2015 at 10:13 AM, Eric Crockett <ecrockett0 at gmail.com>
wrote:

> My Firefox also has this issue. So it seems the problem is the browser
> itself. How can this be fixed on the server side?
>
> On Fri, Apr 24, 2015 at 10:07 AM, Edward Z. Yang <ezyang at mit.edu> wrote:
>
>> Whatever the case, it affects me, it affects SPJ, so we ought to fix it!
>> (Change your browser is not a good answer :)
>>
>> Edward
>>
>> Excerpts from Eric Crockett's message of 2015-04-24 15:02:35 +0100:
>> > On the contrary, I did precisely that just a few days ago (
>> > https://ghc.haskell.org/trac/ghc/ticket/10338), and to my surprise,
>> trac
>> > *did* save my new ticket text. Perhaps this is a browser-specific issue?
>> > I'm using 64-bit Chrome 42.0.2311.90.
>> >
>> > On Fri, Apr 24, 2015 at 9:54 AM, Edward Z. Yang <ezyang at mit.edu> wrote:
>> >
>> > > Steps to reproduce:
>> > >
>> > > 1. Click "New Ticket"
>> > > 2. Type some text into the box
>> > > 3. Press "Back" in your browser
>> > > 4. Press "Forward" in your browser
>> > >
>> > > If you try this with an official Trac this doesn't happen, so either
>> > > this was fixed in a new version, or we have a plugin installed which
>> > > is causing this to happen.
>> > >
>> > > Current version of Trac is 1.0.5, we're currently running 1.0.1
>> > >
>> > > Thanks,
>> > > Edward
>> > > _______________________________________________
>> > > ghc-devs mailing list
>> > > ghc-devs at haskell.org
>> > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> > >
>>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150424/7de961a9/attachment.html>

From ezyang at mit.edu  Fri Apr 24 14:20:35 2015
From: ezyang at mit.edu (Edward Z. Yang)
Date: Fri, 24 Apr 2015 15:20:35 +0100
Subject: Can we fix our Trac that doesn't lose new ticket text
In-Reply-To: <CAO27hRrLkjX84yLjaWQk-b8p-LdoGJ+b6fM4=_uWZ1iFLnZ80A@mail.gmail.com>
References: <1429883680-sup-8002@sabre>
 <CAApao_==6m770eihH035TWGyYHrP9gGUWdBfBWMUr3xnSuxNTQ@mail.gmail.com>
 <1429884427-sup-5668@sabre>
 <CAApao_kEXJEgqbeqnOCeTrGrFbFYg30B-5OeDLt_-4SpbDn5hg@mail.gmail.com>
 <CAO27hRrLkjX84yLjaWQk-b8p-LdoGJ+b6fM4=_uWZ1iFLnZ80A@mail.gmail.com>
Message-ID: <1429885203-sup-4704@sabre>

I've tried a few Firefox browser extensions which purport to "never
lose your form text", but I find they just don't save frequently enough
for my taste.  I would love to know an extension that does this
properly!

Edward

Excerpts from Ryan Yates's message of 2015-04-24 15:15:37 +0100:
> My very pessimistic rule of thumb is don't trust a form field unless the
> site actively saves a draft as you type.
> 
> On Fri, Apr 24, 2015 at 10:13 AM, Eric Crockett <ecrockett0 at gmail.com>
> wrote:
> 
> > My Firefox also has this issue. So it seems the problem is the browser
> > itself. How can this be fixed on the server side?
> >
> > On Fri, Apr 24, 2015 at 10:07 AM, Edward Z. Yang <ezyang at mit.edu> wrote:
> >
> >> Whatever the case, it affects me, it affects SPJ, so we ought to fix it!
> >> (Change your browser is not a good answer :)
> >>
> >> Edward
> >>
> >> Excerpts from Eric Crockett's message of 2015-04-24 15:02:35 +0100:
> >> > On the contrary, I did precisely that just a few days ago (
> >> > https://ghc.haskell.org/trac/ghc/ticket/10338), and to my surprise,
> >> trac
> >> > *did* save my new ticket text. Perhaps this is a browser-specific issue?
> >> > I'm using 64-bit Chrome 42.0.2311.90.
> >> >
> >> > On Fri, Apr 24, 2015 at 9:54 AM, Edward Z. Yang <ezyang at mit.edu> wrote:
> >> >
> >> > > Steps to reproduce:
> >> > >
> >> > > 1. Click "New Ticket"
> >> > > 2. Type some text into the box
> >> > > 3. Press "Back" in your browser
> >> > > 4. Press "Forward" in your browser
> >> > >
> >> > > If you try this with an official Trac this doesn't happen, so either
> >> > > this was fixed in a new version, or we have a plugin installed which
> >> > > is causing this to happen.
> >> > >
> >> > > Current version of Trac is 1.0.5, we're currently running 1.0.1
> >> > >
> >> > > Thanks,
> >> > > Edward
> >> > > _______________________________________________
> >> > > ghc-devs mailing list
> >> > > ghc-devs at haskell.org
> >> > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >> > >
> >>
> >
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
> >

From vagarenko at gmail.com  Fri Apr 24 15:16:29 2015
From: vagarenko at gmail.com (Alexey Vagarenko)
Date: Fri, 24 Apr 2015 21:16:29 +0600
Subject: Can we fix our Trac that doesn't lose new ticket text
In-Reply-To: <1429885203-sup-4704@sabre>
References: <1429883680-sup-8002@sabre>
 <CAApao_==6m770eihH035TWGyYHrP9gGUWdBfBWMUr3xnSuxNTQ@mail.gmail.com>
 <1429884427-sup-5668@sabre>
 <CAApao_kEXJEgqbeqnOCeTrGrFbFYg30B-5OeDLt_-4SpbDn5hg@mail.gmail.com>
 <CAO27hRrLkjX84yLjaWQk-b8p-LdoGJ+b6fM4=_uWZ1iFLnZ80A@mail.gmail.com>
 <1429885203-sup-4704@sabre>
Message-ID: <CAGzSZM4ChrkSru_b5nHjS5ms4ab_PO-KNnNYsBSJ75rpfCPOhw@mail.gmail.com>

I don't know about an extension, but there is .js library
https://github.com/simsalabim/sisyphus

2015-04-24 20:20 GMT+06:00 Edward Z. Yang <ezyang at mit.edu>:
> I've tried a few Firefox browser extensions which purport to "never
> lose your form text", but I find they just don't save frequently enough
> for my taste.  I would love to know an extension that does this
> properly!
>
> Edward
>
> Excerpts from Ryan Yates's message of 2015-04-24 15:15:37 +0100:
>> My very pessimistic rule of thumb is don't trust a form field unless the
>> site actively saves a draft as you type.
>>
>> On Fri, Apr 24, 2015 at 10:13 AM, Eric Crockett <ecrockett0 at gmail.com>
>> wrote:
>>
>> > My Firefox also has this issue. So it seems the problem is the browser
>> > itself. How can this be fixed on the server side?
>> >
>> > On Fri, Apr 24, 2015 at 10:07 AM, Edward Z. Yang <ezyang at mit.edu> wrote:
>> >
>> >> Whatever the case, it affects me, it affects SPJ, so we ought to fix it!
>> >> (Change your browser is not a good answer :)
>> >>
>> >> Edward
>> >>
>> >> Excerpts from Eric Crockett's message of 2015-04-24 15:02:35 +0100:
>> >> > On the contrary, I did precisely that just a few days ago (
>> >> > https://ghc.haskell.org/trac/ghc/ticket/10338), and to my surprise,
>> >> trac
>> >> > *did* save my new ticket text. Perhaps this is a browser-specific issue?
>> >> > I'm using 64-bit Chrome 42.0.2311.90.
>> >> >
>> >> > On Fri, Apr 24, 2015 at 9:54 AM, Edward Z. Yang <ezyang at mit.edu> wrote:
>> >> >
>> >> > > Steps to reproduce:
>> >> > >
>> >> > > 1. Click "New Ticket"
>> >> > > 2. Type some text into the box
>> >> > > 3. Press "Back" in your browser
>> >> > > 4. Press "Forward" in your browser
>> >> > >
>> >> > > If you try this with an official Trac this doesn't happen, so either
>> >> > > this was fixed in a new version, or we have a plugin installed which
>> >> > > is causing this to happen.
>> >> > >
>> >> > > Current version of Trac is 1.0.5, we're currently running 1.0.1
>> >> > >
>> >> > > Thanks,
>> >> > > Edward
>> >> > > _______________________________________________
>> >> > > ghc-devs mailing list
>> >> > > ghc-devs at haskell.org
>> >> > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> >> > >
>> >>
>> >
>> >
>> > _______________________________________________
>> > ghc-devs mailing list
>> > ghc-devs at haskell.org
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> >
>> >
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From k-bx at k-bx.com  Fri Apr 24 17:15:47 2015
From: k-bx at k-bx.com (Kostiantyn Rybnikov)
Date: Fri, 24 Apr 2015 20:15:47 +0300
Subject: Can we fix our Trac that doesn't lose new ticket text
In-Reply-To: <1429883680-sup-8002@sabre>
References: <1429883680-sup-8002@sabre>
Message-ID: <CAAbahfTy5qv_1x8nHwZkETXRhaAQbg-+yUzdsA=XXfJst+BF7g@mail.gmail.com>

Not related to issue, but generally for Firefox I suggest an addon "Form
History Control" (UI is not superb, but it does what it should do)
https://addons.mozilla.org/uk/firefox/addon/form-history-control/

For Chrome, "Lazarus Form Recovery" used to work, but I'm not sure it still
does, since it seemed abandoned.

On Fri, Apr 24, 2015 at 4:54 PM, Edward Z. Yang <ezyang at mit.edu> wrote:

> Steps to reproduce:
>
> 1. Click "New Ticket"
> 2. Type some text into the box
> 3. Press "Back" in your browser
> 4. Press "Forward" in your browser
>
> If you try this with an official Trac this doesn't happen, so either
> this was fixed in a new version, or we have a plugin installed which
> is causing this to happen.
>
> Current version of Trac is 1.0.5, we're currently running 1.0.1
>
> Thanks,
> Edward
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150424/7de2249d/attachment.html>

From dan.doel at gmail.com  Fri Apr 24 17:17:45 2015
From: dan.doel at gmail.com (Dan Doel)
Date: Fri, 24 Apr 2015 13:17:45 -0400
Subject: Can we fix our Trac that doesn't lose new ticket text
In-Reply-To: <1429883680-sup-8002@sabre>
References: <1429883680-sup-8002@sabre>
Message-ID: <CAHEA9tNeqk2YkzJ=MuZY6GNABjZQ5BtfE+1Nu81PzjOkCsvQ2g@mail.gmail.com>

At a guess, I recently had some websites start refreshing more than I
thought they used to when using the back/forward buttons. From what I
gather, this is due to the websites specifying no-cache or something
similar in their HTTP (?) headers. I think reloading the page throws away
entered text, while going back/forward to a stored page does not.

Perhaps something the ghc trac is using is setting this? Or it could be
something outside trac entirely?

Also wouldn't surprise me if Chrome behaves differently with such a setting
than Firefox.

Not sure if that helps.

On Fri, Apr 24, 2015 at 9:54 AM, Edward Z. Yang <ezyang at mit.edu> wrote:

> Steps to reproduce:
>
> 1. Click "New Ticket"
> 2. Type some text into the box
> 3. Press "Back" in your browser
> 4. Press "Forward" in your browser
>
> If you try this with an official Trac this doesn't happen, so either
> this was fixed in a new version, or we have a plugin installed which
> is causing this to happen.
>
> Current version of Trac is 1.0.5, we're currently running 1.0.1
>
> Thanks,
> Edward
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150424/05edb2c8/attachment.html>

From alan.zimm at gmail.com  Tue Apr 28 14:02:24 2015
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Tue, 28 Apr 2015 16:02:24 +0200
Subject: API Annotations and 7.10.2
In-Reply-To: <CANma=H-79za9GfrD49L+C_AmKFWAxH7QpToU2=EN97QCdo+rbA@mail.gmail.com>
References: <CANma=H8DiBr_VkDPSvQiV0S0d6Psb=_nUtPBs6jZoEarJV7KhA@mail.gmail.com>
 <CANma=H-79za9GfrD49L+C_AmKFWAxH7QpToU2=EN97QCdo+rbA@mail.gmail.com>
Message-ID: <CANma=H8Hi_gXiYQC71nwZzMqyHVcqzbyDJy6hcvej80_pmXQfQ@mail.gmail.com>

As you can see in the report below, there are a LOT of patches related to
API Annotations.
I am beginning to have difficulty keeping them up to date, as master moves
ahead.

I would like to request that as many of these as possible be merged into
master sooner rather than later, subject to review approval. There can then
be a secondary process to evaluate which of them actually belong in 7.10.2.

If it would simplify things, I can collapse some of these into a mega patch.

Regards
  Alan

Report follows ....
---------------------------------------------------------------
This is the current state of the patches proposed for 7.10.2

Landed in ghc-7.10 (thank you)
   #10207   D803
   #10214   D806

Landed in master but not ghc-7.10 (also thank you)
    #10209  D813
    #10256  D818
    #10254  D822
    #10255  D823
    #10277  D829

Patches available
    #10269  D832
    #10299  D840  *
    #10268  D825  *
    #10278  D833  *
    #10307  D842  *
    #10309  D848  *
    #10280  D834
    #10287  D837
    #10312  D846
    #10354/#10315  D868
    #10357  D869
    #10358  D873

The ones marked with * form a dependent chain of merges

Moved from 7.10.2 to 7.12
  #10250 D815

The proposed patches all make minor changes to the Parser / RdrHsSyn, and
do not affect the AST or Haddock, nor change the operation of the compiler.

The one with the largest impact is D840, which corrects a conflict in the
parser and now generates the correct type for '[] (`HsExplicitListTy`
rather than `HsTyVar').


The merge process to produce
https://github.com/alanz/ghc/tree/api-annotations is

--------------------------- (2015-04-26)
git checkout api-annotations
git reset --hard master
arc patch --nobranch D832 (cd libraries/Cabal && git checkout
bda1ce6b757cdaca93f2eba4e1906a4658719537)
                           to revert to the master libraries/Cabal
submodule change)
arc patch --nobranch D840
arc patch --nobranch D825 (manual fixup)
arc patch --nobranch D833 (manual fixup)
arc patch --nobranch D842 (manual fixup)
arc patch --nobranch D848 (manual fixup)
arc patch --nobranch D834 (manual fixup)
arc patch --nobranch D837 (manual fixup)
arc patch --nobranch D846 (manual fixup)
arc patch --nobranch D868 (manual fixup)
arc patch --nobranch D869
arc patch --nobranch D873 (manual fixup)




On Fri, Apr 17, 2015 at 7:22 PM, Alan & Kim Zimmerman <alan.zimm at gmail.com>
wrote:

> This is the current state of the patches proposed for 7.10.2
>
> Landed in ghc-7.10 (thank you)
>    #10207   D803
>    #10214   D806
>
> Landed in master but not ghc-7.10 (also thank you)
>     #10209  D813
>     #10256  D818
>     #10254  D822
>     #10255  D823
>     #10277  D829
>
> Patches available
>     #10269  D832
>     #10299  D840  *
>     #10268  D825  *
>     #10278  D833  *
>     #10307  D842  *
>     #10309  D848  *
>     #10280  D834
>     #10287  D837
>     #10312  D846
>
> The ones marked with * form a dependent chain of merges
>
> Patches still to be finalised/provided
>     #10314
>     #10315
>
> Moved from 7.10.2 to 7.12
>   #10250 D815
>
> The proposed patches all make minor changes to the Parser / RdrHsSyn, and
> do not affect the AST or Haddock, nor change the operation of the compiler.
>
> The one with the largest impact is D840, which corrects a conflict in the
> parser and now generates the correct type for '[] (`HsExplicitListTy`
> rather than `HsTyVar').
>
>
> The merge process to produce
> https://github.com/alanz/ghc/tree/api-annotations is
>
> --------------------------- (2015-04-17)
> git checkout -b api-annotations
> arc patch --nobranch D832
> arc patch --nobranch D840
> arc patch --nobranch D825 (manual fixup)
> arc patch --nobranch D833
> arc patch --nobranch D842
> arc patch --nobranch D848 (manual fixup)
> arc patch --nobranch D834 (manual fixup)
> arc patch --nobranch D837 (manual fixup)
> arc patch --nobranch D846 (manual fixup)
> --------------------------------------------------
>
> I am really keen to get these landed, as being able to round-trip haskell
> source using the annotations is the foundation of Matt Pickerings GSOC
> proposal, and it would be a pity if it could not achieve its full potential.
>
> Regards
>   Alan
>
>
> On Mon, Apr 13, 2015 at 12:14 AM, Alan & Kim Zimmerman <
> alan.zimm at gmail.com> wrote:
>
>> This is the state of the nation for API Annotations for 7.10.2
>>
>> The following are ready for merging, in the order proposed. The first
>> four depend on each other.
>>
>> #10209    D813
>> #10256    D818  (depends D813)
>> #10254    D822  (depends D818)
>> #10269    D832  (depends D822)
>>
>> #10255  D823
>>
>> #10268  D825
>> #10278  D833 (depends D825)
>>
>> #10280  D834
>>
>> #10277  D829
>>
>> #10287  D837
>>
>>
>> These are the commands I used to apply them to a freshly checked out ghc
>> tree. The manual fixup is for Makefile, .gitignore, all.T, basically keep
>> both legs each time.
>>
>> --------------------------
>> git checkout -b api-annotations
>> arc patch --nobranch D832
>> arc patch --nobranch D823 (manual fixup)
>> arc patch --nobranch D825 (manual fixup)
>> arc patch --nobranch D834 (manual fixup)
>> arc patch --nobranch D829
>> arc patch --nobranch D837 (manual fixup)
>> arc patch --nobranch D833 (manual fixup)
>> --------------------------
>>
>> Once these are in, I do not think there will be anything else.
>>
>> Regards
>>   Alan
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150428/82f99951/attachment.html>

From ecrockett0 at gmail.com  Tue Apr 28 14:18:38 2015
From: ecrockett0 at gmail.com (Eric Crockett)
Date: Tue, 28 Apr 2015 10:18:38 -0400
Subject: Fixing anchors in GHC docs
Message-ID: <CAApao_=1HKVujKLRRUfxZn1r_Co=WZ7yS1vSRpXvfbvLQe+Zvw@mail.gmail.com>

I think I sent this out already, but never heard back. An issue was fixed
in HsColour regarding HTML anchors in the GHC docs, documented here:
https://github.com/haskell/hackage-server/issues/319

Apparently GHC devs upload their own documentation [to hackage], which
means HsColour needs to be updated on your end so that anchors are correct
the next time docs are generated.

-Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150428/76319ac1/attachment.html>

From simonpj at microsoft.com  Thu Apr 30 15:14:38 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 30 Apr 2015 15:14:38 +0000
Subject: [Diffusion] [Commented On] rGHCb61562feb876: Seed SpecConstr from
 local calls
In-Reply-To: <20150430071014.3487.30528@phabricator.haskell.org>
References: <diffusion-audit-PHID-CMIT-kcp5zhhm5g5xfyzs2y43@phabricator.haskell.org>
 <20150430071014.3487.30528@phabricator.haskell.org>
Message-ID: <7ba6366b5420439fa053eb3f90b1d337@DB4PR30MB030.064d.mgd.msft.net>

Thanks! I've added a comment to the relevant Note to document the effect.

Simon

| -----Original Message-----
| From: noreply at phabricator.haskell.org
| [mailto:noreply at phabricator.haskell.org]
| Sent: 30 April 2015 08:10
| To: Simon Peyton Jones
| Subject: [Diffusion] [Commented On] rGHCb61562feb876: Seed SpecConstr
| from local calls
| 
| nomeata added a subscriber: nomeata.
| nomeata added a comment.
| 
| Nice: -4% alloc in nofib/multiplier, -2.8% in nofib/minimax. ?
| 
| 
| USERS
|   simonpj (Author)
|   GHC - Core/System FC (Auditor)
| 
| COMMIT
|   https://phabricator.haskell.org/rGHCb61562feb876
| 
| EMAIL PREFERENCES
|   https://phabricator.haskell.org/settings/panel/emailpreferences/
| 
| To: simonpj, GHC - Core/System FC
| Cc: nomeata

From d at davidterei.com  Thu Apr 30 22:58:23 2015
From: d at davidterei.com (David Terei)
Date: Thu, 30 Apr 2015 15:58:23 -0700
Subject: Roles, GND, Data.Coerce
Message-ID: <CACHt1w-APhbj1yCtFsXi9wYpj+W2DRWOZ7DVuKcgm1caq027_w@mail.gmail.com>

All,

An issue that came up with GHC 7.8 was the design of Roles and
Data.Coerce, with it's ability to break module abstractions by
default, requiring programmers adopt explicit role annotations to
enforce some types of invariants for abstract data types.

Because of this issue, as of now, GND & Data.Coerce are still disabled
in Safe Haskell. We'd like to change this but need feedback from
everyone.

I've written up a wiki page with lots of information on the issue:

https://ghc.haskell.org/trac/ghc/wiki/SafeRoles

Please read, it has information on how Roles work, the problem it
raises and subtleties in the current system. Possible paths forward
are also there, but I'll include below.

Please be aware that this discussion is about Roles in general, not
specifically how when using -XSafe. Ideally we'd come up with a
solution that works regardless of if using Safe Haskell or not.

I personally like option (3), although it isn't clear to me how hairy
the implementation would be.

== Possible Paths Forward for Roles ==

1) Do Nothing -- Keep Roles & GND unchanged, keep them unsafe in Safe Haskell.

2) Accept as Safe -- Keep Roles & GND unchanged, accept them as safe
in Safe Haskell and warn users that they neednominal role annotations
on ADTs.

3) In-scope constructor restriction for lifting instances -- The
newtype constructor restriction for unwrapping instances could be
extended to both data types, and the lifting instances of Data.Coerce.
This is, GND & Coercing under a type constructor is allowed if (a) all
involved constructors are in scope, or (b) the constructors involved
have been explicitly declared to allow coercion without them being in
scope. I.e., (b) allows library authors to opt-into the current GHC
behavior. This would require new syntax, probably just an explicit
deriving Coercible statement.

4) Change default role to nominal -- This will prioritize safety over
GND, and the belief is that it may break a lot of code. Worse, that it
will be an ongoing tax as role annotations will be needed to enable
GND.

5) Nominal default when constructors aren't exported -- When a module
doesn't export all the constructors of a data type, then the type
parameters of the data type should default to nominal. This heuristic
seems to capture somewhat the intention of the user, but given the
practice of defining an Internal module that exports everything, it
seems of limited use.

6) Nominal default in future -- Add a new extension,
SafeNewtypeDeriving that switches the default role to nominal, but
continue to provide a deprecated GND extension to help with the
transition. The claims in support of representational roles as default
though believe that nominal by default has an ongoing, continuous tax,
not just a transition cost. So it isn't clear that any scheme like
this satisfies that argument.

7) Safe Haskell Specific -- Many of the above approaches could be
adopted in a Safe Haskell specific manner. This isn't ideal as it
makes safe-inference harder and Safe Haskell less likely to remain
viable going forward. Richard suggests one such idea.

==

The belief by many people seems to be that (4) and (6) would be too
much of burden. I'd like to avoid (7) if possible. It isn't clear to
me if (7) ends up better than (2).

I'm going to try to setup some infastructure for compiling Hackage so
that we can measure how impactful these changes would be.

Cheers,
David

From dave.terei at gmail.com  Thu Apr 30 22:58:48 2015
From: dave.terei at gmail.com (David Terei)
Date: Thu, 30 Apr 2015 15:58:48 -0700
Subject: Generalized Newtype Deriving not allowed in Safe Haskell
In-Reply-To: <CACHt1w-B2CJFs7YUHQxPg4RakBUQoOjFGkrx9hgs9BsHjsw8Aw@mail.gmail.com>
References: <CAL2jp559kvXbd3MxEC0Zrg8dzFrUbSYVMwzky3-oHMjKATurDA@mail.gmail.com>
 <0d913dcca48b47abadb7ab6b4125b906@DB4PR30MB030.064d.mgd.msft.net>
 <CACHt1w8Mc_LoZaACO-sPvWxMwragP35bfKL2cz+_GD4tF24OOg@mail.gmail.com>
 <ee5348affe8f498bbbd8c3660591932c@DB4PR30MB030.064d.mgd.msft.net>
 <CACHt1w9GOLMPu+jBdUsi33rvyC_bQ=3MkFAzooTfG6MJ5_FxKA@mail.gmail.com>
 <bd7fb584e9b0400ea13a04c628d77cc6@DB4PR30MB030.064d.mgd.msft.net>
 <CACHt1w-B2CJFs7YUHQxPg4RakBUQoOjFGkrx9hgs9BsHjsw8Aw@mail.gmail.com>
Message-ID: <CACHt1w8MrEavUKnBjUiQ3CJOzaJgeWumxtdskk4igg1XDfROHw@mail.gmail.com>

Done, sent a new email thread out. Can find on wiki page here:

https://ghc.haskell.org/trac/ghc/wiki/SafeRoles

On 13 April 2015 at 18:18, David Terei <dave.terei at gmail.com> wrote:
> Good advice. I'll set that up soon.
>
> On 13 April 2015 at 00:10, Simon Peyton Jones <simonpj at microsoft.com> wrote:
>> David
>>
>> If you would like to lead a debate, and drive it to a conclusion, that would be most helpful.
>>
>> Usually it's constructive to write a wiki page that sets out the design choices, with examples to illustrate their consequences, to set the terms of the debate.  Otherwise you risk misunderstandings, with red herrings being discussed repeatedly.
>>
>> Thanks
>>
>> Simon
>>
>> |  -----Original Message-----
>> |  From: davidterei at gmail.com [mailto:davidterei at gmail.com] On Behalf Of
>> |  David Terei
>> |  Sent: 12 April 2015 09:52
>> |  To: Simon Peyton Jones
>> |  Cc: Omari Norman; ghc-devs at haskell.org; haskell Cafe
>> |  Subject: Re: Generalized Newtype Deriving not allowed in Safe Haskell
>> |
>> |  On 10 April 2015 at 01:48, Simon Peyton Jones <simonpj at microsoft.com>
>> |  wrote:
>> |  > |  prefer, such as only exporting the Coerce instance if all the
>> |  > | constructors are exported, it seems that the ship sailed on these
>> |  >
>> |  > Coercible is relatively recent; I don't think we should regard it as
>> |  cast in stone.
>> |  >
>> |  > But yes, the Coerbible instance of a newtype is only available when
>> |  the data constructor for the newtype is lexically in scope.
>> |
>> |  Yes, so as you point out in the paper, this is done to preserve
>> |  abstractions, but the same rule isn't applied to data types since some
>> |  types like IORef don't even have constructors that can be in scope.
>> |
>> |  Ideally I'd like to find a way forward that works for everyone and
>> |  isn't just a Safe Haskell mode setting.
>> |
>> |  I think the first question is, are there situations where you'd want to
>> |  use `coerce` internally to a module but disallow it externally? The
>> |  role mechanism is a little awkward as it doesn't allow this (although
>> |  it does for newtype's). If yes, then I think we should start there.
>> |
>> |  If it seems we don't need external vs internal control, then we could
>> |  simply change the default to be that GHC sets referential type
>> |  parameters to nominal and allows them to be weakened to referential
>> |  through role annotations. We could use hackage to test how much
>> |  breakage this would cause.
>> |
>> |  The third option is something Safe Haskell specific, so probably
>> |  applying the newtype constructor rule to data types.
>> |
>> |  >
>> |  > Simon
>> |  >
>> |  > |  -----Original Message-----
>> |  > |  From: davidterei at gmail.com [mailto:davidterei at gmail.com] On Behalf
>> |  > | Of  David Terei
>> |  > |  Sent: 10 April 2015 09:38
>> |  > |  To: Simon Peyton Jones
>> |  > |  Cc: Omari Norman; haskell Cafe; ghc-devs at haskell.org
>> |  > |  Subject: Re: Generalized Newtype Deriving not allowed in Safe
>> |  > | Haskell
>> |  > |
>> |  > |  I'll prepare a patch for the userguide soon.
>> |  > |
>> |  > |  As for something better, yes I think we can and should. It's on my
>> |  > | todo  list :) Basically, the new-GND design has all the mechanisms
>> |  > | to be  safe, but sadly the defaults are rather worrying. Without
>> |  > | explicit  annotations from the user, module abstractions are
>> |  broken.
>> |  > | This is why  we left GND out of Safe Haskell for the moment as it
>> |  is
>> |  > | a subtle and  easy mistake to make.
>> |  > |
>> |  > |  If the module contained explicit role annotations then it could be
>> |  > | allowed. The discussion in
>> |  > |  https://ghc.haskell.org/trac/ghc/ticket/8827 has other solutions
>> |  > | that I  prefer, such as only exporting the Coerce instance if all
>> |  > | the  constructors are exported, it seems that the ship sailed on
>> |  > | these  bigger changes sadly.
>> |  > |
>> |  > |  Cheers,
>> |  > |  David
>> |  > |
>> |  > |  On 9 April 2015 at 00:56, Simon Peyton Jones
>> |  > | <simonpj at microsoft.com>
>> |  > |  wrote:
>> |  > |  > There is a long discussion on
>> |  > |  > https://ghc.haskell.org/trac/ghc/ticket/8827
>> |  > |  > about whether the new Coercible story makes GND ok for Safe
>> |  Haskell.
>> |  > |  > At a type-soundness level, definitely yes.  But there are other
>> |  > | > less-clear-cut issues like ?breaking abstractions? to consider.
>> |  > | The  > decision on the ticket  > (comment:36) seems to be: GND
>> |  stays
>> |  > | out of Safe Haskell for now, but  > there is room for a better
>> |  > | proposal.
>> |  > |  >
>> |  > |  >
>> |  > |  >
>> |  > |  > I don?t have an opinion myself. David Terei and David Mazieres
>> |  > | are in  > the driving seat, but I?m sure they?ll be responsive to
>> |  user input.
>> |  > |  >
>> |  > |  >
>> |  > |  >
>> |  > |  > However, I think the user manual may not have kept up with
>> |  #8827.
>> |  > |  The
>> |  > |  > sentence ?GeneralizedNewtypeDeriving ? It can be used to violate
>> |  > | > constructor access control, by allowing untrusted code to
>> |  > | manipulate  > protected data types in ways the data type author did
>> |  > | not intend,  > breaking invariants they have established.?
>> |  vanished
>> |  > | from the 7.8  > user manual (links below).  Maybe it should be
>> |  restored.
>> |  > |  >
>> |  > |  >
>> |  > |  >
>> |  > |  > Safe Haskell aficionados, would you like to offer a patch for
>> |  the
>> |  > | manual?
>> |  > |  > And maybe also a less drastic remedy than omitting GND
>> |  altogether?
>> |  > |  >
>> |  > |  >
>> |  > |  >
>> |  > |  > Simon
>> |  > |  >
>> |  > |  >
>> |  > |  >
>> |  > |  > From: Omari Norman [mailto:omari at smileystation.com]  > Sent: 09
>> |  > | April 2015 02:44  > To: haskell Cafe  > Subject: Generalized
>> |  Newtype
>> |  > | Deriving not allowed in Safe Haskell  >  >  >  > When compiling
>> |  code
>> |  > | with Generalized Newtype Deriving and the  > -fwarn-unsafe flag, I
>> |  > | get  >  >  >  > -XGeneralizedNewtypeDeriving is not allowed in Safe
>> |  > | Haskell  >  >  >  > This happens both in GHC 7.8 and GHC 7.10.
>> |  > |  >
>> |  > |  >
>> |  > |  >
>> |  > |  > I thought I remembered reading somewhere that GNTD is now part
>> |  of
>> |  > | the  > safe language?  The GHC manual used to state that GNTD is
>> |  not
>> |  > | allowed  > in Safe  > Haskell:
>> |  > |  >
>> |  > |  >
>> |  > |  >
>> |  > |  >
>> |  > |
>> |  https://downloads.haskell.org/~ghc/7.6.3/docs/html/users_guide/safe-
>> |  > |  ha
>> |  > |  > skell.html#safe-language
>> |  > |  >
>> |  > |  >
>> |  > |  >
>> |  > |  > But this language on GNTD not being part of the safe language
>> |  was
>> |  > | > removed in the 7.8 manual:
>> |  > |  >
>> |  > |  >
>> |  > |  >
>> |  > |  >
>> |  > |
>> |  https://downloads.haskell.org/~ghc/7.8.2/docs/html/users_guide/safe-
>> |  > |  ha
>> |  > |  > skell.html#safe-language
>> |  > |  >
>> |  > |  >
>> |  > |  >
>> |  > |  > The GHC release notes don't say anything about this one way or
>> |  > | the  other.
>> |  > |  > Thoughts?
>> |  > |  >
>> |  > |  >
>> |  > |  > _______________________________________________
>> |  > |  > ghc-devs mailing list
>> |  > |  > ghc-devs at haskell.org
>> |  > |  > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> |  > |  >
>> |  > _______________________________________________
>> |  > ghc-devs mailing list
>> |  > ghc-devs at haskell.org
>> |  > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs