From marlowsd at gmail.com  Sun May  1 07:55:52 2016
From: marlowsd at gmail.com (Simon Marlow)
Date: Sun, 1 May 2016 08:55:52 +0100
Subject: Reverted your commit
In-Reply-To: <51758a8890d144768304409f4aa0398c@DB4PR30MB030.064d.mgd.msft.net>
References: <51758a8890d144768304409f4aa0398c@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <CANsrgP+e1d5cSa3HtL9prKh4UdjvvSnY-xfs7H9WZUZqU_e3Gw@mail.gmail.com>

Thanks Simon, I'm looking into it.

On 28 April 2016 at 22:02, Simon Peyton Jones <simonpj at microsoft.com> wrote:

> Simon
>
> I reverted your commit
>
>
> https://phabricator.haskell.org/rGHC546f24e4f8a7c086b1e5afcdda624176610cbcf8
>
> because it made every single binary that GHC builds seg-fault on windows.
> Even
>
>                 main = return ()
>
> seg-faults.
>
> You may want to review and re-commit it.
>
> Simon
>
>
>
> commit 24864ba5587c1a0447beabae90529e8bb4fa117a
>
> Author: Simon Marlow <marlowsd at gmail.com>
>
> Date:   Sat Apr 23 22:14:43 2016 +0100
>
>     Use __builtin_clz() to implement log_2()
>
>         A microoptimisation in the block allocator.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160501/5812e271/attachment.html>

From rahulmutt at gmail.com  Mon May  2 15:26:07 2016
From: rahulmutt at gmail.com (Rahul Muttineni)
Date: Mon, 2 May 2016 20:56:07 +0530
Subject: Mentor for a JVM backend for GHC
Message-ID: <CANij+eRbvRcNGbMx23xGw2Q8LjZ4x4AzBwVyoi5oM5KfvF+A+Q@mail.gmail.com>

Hi GHC Developers,

I've started working on a JVM backend for GHC [1] and I'd love to work on
it as my Summer of Haskell project.

Currently, the build system is setup using a mix of Shake (for the RTS
build) and Stack (for the main compiler build) and I ensure that most
commits build successfully. I have ported the core part of the scheduler
and ported over the fundamental types (Capability, StgTSO, Task,
StgClosure, etc.) taking advantage of OOP in the implementation when I
could.

Additionally, I performed a non-trivial refactor of the hs-java package
adding support for inner classes and fields which was very cumbersome to do
in the original package. On the frontend, I have tapped into the STG code
from the GHC 7.10.3 library and setup a CodeGen monad for generating JVM
bytecode. The main task of generating the actual bytecode, porting the more
critical parts of the RTS, and adding support for the threaded RTS remain.

The strategy for compilation is as follows:
- Intercept the STG code in the GHC pipeline
- Convert from STG->JVM bytecode [2] in a similar manner as STG->Cmm
preserving semantics as best as possible [3]
- Port the GHC RTS (normal & threaded) to Java [4]
- Put all the generated class files + RTS into a single jar to be run
directly by the JVM.

My objectives for the project during the summer are:
- To implement the compilation strategy mentioned above
- Implement the Java FFI for foreign imports. [5]
- Implement the most important [6] PrimOps that GHC supports.
- Port the base package replacing the C FFI imports with equivalent Java
FFI imports. [7]

A little bit about myself: I spent a lot of time studying functional
language implementation by reading SPJ's famous book and reading research
papers on related topics last summer as self-study.

I took a break and resumed a couple months ago where I spent a lot of time
plowing through the STG->Cmm code generator as well as the RTS and going
back and forth between them to get a clear understanding of how everything
works.

Moreover, I compiled simple Haskell programs and observed the STG, Cmm, and
assembly output (by decompiling the final executable with objdump) to
understand bits of the code generator where the source code wasn't that
clear.

I also spent a great deal of time studying the JVM internals, reading the
JVM spec, looking for any new features that could facilitate a high
performance implementation [8].

It would be great if someone with an understanding of nuances of the RTS
and code generator could mentor me for this project. It has been a blast so
far learning all the prerequisites and contemplating the design. I'd be
very excited to take this on as a summer project.

Also, given that I have hardly 5 days remaining, does anyone have
suggestions on how I can structure the proposal without getting into too
many details? There are still some parts of the design I haven't figured
out, but I know I could find some solution when I get to it during the
porting process.

Thanks,
Rahul Muttineni

[1] http://github.com/rahulmutt/ghcvm

[2] I intend to organically derive an IR at a later stage to allow for some
optimizations by looking at the final working implementation without an IR
and looking for patterns of repeated sequences of bytecode and assigning
each sequence its own instruction in the IR.

[3] Obviously, the lack of control of memory layouts (besides allocating
off the JVM heap using DirectByteBuffers) and lack of general tail calls
makes it tough to match the semantics of Cmm, but there are many solutions
around it, as can be found in the few papers on translating STG to Java/JVM
bytecode.

[4] This is the GHC RTS without GC and profiling since the JVM has great
support for those already. Also, lots of care must be taken to ensure that
the lock semantics stays in tact during the port.

[5] foreign exports will be dealt at a later stage, but I am taking care of
naming the closures nicely so that in the future you don't have to type
long names like the labels GHC compiles to call a Haskell function in Java.

[6] Basically all the PrimOps that would be required to provide plumbing
for the Prelude functions that can compile beginner-level programs found in
books such as Learn You a Haskell for Great Good.

[7] I know that it's a lot more complicated than just replacing FFI calls.
I'd have to change around a lot of the code in base as well.

[8] I found that the new "invokedynamic" instruction as well as the
MethodHandle API (something like function pointers) that were introduced in
JDK 7 could fit the bill. But as of now, I want to get a baseline
implementation that is compatible with Java 5 so I will not be utilizing
these newer features.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160502/5d1721a2/attachment.html>

From carter.schonwald at gmail.com  Mon May  2 15:48:27 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Mon, 2 May 2016 11:48:27 -0400
Subject: Mentor for a JVM backend for GHC
In-Reply-To: <CANij+eRbvRcNGbMx23xGw2Q8LjZ4x4AzBwVyoi5oM5KfvF+A+Q@mail.gmail.com>
References: <CANij+eRbvRcNGbMx23xGw2Q8LjZ4x4AzBwVyoi5oM5KfvF+A+Q@mail.gmail.com>
Message-ID: <CAHYVw0xaHU6-h7PFy7hKJ_ToWNEDmYzyoBpyf4Q-PR_bth-DzQ@mail.gmail.com>

Woah this is some prodigious work!

1) would initially targeting only newer jvm  variants make the work targets
for the summer easier ?

2) it's worth talking with ghc folks on #ghc and the gsoc admins at
#haskell-gsoc on freenode IRC  about gsoc fit and possible mentors.

3) it sounds like the work so far is worth sharing on the r/Haskell sub
Reddit.  If you want.  I do recommend IRC for talking with some of the
active ghc and gsoc folk

On Monday, May 2, 2016, Rahul Muttineni <rahulmutt at gmail.com> wrote:

> Hi GHC Developers,
>
> I've started working on a JVM backend for GHC [1] and I'd love to work on
> it as my Summer of Haskell project.
>
> Currently, the build system is setup using a mix of Shake (for the RTS
> build) and Stack (for the main compiler build) and I ensure that most
> commits build successfully. I have ported the core part of the scheduler
> and ported over the fundamental types (Capability, StgTSO, Task,
> StgClosure, etc.) taking advantage of OOP in the implementation when I
> could.
>
> Additionally, I performed a non-trivial refactor of the hs-java package
> adding support for inner classes and fields which was very cumbersome to do
> in the original package. On the frontend, I have tapped into the STG code
> from the GHC 7.10.3 library and setup a CodeGen monad for generating JVM
> bytecode. The main task of generating the actual bytecode, porting the more
> critical parts of the RTS, and adding support for the threaded RTS remain.
>
> The strategy for compilation is as follows:
> - Intercept the STG code in the GHC pipeline
> - Convert from STG->JVM bytecode [2] in a similar manner as STG->Cmm
> preserving semantics as best as possible [3]
> - Port the GHC RTS (normal & threaded) to Java [4]
> - Put all the generated class files + RTS into a single jar to be run
> directly by the JVM.
>
> My objectives for the project during the summer are:
> - To implement the compilation strategy mentioned above
> - Implement the Java FFI for foreign imports. [5]
> - Implement the most important [6] PrimOps that GHC supports.
> - Port the base package replacing the C FFI imports with equivalent Java
> FFI imports. [7]
>
> A little bit about myself: I spent a lot of time studying functional
> language implementation by reading SPJ's famous book and reading research
> papers on related topics last summer as self-study.
>
> I took a break and resumed a couple months ago where I spent a lot of time
> plowing through the STG->Cmm code generator as well as the RTS and going
> back and forth between them to get a clear understanding of how everything
> works.
>
> Moreover, I compiled simple Haskell programs and observed the STG, Cmm,
> and assembly output (by decompiling the final executable with objdump) to
> understand bits of the code generator where the source code wasn't that
> clear.
>
> I also spent a great deal of time studying the JVM internals, reading the
> JVM spec, looking for any new features that could facilitate a high
> performance implementation [8].
>
> It would be great if someone with an understanding of nuances of the RTS
> and code generator could mentor me for this project. It has been a blast so
> far learning all the prerequisites and contemplating the design. I'd be
> very excited to take this on as a summer project.
>
> Also, given that I have hardly 5 days remaining, does anyone have
> suggestions on how I can structure the proposal without getting into too
> many details? There are still some parts of the design I haven't figured
> out, but I know I could find some solution when I get to it during the
> porting process.
>
> Thanks,
> Rahul Muttineni
>
> [1] http://github.com/rahulmutt/ghcvm
>
> [2] I intend to organically derive an IR at a later stage to allow for
> some optimizations by looking at the final working implementation without
> an IR and looking for patterns of repeated sequences of bytecode and
> assigning each sequence its own instruction in the IR.
>
> [3] Obviously, the lack of control of memory layouts (besides allocating
> off the JVM heap using DirectByteBuffers) and lack of general tail calls
> makes it tough to match the semantics of Cmm, but there are many solutions
> around it, as can be found in the few papers on translating STG to Java/JVM
> bytecode.
>
> [4] This is the GHC RTS without GC and profiling since the JVM has great
> support for those already. Also, lots of care must be taken to ensure that
> the lock semantics stays in tact during the port.
>
> [5] foreign exports will be dealt at a later stage, but I am taking care
> of naming the closures nicely so that in the future you don't have to type
> long names like the labels GHC compiles to call a Haskell function in Java.
>
> [6] Basically all the PrimOps that would be required to provide plumbing
> for the Prelude functions that can compile beginner-level programs found in
> books such as Learn You a Haskell for Great Good.
>
> [7] I know that it's a lot more complicated than just replacing FFI calls.
> I'd have to change around a lot of the code in base as well.
>
> [8] I found that the new "invokedynamic" instruction as well as the
> MethodHandle API (something like function pointers) that were introduced in
> JDK 7 could fit the bill. But as of now, I want to get a baseline
> implementation that is compatible with Java 5 so I will not be utilizing
> these newer features.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160502/a1895c5f/attachment.html>

From ekmett at gmail.com  Mon May  2 16:05:42 2016
From: ekmett at gmail.com (Edward Kmett)
Date: Tue, 3 May 2016 00:05:42 +0800
Subject: Mentor for a JVM backend for GHC
In-Reply-To: <CAHYVw0xaHU6-h7PFy7hKJ_ToWNEDmYzyoBpyf4Q-PR_bth-DzQ@mail.gmail.com>
References: <CANij+eRbvRcNGbMx23xGw2Q8LjZ4x4AzBwVyoi5oM5KfvF+A+Q@mail.gmail.com>
 <CAHYVw0xaHU6-h7PFy7hKJ_ToWNEDmYzyoBpyf4Q-PR_bth-DzQ@mail.gmail.com>
Message-ID: <CAJumaK_jUqE3A22-U006mptqc8ccJRjk19Q8aF=g6mgox8GcDg@mail.gmail.com>

I'd be willing to help out at least as a backup mentor for this.

I'd prefer if we could find someone who is more familiar with the GHC
peculiarities, but I can speak to the JVM and Java bytecode end and
know the general STG execution model pretty well.

-Edward

On Mon, May 2, 2016 at 11:48 PM, Carter Schonwald
<carter.schonwald at gmail.com> wrote:
> Woah this is some prodigious work!
>
> 1) would initially targeting only newer jvm  variants make the work targets
> for the summer easier ?
>
> 2) it's worth talking with ghc folks on #ghc and the gsoc admins at
> #haskell-gsoc on freenode IRC  about gsoc fit and possible mentors.
>
> 3) it sounds like the work so far is worth sharing on the r/Haskell sub
> Reddit.  If you want.  I do recommend IRC for talking with some of the
> active ghc and gsoc folk
>
>
> On Monday, May 2, 2016, Rahul Muttineni <rahulmutt at gmail.com> wrote:
>>
>> Hi GHC Developers,
>>
>> I've started working on a JVM backend for GHC [1] and I'd love to work on
>> it as my Summer of Haskell project.
>>
>> Currently, the build system is setup using a mix of Shake (for the RTS
>> build) and Stack (for the main compiler build) and I ensure that most
>> commits build successfully. I have ported the core part of the scheduler and
>> ported over the fundamental types (Capability, StgTSO, Task, StgClosure,
>> etc.) taking advantage of OOP in the implementation when I could.
>>
>> Additionally, I performed a non-trivial refactor of the hs-java package
>> adding support for inner classes and fields which was very cumbersome to do
>> in the original package. On the frontend, I have tapped into the STG code
>> from the GHC 7.10.3 library and setup a CodeGen monad for generating JVM
>> bytecode. The main task of generating the actual bytecode, porting the more
>> critical parts of the RTS, and adding support for the threaded RTS remain.
>>
>> The strategy for compilation is as follows:
>> - Intercept the STG code in the GHC pipeline
>> - Convert from STG->JVM bytecode [2] in a similar manner as STG->Cmm
>> preserving semantics as best as possible [3]
>> - Port the GHC RTS (normal & threaded) to Java [4]
>> - Put all the generated class files + RTS into a single jar to be run
>> directly by the JVM.
>>
>> My objectives for the project during the summer are:
>> - To implement the compilation strategy mentioned above
>> - Implement the Java FFI for foreign imports. [5]
>> - Implement the most important [6] PrimOps that GHC supports.
>> - Port the base package replacing the C FFI imports with equivalent Java
>> FFI imports. [7]
>>
>> A little bit about myself: I spent a lot of time studying functional
>> language implementation by reading SPJ's famous book and reading research
>> papers on related topics last summer as self-study.
>>
>> I took a break and resumed a couple months ago where I spent a lot of time
>> plowing through the STG->Cmm code generator as well as the RTS and going
>> back and forth between them to get a clear understanding of how everything
>> works.
>>
>> Moreover, I compiled simple Haskell programs and observed the STG, Cmm,
>> and assembly output (by decompiling the final executable with objdump) to
>> understand bits of the code generator where the source code wasn't that
>> clear.
>>
>> I also spent a great deal of time studying the JVM internals, reading the
>> JVM spec, looking for any new features that could facilitate a high
>> performance implementation [8].
>>
>> It would be great if someone with an understanding of nuances of the RTS
>> and code generator could mentor me for this project. It has been a blast so
>> far learning all the prerequisites and contemplating the design. I'd be very
>> excited to take this on as a summer project.
>>
>> Also, given that I have hardly 5 days remaining, does anyone have
>> suggestions on how I can structure the proposal without getting into too
>> many details? There are still some parts of the design I haven't figured
>> out, but I know I could find some solution when I get to it during the
>> porting process.
>>
>> Thanks,
>> Rahul Muttineni
>>
>> [1] http://github.com/rahulmutt/ghcvm
>>
>> [2] I intend to organically derive an IR at a later stage to allow for
>> some optimizations by looking at the final working implementation without an
>> IR and looking for patterns of repeated sequences of bytecode and assigning
>> each sequence its own instruction in the IR.
>>
>> [3] Obviously, the lack of control of memory layouts (besides allocating
>> off the JVM heap using DirectByteBuffers) and lack of general tail calls
>> makes it tough to match the semantics of Cmm, but there are many solutions
>> around it, as can be found in the few papers on translating STG to Java/JVM
>> bytecode.
>>
>> [4] This is the GHC RTS without GC and profiling since the JVM has great
>> support for those already. Also, lots of care must be taken to ensure that
>> the lock semantics stays in tact during the port.
>>
>> [5] foreign exports will be dealt at a later stage, but I am taking care
>> of naming the closures nicely so that in the future you don't have to type
>> long names like the labels GHC compiles to call a Haskell function in Java.
>>
>> [6] Basically all the PrimOps that would be required to provide plumbing
>> for the Prelude functions that can compile beginner-level programs found in
>> books such as Learn You a Haskell for Great Good.
>>
>> [7] I know that it's a lot more complicated than just replacing FFI calls.
>> I'd have to change around a lot of the code in base as well.
>>
>> [8] I found that the new "invokedynamic" instruction as well as the
>> MethodHandle API (something like function pointers) that were introduced in
>> JDK 7 could fit the bill. But as of now, I want to get a baseline
>> implementation that is compatible with Java 5 so I will not be utilizing
>> these newer features.
>>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>

From karel.gardas at centrum.cz  Mon May  2 16:29:59 2016
From: karel.gardas at centrum.cz (Karel Gardas)
Date: Mon, 02 May 2016 18:29:59 +0200
Subject: Mentor for a JVM backend for GHC
In-Reply-To: <CANij+eRbvRcNGbMx23xGw2Q8LjZ4x4AzBwVyoi5oM5KfvF+A+Q@mail.gmail.com>
References: <CANij+eRbvRcNGbMx23xGw2Q8LjZ4x4AzBwVyoi5oM5KfvF+A+Q@mail.gmail.com>
Message-ID: <57278087.4030108@centrum.cz>


Rahul,

a lot of work in front of you. There was a similar project in the past, 
LambdaVM was it's name, author Brian Alliet -- unfortunately google 
can't reveal working site with it nor web.archive.org. What I can offer 
you are some of the latest sources of this project. It's based on GHC 
6.7 version so really an old base, but perhaps something would be usable 
even for your own work and even after all those years? Let me know if 
you are interested and I'll pack that and upload somewhere -- well 
assuming you have not heart about it since otherwise I would expect it 
to be noted somewhere in your email. Just let me know if you are 
interested...

Anyway, I'm keeping my finger crossed for this your work! I'm personally 
very interested in seeing Haskell hosted in JVM and inter operable with 
Java...(yes, I know about Frege...)

Cheers,
Karel

On 05/ 2/16 05:26 PM, Rahul Muttineni wrote:
> Hi GHC Developers,
>
> I've started working on a JVM backend for GHC [1] and I'd love to work
> on it as my Summer of Haskell project.
>
> Currently, the build system is setup using a mix of Shake (for the RTS
> build) and Stack (for the main compiler build) and I ensure that most
> commits build successfully. I have ported the core part of the scheduler
> and ported over the fundamental types (Capability, StgTSO, Task,
> StgClosure, etc.) taking advantage of OOP in the implementation when I
> could.
>
> Additionally, I performed a non-trivial refactor of the hs-java package
> adding support for inner classes and fields which was very cumbersome to
> do in the original package. On the frontend, I have tapped into the STG
> code from the GHC 7.10.3 library and setup a CodeGen monad for
> generating JVM bytecode. The main task of generating the actual
> bytecode, porting the more critical parts of the RTS, and adding support
> for the threaded RTS remain.
>
> The strategy for compilation is as follows:
> - Intercept the STG code in the GHC pipeline
> - Convert from STG->JVM bytecode [2] in a similar manner as STG->Cmm
> preserving semantics as best as possible [3]
> - Port the GHC RTS (normal & threaded) to Java [4]
> - Put all the generated class files + RTS into a single jar to be run
> directly by the JVM.
>
> My objectives for the project during the summer are:
> - To implement the compilation strategy mentioned above
> - Implement the Java FFI for foreign imports. [5]
> - Implement the most important [6] PrimOps that GHC supports.
> - Port the base package replacing the C FFI imports with equivalent Java
> FFI imports. [7]
>
> A little bit about myself: I spent a lot of time studying functional
> language implementation by reading SPJ's famous book and reading
> research papers on related topics last summer as self-study.
>
> I took a break and resumed a couple months ago where I spent a lot of
> time plowing through the STG->Cmm code generator as well as the RTS and
> going back and forth between them to get a clear understanding of how
> everything works.
>
> Moreover, I compiled simple Haskell programs and observed the STG, Cmm,
> and assembly output (by decompiling the final executable with objdump)
> to understand bits of the code generator where the source code wasn't
> that clear.
>
> I also spent a great deal of time studying the JVM internals, reading
> the JVM spec, looking for any new features that could facilitate a high
> performance implementation [8].
>
> It would be great if someone with an understanding of nuances of the RTS
> and code generator could mentor me for this project. It has been a blast
> so far learning all the prerequisites and contemplating the design. I'd
> be very excited to take this on as a summer project.
>
> Also, given that I have hardly 5 days remaining, does anyone have
> suggestions on how I can structure the proposal without getting into too
> many details? There are still some parts of the design I haven't figured
> out, but I know I could find some solution when I get to it during the
> porting process.
>
> Thanks,
> Rahul Muttineni
>
> [1] http://github.com/rahulmutt/ghcvm
>
> [2] I intend to organically derive an IR at a later stage to allow for
> some optimizations by looking at the final working implementation
> without an IR and looking for patterns of repeated sequences of bytecode
> and assigning each sequence its own instruction in the IR.
>
> [3] Obviously, the lack of control of memory layouts (besides allocating
> off the JVM heap using DirectByteBuffers) and lack of general tail calls
> makes it tough to match the semantics of Cmm, but there are many
> solutions around it, as can be found in the few papers on translating
> STG to Java/JVM bytecode.
>
> [4] This is the GHC RTS without GC and profiling since the JVM has great
> support for those already. Also, lots of care must be taken to ensure
> that the lock semantics stays in tact during the port.
>
> [5] foreign exports will be dealt at a later stage, but I am taking care
> of naming the closures nicely so that in the future you don't have to
> type long names like the labels GHC compiles to call a Haskell function
> in Java.
>
> [6] Basically all the PrimOps that would be required to provide plumbing
> for the Prelude functions that can compile beginner-level programs found
> in books such as Learn You a Haskell for Great Good.
>
> [7] I know that it's a lot more complicated than just replacing FFI
> calls. I'd have to change around a lot of the code in base as well.
>
> [8] I found that the new "invokedynamic" instruction as well as the
> MethodHandle API (something like function pointers) that were introduced
> in JDK 7 could fit the bill. But as of now, I want to get a baseline
> implementation that is compatible with Java 5 so I will not be utilizing
> these newer features.
>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


From rahulmutt at gmail.com  Mon May  2 17:55:36 2016
From: rahulmutt at gmail.com (Rahul Muttineni)
Date: Mon, 2 May 2016 23:25:36 +0530
Subject: Mentor for a JVM backend for GHC
In-Reply-To: <57278087.4030108@centrum.cz>
References: <CANij+eRbvRcNGbMx23xGw2Q8LjZ4x4AzBwVyoi5oM5KfvF+A+Q@mail.gmail.com>
 <57278087.4030108@centrum.cz>
Message-ID: <CANij+eQA2zZQtFpfeHUgNPSGegPbzMityN9oy7DwEMy8gKmTzw@mail.gmail.com>

@Carter:
1) Actually, that would be harder. I've given the implementation without
the new features a lot of thought and it's simpler to get done. I've only
briefly given a thought on how the newer JVM features could be used, but I
figured as I port more of the GHC's RTS/code generator, I'll know enough of
the nuances to be able to judge where to apply these new features
effectively.

2) Thanks for the suggestion. I don't use IRC that often, but if I could
reach more people there then I'll give it a try.

3) Right now it doesn't do anything that is visible to the user so I'll
hold off on that until I've ported a tiny but usable subset of the code
generator. My target is to get the basic Java FFI and I/O working so that
there's something new and interesting to play with.

@Edward: Thanks a lot! That would be great.

@Karel: Yeah it is, but the reward of being able to run Haskell anywhere is
definitely worth it! I'm aware of the LambdaVM project. I didn't mention it
because I wanted to focus on the present. I sent Brian Alliet an email
asking for guidance on architectural decisions a while back, but have
received no response.

I'd be interested in having a copy of the LambdaVM source, thanks. There
are a couple of places in the design I'm iffy on, so it'd be nice to have a
source of inspiration.

Frege is a great project in its own right, but GHC Haskell has become the
standard and I find many of the extensions to be useful in eliminating many
more classes of bugs at compile-time.

Thanks guys,
Rahul Muttineni


On Mon, May 2, 2016 at 9:59 PM, Karel Gardas <karel.gardas at centrum.cz>
wrote:

>
> Rahul,
>
> a lot of work in front of you. There was a similar project in the past,
> LambdaVM was it's name, author Brian Alliet -- unfortunately google can't
> reveal working site with it nor web.archive.org. What I can offer you are
> some of the latest sources of this project. It's based on GHC 6.7 version
> so really an old base, but perhaps something would be usable even for your
> own work and even after all those years? Let me know if you are interested
> and I'll pack that and upload somewhere -- well assuming you have not heart
> about it since otherwise I would expect it to be noted somewhere in your
> email. Just let me know if you are interested...
>
> Anyway, I'm keeping my finger crossed for this your work! I'm personally
> very interested in seeing Haskell hosted in JVM and inter operable with
> Java...(yes, I know about Frege...)
>
> Cheers,
> Karel
>
>
> On 05/ 2/16 05:26 PM, Rahul Muttineni wrote:
>
>> Hi GHC Developers,
>>
>> I've started working on a JVM backend for GHC [1] and I'd love to work
>> on it as my Summer of Haskell project.
>>
>> Currently, the build system is setup using a mix of Shake (for the RTS
>> build) and Stack (for the main compiler build) and I ensure that most
>> commits build successfully. I have ported the core part of the scheduler
>> and ported over the fundamental types (Capability, StgTSO, Task,
>> StgClosure, etc.) taking advantage of OOP in the implementation when I
>> could.
>>
>> Additionally, I performed a non-trivial refactor of the hs-java package
>> adding support for inner classes and fields which was very cumbersome to
>> do in the original package. On the frontend, I have tapped into the STG
>> code from the GHC 7.10.3 library and setup a CodeGen monad for
>> generating JVM bytecode. The main task of generating the actual
>> bytecode, porting the more critical parts of the RTS, and adding support
>> for the threaded RTS remain.
>>
>> The strategy for compilation is as follows:
>> - Intercept the STG code in the GHC pipeline
>> - Convert from STG->JVM bytecode [2] in a similar manner as STG->Cmm
>> preserving semantics as best as possible [3]
>> - Port the GHC RTS (normal & threaded) to Java [4]
>> - Put all the generated class files + RTS into a single jar to be run
>> directly by the JVM.
>>
>> My objectives for the project during the summer are:
>> - To implement the compilation strategy mentioned above
>> - Implement the Java FFI for foreign imports. [5]
>> - Implement the most important [6] PrimOps that GHC supports.
>> - Port the base package replacing the C FFI imports with equivalent Java
>> FFI imports. [7]
>>
>> A little bit about myself: I spent a lot of time studying functional
>> language implementation by reading SPJ's famous book and reading
>> research papers on related topics last summer as self-study.
>>
>> I took a break and resumed a couple months ago where I spent a lot of
>> time plowing through the STG->Cmm code generator as well as the RTS and
>> going back and forth between them to get a clear understanding of how
>> everything works.
>>
>> Moreover, I compiled simple Haskell programs and observed the STG, Cmm,
>> and assembly output (by decompiling the final executable with objdump)
>> to understand bits of the code generator where the source code wasn't
>> that clear.
>>
>> I also spent a great deal of time studying the JVM internals, reading
>> the JVM spec, looking for any new features that could facilitate a high
>> performance implementation [8].
>>
>> It would be great if someone with an understanding of nuances of the RTS
>> and code generator could mentor me for this project. It has been a blast
>> so far learning all the prerequisites and contemplating the design. I'd
>> be very excited to take this on as a summer project.
>>
>> Also, given that I have hardly 5 days remaining, does anyone have
>> suggestions on how I can structure the proposal without getting into too
>> many details? There are still some parts of the design I haven't figured
>> out, but I know I could find some solution when I get to it during the
>> porting process.
>>
>> Thanks,
>> Rahul Muttineni
>>
>> [1] http://github.com/rahulmutt/ghcvm
>>
>> [2] I intend to organically derive an IR at a later stage to allow for
>> some optimizations by looking at the final working implementation
>> without an IR and looking for patterns of repeated sequences of bytecode
>> and assigning each sequence its own instruction in the IR.
>>
>> [3] Obviously, the lack of control of memory layouts (besides allocating
>> off the JVM heap using DirectByteBuffers) and lack of general tail calls
>> makes it tough to match the semantics of Cmm, but there are many
>> solutions around it, as can be found in the few papers on translating
>> STG to Java/JVM bytecode.
>>
>> [4] This is the GHC RTS without GC and profiling since the JVM has great
>> support for those already. Also, lots of care must be taken to ensure
>> that the lock semantics stays in tact during the port.
>>
>> [5] foreign exports will be dealt at a later stage, but I am taking care
>> of naming the closures nicely so that in the future you don't have to
>> type long names like the labels GHC compiles to call a Haskell function
>> in Java.
>>
>> [6] Basically all the PrimOps that would be required to provide plumbing
>> for the Prelude functions that can compile beginner-level programs found
>> in books such as Learn You a Haskell for Great Good.
>>
>> [7] I know that it's a lot more complicated than just replacing FFI
>> calls. I'd have to change around a lot of the code in base as well.
>>
>> [8] I found that the new "invokedynamic" instruction as well as the
>> MethodHandle API (something like function pointers) that were introduced
>> in JDK 7 could fit the bill. But as of now, I want to get a baseline
>> implementation that is compatible with Java 5 so I will not be utilizing
>> these newer features.
>>
>>
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>>
>


-- 
Rahul Muttineni
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160502/3fa74ceb/attachment.html>

From iavor.diatchki at gmail.com  Mon May  2 17:59:24 2016
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Mon, 2 May 2016 10:59:24 -0700
Subject: GHC nightly builds?
Message-ID: <CAGK9nuoFD35uQJcGeScj5_h25-Ux=T3O1mF8YJZ8eTA0i+czSQ@mail.gmail.com>

Hello,

do we have nightly builds for development versions of GHC somewhere?

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

From ezyang at mit.edu  Mon May  2 18:05:55 2016
From: ezyang at mit.edu (Edward Z. Yang)
Date: Mon, 02 May 2016 11:05:55 -0700
Subject: GHC nightly builds?
In-Reply-To: <CAGK9nuoFD35uQJcGeScj5_h25-Ux=T3O1mF8YJZ8eTA0i+czSQ@mail.gmail.com>
References: <CAGK9nuoFD35uQJcGeScj5_h25-Ux=T3O1mF8YJZ8eTA0i+czSQ@mail.gmail.com>
Message-ID: <1462212321-sup-7382@sabre>

hvr has a PPA with GHC nightlies https://launchpad.net/~hvr/+archive/ubuntu/ghc (ghc-head)

Edward

Excerpts from Iavor Diatchki's message of 2016-05-02 10:59:24 -0700:
> Hello,
> 
> do we have nightly builds for development versions of GHC somewhere?
> 
> -Iavor

From ryan.gl.scott at gmail.com  Mon May  2 18:09:10 2016
From: ryan.gl.scott at gmail.com (Ryan Scott)
Date: Mon, 2 May 2016 14:09:10 -0400
Subject: GHC nightly builds?
Message-ID: <CADdQpRBowLP9ZV-oEWc24ai0+qrzr5Hp+EEGH8V4b+=TH_fHTw@mail.gmail.com>

Herbert has an Ubuntu PPA with a ghc-head package that is built on a
regular basis:

https://launchpad.net/~hvr/+archive/ubuntu/ghc

Best,
Ryan S.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160502/6426aa38/attachment.html>

From karel.gardas at centrum.cz  Mon May  2 18:44:47 2016
From: karel.gardas at centrum.cz (Karel Gardas)
Date: Mon, 02 May 2016 20:44:47 +0200
Subject: GHC nightly builds?
In-Reply-To: <CAGK9nuoFD35uQJcGeScj5_h25-Ux=T3O1mF8YJZ8eTA0i+czSQ@mail.gmail.com>
References: <CAGK9nuoFD35uQJcGeScj5_h25-Ux=T3O1mF8YJZ8eTA0i+czSQ@mail.gmail.com>
Message-ID: <5727A01F.1090506@centrum.cz>


It seems builders also allow to download binary distro from successful 
build: http://haskell.inf.elte.hu/builders/

Karel

On 05/ 2/16 07:59 PM, Iavor Diatchki wrote:
> Hello,
>
> do we have nightly builds for development versions of GHC somewhere?
>
> -Iavor
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


From karel.gardas at centrum.cz  Mon May  2 19:15:01 2016
From: karel.gardas at centrum.cz (Karel Gardas)
Date: Mon, 02 May 2016 21:15:01 +0200
Subject: Mentor for a JVM backend for GHC
In-Reply-To: <CANij+eQA2zZQtFpfeHUgNPSGegPbzMityN9oy7DwEMy8gKmTzw@mail.gmail.com>
References: <CANij+eRbvRcNGbMx23xGw2Q8LjZ4x4AzBwVyoi5oM5KfvF+A+Q@mail.gmail.com>
 <57278087.4030108@centrum.cz>
 <CANij+eQA2zZQtFpfeHUgNPSGegPbzMityN9oy7DwEMy8gKmTzw@mail.gmail.com>
Message-ID: <5727A735.7040703@centrum.cz>

On 05/ 2/16 07:55 PM, Rahul Muttineni wrote:
> @Karel: Yeah it is, but the reward of being able to run Haskell anywhere
> is definitely worth it! I'm aware of the LambdaVM project. I didn't
> mention it because I wanted to focus on the present. I sent Brian Alliet
> an email asking for guidance on architectural decisions a while back,
> but have received no response.
>
> I'd be interested in having a copy of the LambdaVM source, thanks. There
> are a couple of places in the design I'm iffy on, so it'd be nice to
> have a source of inspiration.

http://uloz.to/x3q5Mmi1/lambdavm-tar-bz2 -- this is 50 MB. I've not 
`gmake clean' it so you see what's compiled in jar/classes and what's 
not. Pity, if you'd like to have it running (besides already precompiled 
examples) you would need either Solaris 11 (my host) or "risk" build 
yourself.

> Frege is a great project in its own right, but GHC Haskell has become
> the standard and I find many of the extensions to be useful in
> eliminating many more classes of bugs at compile-time.

Indeed, I'm looking forward to seeing/testing your results.

Karel


From eir at cis.upenn.edu  Mon May  2 20:10:50 2016
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Mon, 2 May 2016 16:10:50 -0400
Subject: Bikeshedding request for GHCi's :type
In-Reply-To: <60D162E7-9FAE-45AE-BD22-9E1C6D6C7466@cis.upenn.edu>
References: <60D162E7-9FAE-45AE-BD22-9E1C6D6C7466@cis.upenn.edu>
Message-ID: <C5CFC059-D1D3-4692-9871-B6902982D8AF@cis.upenn.edu>

I have collected feedback gleaned here, on the ticket, and on reddit and summarized here: https://ghc.haskell.org/trac/ghc/wiki/Design/GHCi/Type#Summaryoffeedbackaboutthisissue

That summary includes this concrete proposal:
 1. Ask for concrete suggestions about names for the new commands.
 2. Use these names on my current implementation (which prints out only one specialization)
 3. Post a feature request looking for more specializations.

I simply don't have time to specify a design or implement an algorithm for printing out multiple specializations. Furthermore, my current implementation meets all specifications proffered for printing out multiple specializations, for all values of "multiple" that equal 1. It is easy to extend later.

Separately, there is a groundswell of support for :doc, but that's beyond the scope of my work on this point. (I personally would love :doc, too.)

So, what shall we name the two new commands?

1. A new command that specializes a type. (Currently with one specialization, but perhaps more examples in the future.)

2. A new command that preserves specialized type variables so that users of TypeApplications know what type parameters to pass in next.

I have suggested :type-def for (1) and :type-spec for (2). I don't strongly like either. :examples and :inst have been suggested for (1). Any other ideas?

Thanks!
Richard

On Apr 26, 2016, at 9:08 AM, Richard Eisenberg <eir at cis.upenn.edu> wrote:

> Hi devs,
> 
> Over the weekend, I was pondering the Haskell course I will be teaching next year and shuddered at having to teach Foldable at the same time as `length`. So I implemented feature request #10963 (https://ghc.haskell.org/trac/ghc/ticket/10963), which allows for a way for a user to request a specialization of a type. It all works wonderfully, but there is a real user-facing design issue here around the default behavior of :type and whether or not to add new :type-y like commands. I have outlined the situation here: https://ghc.haskell.org/trac/ghc/wiki/Design/GHCi/Type
> 
> I'd love some broad input on this issue. If you've got a stake in how this all works, please skim that wiki page and comment on #10963.
> 
> Thanks!
> Richard
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


From takenobu.hs at gmail.com  Tue May  3 15:14:33 2016
From: takenobu.hs at gmail.com (Takenobu Tani)
Date: Wed, 4 May 2016 00:14:33 +0900
Subject: [Haskell-cafe] Bikeshedding request for GHCi's :type
In-Reply-To: <C5CFC059-D1D3-4692-9871-B6902982D8AF@cis.upenn.edu>
References: <60D162E7-9FAE-45AE-BD22-9E1C6D6C7466@cis.upenn.edu>
 <C5CFC059-D1D3-4692-9871-B6902982D8AF@cis.upenn.edu>
Message-ID: <CAPB_Nvx1bzzXxOV-rOJWB297Ee3B-qNaHOASV5=DvE-L7Y3OsQ@mail.gmail.com>

Hi Richard,

I like your decision and plan.
Thank you a lot of work, for community.


About new command name for (1):

Most users, perhaps, have entered the `:t` rather than `:type`.

  ghci> :t  length

In the same way, how about a full name and abbreviation name for (1).
For example, we prepare `:type-default` and `:td`.

  ghci> :td  length

So they don't misunderstand that it is "typedef".


I also like `:type!` and `:types` with Jack :)

  ghci> :t!  length


Regards,
Takenobu


2016-05-03 5:10 GMT+09:00 Richard Eisenberg <eir at cis.upenn.edu>:

> I have collected feedback gleaned here, on the ticket, and on reddit and
> summarized here:
> https://ghc.haskell.org/trac/ghc/wiki/Design/GHCi/Type#Summaryoffeedbackaboutthisissue
>
> That summary includes this concrete proposal:
>  1. Ask for concrete suggestions about names for the new commands.
>  2. Use these names on my current implementation (which prints out only
> one specialization)
>  3. Post a feature request looking for more specializations.
>
> I simply don't have time to specify a design or implement an algorithm for
> printing out multiple specializations. Furthermore, my current
> implementation meets all specifications proffered for printing out multiple
> specializations, for all values of "multiple" that equal 1. It is easy to
> extend later.
>
> Separately, there is a groundswell of support for :doc, but that's beyond
> the scope of my work on this point. (I personally would love :doc, too.)
>
> So, what shall we name the two new commands?
>
> 1. A new command that specializes a type. (Currently with one
> specialization, but perhaps more examples in the future.)
>
> 2. A new command that preserves specialized type variables so that users
> of TypeApplications know what type parameters to pass in next.
>
> I have suggested :type-def for (1) and :type-spec for (2). I don't
> strongly like either. :examples and :inst have been suggested for (1). Any
> other ideas?
>
> Thanks!
> Richard
>
> On Apr 26, 2016, at 9:08 AM, Richard Eisenberg <eir at cis.upenn.edu> wrote:
>
> > Hi devs,
> >
> > Over the weekend, I was pondering the Haskell course I will be teaching
> next year and shuddered at having to teach Foldable at the same time as
> `length`. So I implemented feature request #10963 (
> https://ghc.haskell.org/trac/ghc/ticket/10963), which allows for a way
> for a user to request a specialization of a type. It all works wonderfully,
> but there is a real user-facing design issue here around the default
> behavior of :type and whether or not to add new :type-y like commands. I
> have outlined the situation here:
> https://ghc.haskell.org/trac/ghc/wiki/Design/GHCi/Type
> >
> > I'd love some broad input on this issue. If you've got a stake in how
> this all works, please skim that wiki page and comment on #10963.
> >
> > Thanks!
> > Richard
> > _______________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160504/d1979187/attachment.html>

From ben at well-typed.com  Tue May  3 15:32:42 2016
From: ben at well-typed.com (Ben Gamari)
Date: Tue, 03 May 2016 17:32:42 +0200
Subject: Draft 8.0 Mac build directions
In-Reply-To: <CAHYVw0x_bNzRJDu3TqnBDHi__Y50DY_2e1Jq7XgaMGKjZ2VyxA@mail.gmail.com>
References: <CE46F136-D75F-40B2-BCFA-1CB9F9656A5B@gmail.com>
 <CAHYVw0x_bNzRJDu3TqnBDHi__Y50DY_2e1Jq7XgaMGKjZ2VyxA@mail.gmail.com>
Message-ID: <878tzr6tt1.fsf@smart-cactus.org>

Carter Schonwald <carter.schonwald at gmail.com> writes:

> Woops forgot to link them this morning
>
> https://gist.github.com/cartazio/32038db09222a2aac767cb5c03b406c6
>
> Feedback would be appreciated.
> And still need to mention cabal install hscolour :)
>
> Pardon the noise and feedback would be appreciated!
>
Thanks for this, Carter!

About font installation: do you know any any way to accomplish this
at the terminal?

re step 9: Perhaps make sure that `~/.cabal/bin` is in `PATH`.

re step 16: There are two step 16s! ;)

re step 16.a: It would also be nice if you could describe the reasons for
choosing Clang or GCC, in particular with references to further reading
(e.g. I think #7602 is relevant here).

re step 16.b: some justification for setting the `DEPLOYMENT_TARGET` would
be nice.

re step 17: If I'm not mistaken `--with-gcc` is now redundant. If you
still want to include it then perhaps just make the example use `$CC`
instead of `$pathToMyCC`.

re step 17: Also, isn't the nm issue dependent upon the XCode version,
not OS X version?

Also, perhaps you could submit a patch to fix haddock issue cited in
step 18?


Thanks again!

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/20160503/b00c6ad9/attachment.sig>

From allbery.b at gmail.com  Tue May  3 15:48:28 2016
From: allbery.b at gmail.com (Brandon Allbery)
Date: Tue, 3 May 2016 11:48:28 -0400
Subject: Draft 8.0 Mac build directions
In-Reply-To: <878tzr6tt1.fsf@smart-cactus.org>
References: <CE46F136-D75F-40B2-BCFA-1CB9F9656A5B@gmail.com>
 <CAHYVw0x_bNzRJDu3TqnBDHi__Y50DY_2e1Jq7XgaMGKjZ2VyxA@mail.gmail.com>
 <878tzr6tt1.fsf@smart-cactus.org>
Message-ID: <CAKFCL4V85vt-47sDYEFqcer9y_km6n81LZKmjF5XhUoNkL4y_A@mail.gmail.com>

On Tue, May 3, 2016 at 11:32 AM, Ben Gamari <ben at well-typed.com> wrote:

> About font installation: do you know any any way to accomplish this
> at the terminal?
>

Just copy them to the appropriate directory (/Library/Fonts or
~/Library/Fonts); fontd will see and register them automatically.
Font Book automates this and includes some basic sanity checks; it does not
do any extra registration or etc.

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

From thegravian at gmail.com  Tue May  3 15:52:31 2016
From: thegravian at gmail.com (thegravian)
Date: Tue, 03 May 2016 15:52:31 +0000
Subject: Mentor for a JVM backend for GHC
In-Reply-To: <5727A735.7040703@centrum.cz>
References: <CANij+eRbvRcNGbMx23xGw2Q8LjZ4x4AzBwVyoi5oM5KfvF+A+Q@mail.gmail.com>
 <57278087.4030108@centrum.cz>
 <CANij+eQA2zZQtFpfeHUgNPSGegPbzMityN9oy7DwEMy8gKmTzw@mail.gmail.com>
 <5727A735.7040703@centrum.cz>
Message-ID: <CAEbmKSVC+SmLexz9gP28H_H__-9MaUT+qaKKMTmEGJPub_-1FQ@mail.gmail.com>

Hi Rahul,

This is pretty neat stuff.  I'd be really interested in tracking this
project and maybe making a few commits, though I'm not in a good position
to be a full blown mentor.  While it's not mainline Java/bytecode yet, you
might have some future opportunities for better FFI and control of memory
layout with the work being done in the OpenJDK Panama and Valhalla projects
(resp.).  Some of the features in these projects will probably be in future
JDKs and might be worth harmonizing with on some level.

I think you're on the right track with MethodHandles and invokedynamic.

--Ian

On Mon, May 2, 2016 at 12:15 PM Karel Gardas <karel.gardas at centrum.cz>
wrote:

> On 05/ 2/16 07:55 PM, Rahul Muttineni wrote:
> > @Karel: Yeah it is, but the reward of being able to run Haskell anywhere
> > is definitely worth it! I'm aware of the LambdaVM project. I didn't
> > mention it because I wanted to focus on the present. I sent Brian Alliet
> > an email asking for guidance on architectural decisions a while back,
> > but have received no response.
> >
> > I'd be interested in having a copy of the LambdaVM source, thanks. There
> > are a couple of places in the design I'm iffy on, so it'd be nice to
> > have a source of inspiration.
>
> http://uloz.to/x3q5Mmi1/lambdavm-tar-bz2 -- this is 50 MB. I've not
> `gmake clean' it so you see what's compiled in jar/classes and what's
> not. Pity, if you'd like to have it running (besides already precompiled
> examples) you would need either Solaris 11 (my host) or "risk" build
> yourself.
>
> > Frege is a great project in its own right, but GHC Haskell has become
> > the standard and I find many of the extensions to be useful in
> > eliminating many more classes of bugs at compile-time.
>
> Indeed, I'm looking forward to seeing/testing your results.
>
> 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/20160503/9b9576af/attachment.html>

From rahulmutt at gmail.com  Tue May  3 16:09:34 2016
From: rahulmutt at gmail.com (Rahul Muttineni)
Date: Tue, 3 May 2016 21:39:34 +0530
Subject: Mentor for a JVM backend for GHC
In-Reply-To: <5727A735.7040703@centrum.cz>
References: <CANij+eRbvRcNGbMx23xGw2Q8LjZ4x4AzBwVyoi5oM5KfvF+A+Q@mail.gmail.com>
 <57278087.4030108@centrum.cz>
 <CANij+eQA2zZQtFpfeHUgNPSGegPbzMityN9oy7DwEMy8gKmTzw@mail.gmail.com>
 <5727A735.7040703@centrum.cz>
Message-ID: <CANij+eS+dipYUoEd_ek4p_dzHrKBO8zj4P30o5uGvR_ePWdhiw@mail.gmail.com>

Hi Karel,

On Tue, May 3, 2016 at 12:45 AM, Karel Gardas <karel.gardas at centrum.cz>
wrote:

http://uloz.to/x3q5Mmi1/lambdavm-tar-bz2 -- this is 50 MB. I've not `gmake
> clean' it so you see what's compiled in jar/classes and what's not. Pity,
> if you'd like to have it running (besides already precompiled examples) you
> would need either Solaris 11 (my host) or "risk" build yourself.


That's fine, it was no problem. Thanks for taking the time and uploading
it! It seems like it has dependencies and some more of Brian's packages (of
which one has a module named Brianweb.Java), which again are nowhere to be
found on the internet. Do you happen to have sources to his other packages
too?

>
> Indeed, I'm looking forward to seeing/testing your results.
>
> Karel
>

Awesome, I'll be sure you keep you updated.

Thanks,
Rahul Muttineni
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160503/ef9c3bb1/attachment-0001.html>

From rahulmutt at gmail.com  Tue May  3 16:26:42 2016
From: rahulmutt at gmail.com (Rahul Muttineni)
Date: Tue, 3 May 2016 21:56:42 +0530
Subject: Mentor for a JVM backend for GHC
In-Reply-To: <CAEbmKSVC+SmLexz9gP28H_H__-9MaUT+qaKKMTmEGJPub_-1FQ@mail.gmail.com>
References: <CANij+eRbvRcNGbMx23xGw2Q8LjZ4x4AzBwVyoi5oM5KfvF+A+Q@mail.gmail.com>
 <57278087.4030108@centrum.cz>
 <CANij+eQA2zZQtFpfeHUgNPSGegPbzMityN9oy7DwEMy8gKmTzw@mail.gmail.com>
 <5727A735.7040703@centrum.cz>
 <CAEbmKSVC+SmLexz9gP28H_H__-9MaUT+qaKKMTmEGJPub_-1FQ@mail.gmail.com>
Message-ID: <CANij+eR9MPF=FYrPEiY-X5eo95X-BLqKUN=D6Mr=E3mv1jmvvg@mail.gmail.com>

Hi Ian,

That sounds great. It's always great to have some help. Let me know if you
want some context for what's going on in the implementation. Those projects
look pretty cool. A more recent advance we can count on is GraalVM and the
accompanying Truffle API, which is slated for the JVM 9 release. It also
looks quite promising and the JRuby folks have a working implementation
which appears to be quite fast.

Thanks,
Rahul Muttineni
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160503/81b629a1/attachment.html>

From karel.gardas at centrum.cz  Tue May  3 18:02:34 2016
From: karel.gardas at centrum.cz (Karel Gardas)
Date: Tue, 03 May 2016 20:02:34 +0200
Subject: Mentor for a JVM backend for GHC
In-Reply-To: <CANij+eS+dipYUoEd_ek4p_dzHrKBO8zj4P30o5uGvR_ePWdhiw@mail.gmail.com>
References: <CANij+eRbvRcNGbMx23xGw2Q8LjZ4x4AzBwVyoi5oM5KfvF+A+Q@mail.gmail.com>
 <57278087.4030108@centrum.cz>
 <CANij+eQA2zZQtFpfeHUgNPSGegPbzMityN9oy7DwEMy8gKmTzw@mail.gmail.com>
 <5727A735.7040703@centrum.cz>
 <CANij+eS+dipYUoEd_ek4p_dzHrKBO8zj4P30o5uGvR_ePWdhiw@mail.gmail.com>
Message-ID: <5728E7BA.3090503@centrum.cz>

On 05/ 3/16 06:09 PM, Rahul Muttineni wrote:
> Hi Karel,
>
> On Tue, May 3, 2016 at 12:45 AM, Karel Gardas <karel.gardas at centrum.cz
> <mailto:karel.gardas at centrum.cz>> wrote:
>
>     http://uloz.to/x3q5Mmi1/lambdavm-tar-bz2 -- this is 50 MB. I've not
>     `gmake clean' it so you see what's compiled in jar/classes and
>     what's not. Pity, if you'd like to have it running (besides already
>     precompiled examples) you would need either Solaris 11 (my host) or
>     "risk" build yourself.
>
> That's fine, it was no problem. Thanks for taking the time and uploading
> it! It seems like it has dependencies and some more of Brian's packages
> (of which one has a module named Brianweb.Java), which again are nowhere
> to be found on the internet. Do you happen to have sources to his other
> packages too?

Indeed, hsjava and hsutils, please download 
http://uloz.to/xRV47zow/support-tar-bz2 -- and let me know if you need 
anything else. Definitely the beast was working here at least for fib.hs 
-- it's in the ghc root and probably also hello world like example so I 
definitely have everything needed here... So just speak up if 
something's missing. :-)

Karel


From ben at well-typed.com  Wed May  4 09:50:13 2016
From: ben at well-typed.com (Ben Gamari)
Date: Wed, 04 May 2016 11:50:13 +0200
Subject: Draft 8.0 Mac build directions
In-Reply-To: <CAKFCL4V85vt-47sDYEFqcer9y_km6n81LZKmjF5XhUoNkL4y_A@mail.gmail.com>
References: <CE46F136-D75F-40B2-BCFA-1CB9F9656A5B@gmail.com>
 <CAHYVw0x_bNzRJDu3TqnBDHi__Y50DY_2e1Jq7XgaMGKjZ2VyxA@mail.gmail.com>
 <878tzr6tt1.fsf@smart-cactus.org>
 <CAKFCL4V85vt-47sDYEFqcer9y_km6n81LZKmjF5XhUoNkL4y_A@mail.gmail.com>
Message-ID: <87y47qb19m.fsf@smart-cactus.org>

Brandon Allbery <allbery.b at gmail.com> writes:

> On Tue, May 3, 2016 at 11:32 AM, Ben Gamari <ben at well-typed.com> wrote:
>
>> About font installation: do you know any any way to accomplish this
>> at the terminal?
>>
>
> Just copy them to the appropriate directory (/Library/Fonts or
> ~/Library/Fonts); fontd will see and register them automatically.
> Font Book automates this and includes some basic sanity checks; it does not
> do any extra registration or etc.
>
Ahh, great. Thanks!

Carter, could you add this to your draft? I doubt I am the only one who
works primarily from the command line.

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/20160504/2b978c27/attachment.sig>

From ben at well-typed.com  Wed May  4 10:49:20 2016
From: ben at well-typed.com (Ben Gamari)
Date: Wed, 04 May 2016 12:49:20 +0200
Subject: [Maintainer needed] Actively maintained Haddock are happy Haddock
Message-ID: <874mae6qtr.fsf@smart-cactus.org>

tl;dr. Our Haddock need a dedicated maintainer responsible for their
       care and feeding. Would you like to move forward a critical piece
       of infrastructure used on a daily basis by thousands of
       Haskellers? Let us know if so.


Hello everyone,

While for several years Mateusz Kowalczyk and Simon Hengel have done an
admirable job in serving as comaintainers of the Haddock documentation
tool, they have both indicated that they no longer have the time to
continue to be active in this role. They both deserve our thanks for
their service.

While Matthew Pickering and I have tried to pick up some of the
Haddock's maintenance load in the meantime, we really need a dedicated
maintainer to ensure that Haddock continues to swim along healthfully.
At the moment there are over 150 open tickets in the issue tracker [1],
an open call for a stable release, and 4 patches in need of review. We
currently lack the time to get on top of such a load.

In particular, Haddock need someone to take ownership of the management
of the project: this person would keep an eye on (and preferably pare
down) the issue tracker (which typically isn't very active, happily),
guide new contributors, and manage releases. This is an opportunity to
drive forward a project used on a daily basis by a significant fraction
of Haskellers.

If you think you might be interested in serving in this role, please let
us know. Thanks!

Cheers,

- Ben

[1] https://github.com/haskell/haddock/pulls
-------------- 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/20160504/ee8f985f/attachment.sig>

From arnaudpourseb at gmail.com  Wed May  4 12:43:27 2016
From: arnaudpourseb at gmail.com (Sebastian)
Date: Wed, 4 May 2016 08:43:27 -0400
Subject: [Maintainer needed] Actively maintained Haddock are happy Haddock
In-Reply-To: <874mae6qtr.fsf@smart-cactus.org>
References: <874mae6qtr.fsf@smart-cactus.org>
Message-ID: <CAD27H6KNK7bgXJXQybRrYZvNSpojv70w0EsFHCvfqEE=5w7Phg@mail.gmail.com>

Hello Ben,

If that's ok I'd be happy to take over the maintenance of Haddock.

Sebastian M?ric de Bellefon (@Helkafen)

On Wed, May 4, 2016 at 6:49 AM, Ben Gamari <ben at well-typed.com> wrote:

> tl;dr. Our Haddock need a dedicated maintainer responsible for their
>        care and feeding. Would you like to move forward a critical piece
>        of infrastructure used on a daily basis by thousands of
>        Haskellers? Let us know if so.
>
>
> Hello everyone,
>
> While for several years Mateusz Kowalczyk and Simon Hengel have done an
> admirable job in serving as comaintainers of the Haddock documentation
> tool, they have both indicated that they no longer have the time to
> continue to be active in this role. They both deserve our thanks for
> their service.
>
> While Matthew Pickering and I have tried to pick up some of the
> Haddock's maintenance load in the meantime, we really need a dedicated
> maintainer to ensure that Haddock continues to swim along healthfully.
> At the moment there are over 150 open tickets in the issue tracker [1],
> an open call for a stable release, and 4 patches in need of review. We
> currently lack the time to get on top of such a load.
>
> In particular, Haddock need someone to take ownership of the management
> of the project: this person would keep an eye on (and preferably pare
> down) the issue tracker (which typically isn't very active, happily),
> guide new contributors, and manage releases. This is an opportunity to
> drive forward a project used on a daily basis by a significant fraction
> of Haskellers.
>
> If you think you might be interested in serving in this role, please let
> us know. Thanks!
>
> Cheers,
>
> - Ben
>
> [1] https://github.com/haskell/haddock/pulls
>
> _______________________________________________
> 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/20160504/93e1c6eb/attachment.html>

From ben at well-typed.com  Thu May  5 07:08:07 2016
From: ben at well-typed.com (Ben Gamari)
Date: Thu, 05 May 2016 09:08:07 +0200
Subject: Generics performance
Message-ID: <87bn4l6kyw.fsf@smart-cactus.org>

Hi Ryan!

As you may know, we are encouraging contributors to view the 8.2 release
as a consolidation release, using it as an opportunity to optimize,
stabilize, document, and refine existing features instead of introducing
new ones.

It seems like there is plenty of optimization that could be done in your
area of generics. In particular #5642 and #11991 are quite relevant and
have been felt by a fair number of users. While compiling derived
Generic instances can necessarily produce quadratic code (see
ticket:5642#comment:8), the costs that we are seeing do seem a bit high
so perhaps there are some constant factors that we can knock down.
However, working this out will require a concerted effort.

Would you be interested in picking up this issue as a task for 8.2?

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/20160505/1d88dfa0/attachment.sig>

From ben at well-typed.com  Thu May  5 07:30:25 2016
From: ben at well-typed.com (Ben Gamari)
Date: Thu, 05 May 2016 09:30:25 +0200
Subject: [Haskell-cafe] Call for Contributions - Haskell Communities and
 Activities Report, May 2016 edition (30th edition)
In-Reply-To: <87wpne6od3.fsf@smart-cactus.org>
References: <CAOMsUMKuybJx6G8wnSa5kHvsn654iwRWSsm2nV61OU6wuBiedA@mail.gmail.com>
 <87wpne6od3.fsf@smart-cactus.org>
Message-ID: <878tzp6jxq.fsf@smart-cactus.org>

Ben Gamari <ben at well-typed.com> writes:

> [ Unknown signature status ]
> Mihai Maruseac <mihai.maruseac at gmail.com> writes:
>
>> Dear all,
>>
>> It's that time of the year again (https://ro-che.info/ccc/16). :)
>>
>> We would like to collect contributions for the 30th edition of the
>>
> Hello Mihai,
>
> Here is GHC's contribution to the current HCAR. Let me know if you'd
> like me to make any revisions. Sorry for the late submission!
>
Hi Mihai,

If possible, it would be great if you could instead use this revised
HCAR text as GHC's submission. This includes a few late amendments that
would be nice to have.

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/20160505/d3bc8710/attachment-0001.sig>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hcar.tex
Type: text/x-tex
Size: 19003 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160505/d3bc8710/attachment-0001.tex>

From ben at well-typed.com  Thu May  5 12:52:45 2016
From: ben at well-typed.com (Ben Gamari)
Date: Thu, 05 May 2016 14:52:45 +0200
Subject: Looking for GHC compile-time performance tests
Message-ID: <87r3dg650i.fsf@smart-cactus.org>

tl;dr. Do you have a Haskell project which GHC now compiles more slowly
       than in the past? If you would like to see your program's
       compilation time improve in 8.2, reduce it to a minimal testcase,
       and provide it to us via Trac.


Good news everyone,

GHC 8.2 will be a release largely targetting consolidation instead of
new features. In particular, we will focus on compiler performance
issues.

One of the challenges of this task is knowing in which ways GHC has
regressed. It is currently hard to know how much of the apparent
compiler performance regression is due to GHC getting slower and how
much is due to users demanding more of it.

To better understand the performance of our compiler, we would like to
collect modern Haskell code samples that exhibit compile-time
performance issues (either regressions or otherwise).

For this we are asking for your help: we are looking for projects that,

 * are small-to-moderate-sized Haskell programs which you believe have
   regressed in compile time in the last few GHC releases

 * have minimal build dependencies, in the ideal case none outside of
   the standard GHC boot libraries

 * can be licensed for use under 3-clause BSD

In some cases we may also be able to make use of examples with a few
library dependencies that are necessary to demonstrate the performance
issue (for instance, a suspected issue stemming from stream fusion
requiring Conduit).

For performance issues exhibiting non-linear scaling in some quantity
(e.g. the size of a type in the program), it would be extremely helpful
if the testcase exposed a "knob" demonstrating this scaling.

So, if you would like to see your program's compilation time improve
in GHC 8.2, put some time into reducing it to something minimal, submit
it to us via a Trac ticket, and let us know in this thread.

Thanks for your help!

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/20160505/24a17d65/attachment.sig>

From ben at well-typed.com  Thu May  5 12:56:13 2016
From: ben at well-typed.com (Ben Gamari)
Date: Thu, 05 May 2016 14:56:13 +0200
Subject: [Haskell-cafe] Call for Contributions - Haskell Communities and
 Activities Report, May 2016 edition (30th edition)
In-Reply-To: <CAOMsUMKgaPeobkxQrc67qbfmq2McFOEfE1wTk_u11L1mJwe3mg@mail.gmail.com>
References: <CAOMsUMKuybJx6G8wnSa5kHvsn654iwRWSsm2nV61OU6wuBiedA@mail.gmail.com>
 <87wpne6od3.fsf@smart-cactus.org> <878tzp6jxq.fsf@smart-cactus.org>
 <CAOMsUMKgaPeobkxQrc67qbfmq2McFOEfE1wTk_u11L1mJwe3mg@mail.gmail.com>
Message-ID: <87oa8k64uq.fsf@smart-cactus.org>

Mihai Maruseac <mihai.maruseac at gmail.com> writes:

> Hi,
>
> Thanks for the entry. In the past, I was copying the text at
> https://ghc.haskell.org/trac/ghc/wiki/Status/May16 (with the
> corresponding different date at the end) and formatting it in LaTeX.
> Now I got a tex file which looks exactly like the text in the Trac
> wiki. If not mentioned otherwise, I guess I'll use the .tex file,
> since it will be easier.
>
Ahh, I see; thanks for letting me know!

I think this time around it would be better you use the TeX source I
provided as I made a few formatting improvements over the Trac document.

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/20160505/751b27b7/attachment.sig>

From ezyang at mit.edu  Thu May  5 23:20:46 2016
From: ezyang at mit.edu (Edward Z. Yang)
Date: Thu, 05 May 2016 16:20:46 -0700
Subject: Determining if an instance is provided by the environment
Message-ID: <1462489986-sup-9818@sabre>

Hello all,

Suppose I have a ClsInst from typechecking the following instance
declaration:

    instance Show [Char] -- i.e. String

I'd now like to answer the question: "Is this instance 'provided'
by the instance environment?"  For example, this instance is provided
given that I have these two instances in the environment:

    instance Show a => Show [a] -- (1)
    instance Show Char          -- (2)

However, if I have just instance (1) in the environment, it's not
provided (and if you tried to use show "foo", you'd get the error
that Char is not an instance of Show.)

Is there are convenient way to do this from TcM?  With 'tcMatchTys'
and I can easily test if there is some instance in the environment
which *matches* my instance head (e.g., Show [a] matches Show [Char])
but this doesn't tell me if all the resulting constraints are
solvable.

Thanks,
Edward

From simonpj at microsoft.com  Fri May  6 09:00:11 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 6 May 2016 09:00:11 +0000
Subject: pmcheck/T11195
Message-ID: <eddced3e5e254935b35348e6c0001f27@DB4PR30MB030.064d.mgd.msft.net>

Harbourmaster is failing (?Killed?) on pmcheck/should_compile/T11195.
Are others finding this?  What should we do?
SImon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160506/df9a8772/attachment.html>

From simonpj at microsoft.com  Fri May  6 09:05:31 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 6 May 2016 09:05:31 +0000
Subject: Determining if an instance is provided by the environment
In-Reply-To: <1462489986-sup-9818@sabre>
References: <1462489986-sup-9818@sabre>
Message-ID: <27d11f3496bf4fdd8b75c7e88bca3629@DB4PR30MB030.064d.mgd.msft.net>

You probably want a variant on TcDeriv.simplifyDeriv, shorn of its complex error reporting.

Simon

|  -----Original Message-----
|  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
|  Edward Z. Yang
|  Sent: 06 May 2016 00:21
|  To: ghc-devs <ghc-devs at haskell.org>
|  Subject: Determining if an instance is provided by the environment
|  
|  Hello all,
|  
|  Suppose I have a ClsInst from typechecking the following instance
|  declaration:
|  
|      instance Show [Char] -- i.e. String
|  
|  I'd now like to answer the question: "Is this instance 'provided'
|  by the instance environment?"  For example, this instance is provided
|  given that I have these two instances in the environment:
|  
|      instance Show a => Show [a] -- (1)
|      instance Show Char          -- (2)
|  
|  However, if I have just instance (1) in the environment, it's not
|  provided (and if you tried to use show "foo", you'd get the error that
|  Char is not an instance of Show.)
|  
|  Is there are convenient way to do this from TcM?  With 'tcMatchTys'
|  and I can easily test if there is some instance in the environment
|  which *matches* my instance head (e.g., Show [a] matches Show [Char])
|  but this doesn't tell me if all the resulting constraints are solvable.
|  
|  Thanks,
|  Edward
|  _______________________________________________
|  ghc-devs mailing list
|  ghc-devs at haskell.org
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.ha
|  skell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
|  devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c8c304d9b355244c6
|  ee7208d3753be740%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=iWdrnb6hC
|  8pexyVkWNG22G%2fgdO10tCBy8nuCxhnO0M8%3d

From alois.cochard at gmail.com  Fri May  6 11:40:35 2016
From: alois.cochard at gmail.com (Alois Cochard)
Date: Fri, 6 May 2016 13:40:35 +0200
Subject: Mentor for a JVM backend for GHC
In-Reply-To: <CANij+eRbvRcNGbMx23xGw2Q8LjZ4x4AzBwVyoi5oM5KfvF+A+Q@mail.gmail.com>
References: <CANij+eRbvRcNGbMx23xGw2Q8LjZ4x4AzBwVyoi5oM5KfvF+A+Q@mail.gmail.com>
Message-ID: <CAJHA+wogRXaQ3mdxV_PV7REwBY-4-E+7n79cMcx7NBQ+B0nkjg@mail.gmail.com>

Hi Rahul,

Exicting to see other folks interested into doing this!

I did started an exprimental project on this at the end of last year, sadly
I did not had much time to work on it and it was closed sources, I just
opened it, so maybe we can share/reuse stuff?

Please take a look at this repository: https://github.com/aloiscochard/kuna

The most useful part is probaly the java assembly, I was not so happy of
hs-java so I rewrote an assembler from scratch.

To be honest I have not yet looked in your code, but I'll definitely will.

Let's keep in touch!

Cheers

On 2 May 2016 at 17:26, Rahul Muttineni <rahulmutt at gmail.com> wrote:

> Hi GHC Developers,
>
> I've started working on a JVM backend for GHC [1] and I'd love to work on
> it as my Summer of Haskell project.
>
> Currently, the build system is setup using a mix of Shake (for the RTS
> build) and Stack (for the main compiler build) and I ensure that most
> commits build successfully. I have ported the core part of the scheduler
> and ported over the fundamental types (Capability, StgTSO, Task,
> StgClosure, etc.) taking advantage of OOP in the implementation when I
> could.
>
> Additionally, I performed a non-trivial refactor of the hs-java package
> adding support for inner classes and fields which was very cumbersome to do
> in the original package. On the frontend, I have tapped into the STG code
> from the GHC 7.10.3 library and setup a CodeGen monad for generating JVM
> bytecode. The main task of generating the actual bytecode, porting the more
> critical parts of the RTS, and adding support for the threaded RTS remain.
>
> The strategy for compilation is as follows:
> - Intercept the STG code in the GHC pipeline
> - Convert from STG->JVM bytecode [2] in a similar manner as STG->Cmm
> preserving semantics as best as possible [3]
> - Port the GHC RTS (normal & threaded) to Java [4]
> - Put all the generated class files + RTS into a single jar to be run
> directly by the JVM.
>
> My objectives for the project during the summer are:
> - To implement the compilation strategy mentioned above
> - Implement the Java FFI for foreign imports. [5]
> - Implement the most important [6] PrimOps that GHC supports.
> - Port the base package replacing the C FFI imports with equivalent Java
> FFI imports. [7]
>
> A little bit about myself: I spent a lot of time studying functional
> language implementation by reading SPJ's famous book and reading research
> papers on related topics last summer as self-study.
>
> I took a break and resumed a couple months ago where I spent a lot of time
> plowing through the STG->Cmm code generator as well as the RTS and going
> back and forth between them to get a clear understanding of how everything
> works.
>
> Moreover, I compiled simple Haskell programs and observed the STG, Cmm,
> and assembly output (by decompiling the final executable with objdump) to
> understand bits of the code generator where the source code wasn't that
> clear.
>
> I also spent a great deal of time studying the JVM internals, reading the
> JVM spec, looking for any new features that could facilitate a high
> performance implementation [8].
>
> It would be great if someone with an understanding of nuances of the RTS
> and code generator could mentor me for this project. It has been a blast so
> far learning all the prerequisites and contemplating the design. I'd be
> very excited to take this on as a summer project.
>
> Also, given that I have hardly 5 days remaining, does anyone have
> suggestions on how I can structure the proposal without getting into too
> many details? There are still some parts of the design I haven't figured
> out, but I know I could find some solution when I get to it during the
> porting process.
>
> Thanks,
> Rahul Muttineni
>
> [1] http://github.com/rahulmutt/ghcvm
>
> [2] I intend to organically derive an IR at a later stage to allow for
> some optimizations by looking at the final working implementation without
> an IR and looking for patterns of repeated sequences of bytecode and
> assigning each sequence its own instruction in the IR.
>
> [3] Obviously, the lack of control of memory layouts (besides allocating
> off the JVM heap using DirectByteBuffers) and lack of general tail calls
> makes it tough to match the semantics of Cmm, but there are many solutions
> around it, as can be found in the few papers on translating STG to Java/JVM
> bytecode.
>
> [4] This is the GHC RTS without GC and profiling since the JVM has great
> support for those already. Also, lots of care must be taken to ensure that
> the lock semantics stays in tact during the port.
>
> [5] foreign exports will be dealt at a later stage, but I am taking care
> of naming the closures nicely so that in the future you don't have to type
> long names like the labels GHC compiles to call a Haskell function in Java.
>
> [6] Basically all the PrimOps that would be required to provide plumbing
> for the Prelude functions that can compile beginner-level programs found in
> books such as Learn You a Haskell for Great Good.
>
> [7] I know that it's a lot more complicated than just replacing FFI calls.
> I'd have to change around a lot of the code in base as well.
>
> [8] I found that the new "invokedynamic" instruction as well as the
> MethodHandle API (something like function pointers) that were introduced in
> JDK 7 could fit the bill. But as of now, I want to get a baseline
> implementation that is compatible with Java 5 so I will not be utilizing
> these newer features.
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>


-- 
*?\ois*
http://twitter.com/aloiscochard
http://github.com/aloiscochard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160506/7f111dd6/attachment.html>

From ben at well-typed.com  Fri May  6 17:58:19 2016
From: ben at well-typed.com (Ben Gamari)
Date: Fri, 06 May 2016 19:58:19 +0200
Subject: [Maintainer needed] Actively maintained Haddock are happy Haddock
In-Reply-To: <CAD27H6KNK7bgXJXQybRrYZvNSpojv70w0EsFHCvfqEE=5w7Phg@mail.gmail.com>
References: <874mae6qtr.fsf@smart-cactus.org>
 <CAD27H6KNK7bgXJXQybRrYZvNSpojv70w0EsFHCvfqEE=5w7Phg@mail.gmail.com>
Message-ID: <87zis3m5l0.fsf@smart-cactus.org>

Sebastian <arnaudpourseb at gmail.com> writes:

> Hello Ben,
>
Hi Sebastian,

Sorry for the belated response.

> If that's ok I'd be happy to take over the maintenance of Haddock.
>
Sure, that would be great. I can give you the keys in a bit.

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/20160506/a883b02d/attachment.sig>

From ezyang at mit.edu  Fri May  6 23:40:31 2016
From: ezyang at mit.edu (Edward Z. Yang)
Date: Fri, 06 May 2016 16:40:31 -0700
Subject: Determining if an instance is provided by the environment
In-Reply-To: <27d11f3496bf4fdd8b75c7e88bca3629@DB4PR30MB030.064d.mgd.msft.net>
References: <1462489986-sup-9818@sabre>
 <27d11f3496bf4fdd8b75c7e88bca3629@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <1462578011-sup-7528@sabre>

Thanks Simon, that has all the ingredients I need.

I wrote some more docs for the function: https://phabricator.haskell.org/D2180

Edward

Excerpts from Simon Peyton Jones's message of 2016-05-06 02:05:31 -0700:
> You probably want a variant on TcDeriv.simplifyDeriv, shorn of its complex error reporting.
> 
> Simon
> 
> |  -----Original Message-----
> |  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
> |  Edward Z. Yang
> |  Sent: 06 May 2016 00:21
> |  To: ghc-devs <ghc-devs at haskell.org>
> |  Subject: Determining if an instance is provided by the environment
> |  
> |  Hello all,
> |  
> |  Suppose I have a ClsInst from typechecking the following instance
> |  declaration:
> |  
> |      instance Show [Char] -- i.e. String
> |  
> |  I'd now like to answer the question: "Is this instance 'provided'
> |  by the instance environment?"  For example, this instance is provided
> |  given that I have these two instances in the environment:
> |  
> |      instance Show a => Show [a] -- (1)
> |      instance Show Char          -- (2)
> |  
> |  However, if I have just instance (1) in the environment, it's not
> |  provided (and if you tried to use show "foo", you'd get the error that
> |  Char is not an instance of Show.)
> |  
> |  Is there are convenient way to do this from TcM?  With 'tcMatchTys'
> |  and I can easily test if there is some instance in the environment
> |  which *matches* my instance head (e.g., Show [a] matches Show [Char])
> |  but this doesn't tell me if all the resulting constraints are solvable.
> |  
> |  Thanks,
> |  Edward
> |  _______________________________________________
> |  ghc-devs mailing list
> |  ghc-devs at haskell.org
> |  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.ha
> |  skell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
> |  devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c8c304d9b355244c6
> |  ee7208d3753be740%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=iWdrnb6hC
> |  8pexyVkWNG22G%2fgdO10tCBy8nuCxhnO0M8%3d

From dsf at seereason.com  Sat May  7 00:06:41 2016
From: dsf at seereason.com (David Fox)
Date: Fri, 6 May 2016 17:06:41 -0700
Subject: Determining if an instance is provided by the environment
In-Reply-To: <1462578011-sup-7528@sabre>
References: <1462489986-sup-9818@sabre>
 <27d11f3496bf4fdd8b75c7e88bca3629@DB4PR30MB030.064d.mgd.msft.net>
 <1462578011-sup-7528@sabre>
Message-ID: <CAM8C2CDQwyx6vLEZKD__FCjVBoDDowxB=znOWOv7-qKnNqw3bg@mail.gmail.com>

Is there a way to connect this to template-haskell or haskell-src-exts code?

On Fri, May 6, 2016 at 4:40 PM, Edward Z. Yang <ezyang at mit.edu> wrote:

> Thanks Simon, that has all the ingredients I need.
>
> I wrote some more docs for the function:
> https://phabricator.haskell.org/D2180
>
> Edward
>
> Excerpts from Simon Peyton Jones's message of 2016-05-06 02:05:31 -0700:
> > You probably want a variant on TcDeriv.simplifyDeriv, shorn of its
> complex error reporting.
> >
> > Simon
> >
> > |  -----Original Message-----
> > |  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
> > |  Edward Z. Yang
> > |  Sent: 06 May 2016 00:21
> > |  To: ghc-devs <ghc-devs at haskell.org>
> > |  Subject: Determining if an instance is provided by the environment
> > |
> > |  Hello all,
> > |
> > |  Suppose I have a ClsInst from typechecking the following instance
> > |  declaration:
> > |
> > |      instance Show [Char] -- i.e. String
> > |
> > |  I'd now like to answer the question: "Is this instance 'provided'
> > |  by the instance environment?"  For example, this instance is provided
> > |  given that I have these two instances in the environment:
> > |
> > |      instance Show a => Show [a] -- (1)
> > |      instance Show Char          -- (2)
> > |
> > |  However, if I have just instance (1) in the environment, it's not
> > |  provided (and if you tried to use show "foo", you'd get the error that
> > |  Char is not an instance of Show.)
> > |
> > |  Is there are convenient way to do this from TcM?  With 'tcMatchTys'
> > |  and I can easily test if there is some instance in the environment
> > |  which *matches* my instance head (e.g., Show [a] matches Show [Char])
> > |  but this doesn't tell me if all the resulting constraints are
> solvable.
> > |
> > |  Thanks,
> > |  Edward
> > |  _______________________________________________
> > |  ghc-devs mailing list
> > |  ghc-devs at haskell.org
> > |
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.ha
> > |  skell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
> > |  devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com
> %7c8c304d9b355244c6
> > |
> ee7208d3753be740%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=iWdrnb6hC
> > |  8pexyVkWNG22G%2fgdO10tCBy8nuCxhnO0M8%3d
> _______________________________________________
> 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/20160506/c97e9459/attachment.html>

From ezyang at mit.edu  Sat May  7 00:33:33 2016
From: ezyang at mit.edu (Edward Z. Yang)
Date: Fri, 06 May 2016 17:33:33 -0700
Subject: Determining if an instance is provided by the environment
In-Reply-To: <CAM8C2CDQwyx6vLEZKD__FCjVBoDDowxB=znOWOv7-qKnNqw3bg@mail.gmail.com>
References: <1462489986-sup-9818@sabre>
 <27d11f3496bf4fdd8b75c7e88bca3629@DB4PR30MB030.064d.mgd.msft.net>
 <1462578011-sup-7528@sabre>
 <CAM8C2CDQwyx6vLEZKD__FCjVBoDDowxB=znOWOv7-qKnNqw3bg@mail.gmail.com>
Message-ID: <1462580960-sup-2046@sabre>

Well, I have to write the new variant of this function :)

Simon, I ran into a minor complication: if my instance is
something like:

    instance Show a => Show [a]

I think I need to pass in a 'CtGiven' for 'Show a'.  However,
I don't know what to pass as the evidence to the 'CtGiven'
constraints.  My guess is that it doesn't matter?

Edward

Excerpts from David Fox's message of 2016-05-06 17:06:41 -0700:
> Is there a way to connect this to template-haskell or haskell-src-exts code?
> 
> On Fri, May 6, 2016 at 4:40 PM, Edward Z. Yang <ezyang at mit.edu> wrote:
> 
> > Thanks Simon, that has all the ingredients I need.
> >
> > I wrote some more docs for the function:
> > https://phabricator.haskell.org/D2180
> >
> > Edward
> >
> > Excerpts from Simon Peyton Jones's message of 2016-05-06 02:05:31 -0700:
> > > You probably want a variant on TcDeriv.simplifyDeriv, shorn of its
> > complex error reporting.
> > >
> > > Simon
> > >
> > > |  -----Original Message-----
> > > |  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
> > > |  Edward Z. Yang
> > > |  Sent: 06 May 2016 00:21
> > > |  To: ghc-devs <ghc-devs at haskell.org>
> > > |  Subject: Determining if an instance is provided by the environment
> > > |
> > > |  Hello all,
> > > |
> > > |  Suppose I have a ClsInst from typechecking the following instance
> > > |  declaration:
> > > |
> > > |      instance Show [Char] -- i.e. String
> > > |
> > > |  I'd now like to answer the question: "Is this instance 'provided'
> > > |  by the instance environment?"  For example, this instance is provided
> > > |  given that I have these two instances in the environment:
> > > |
> > > |      instance Show a => Show [a] -- (1)
> > > |      instance Show Char          -- (2)
> > > |
> > > |  However, if I have just instance (1) in the environment, it's not
> > > |  provided (and if you tried to use show "foo", you'd get the error that
> > > |  Char is not an instance of Show.)
> > > |
> > > |  Is there are convenient way to do this from TcM?  With 'tcMatchTys'
> > > |  and I can easily test if there is some instance in the environment
> > > |  which *matches* my instance head (e.g., Show [a] matches Show [Char])
> > > |  but this doesn't tell me if all the resulting constraints are
> > solvable.
> > > |
> > > |  Thanks,
> > > |  Edward
> > > |  _______________________________________________
> > > |  ghc-devs mailing list
> > > |  ghc-devs at haskell.org
> > > |
> > https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.ha
> > > |  skell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
> > > |  devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com
> > %7c8c304d9b355244c6
> > > |
> > ee7208d3753be740%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=iWdrnb6hC
> > > |  8pexyVkWNG22G%2fgdO10tCBy8nuCxhnO0M8%3d
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >

From tjakway at nyu.edu  Sat May  7 15:32:12 2016
From: tjakway at nyu.edu (Thomas Jakway)
Date: Sat, 7 May 2016 11:32:12 -0400
Subject: Mentor for a JVM backend for GHC
In-Reply-To: <CANij+eRbvRcNGbMx23xGw2Q8LjZ4x4AzBwVyoi5oM5KfvF+A+Q@mail.gmail.com>
References: <CANij+eRbvRcNGbMx23xGw2Q8LjZ4x4AzBwVyoi5oM5KfvF+A+Q@mail.gmail.com>
Message-ID: <572E0A7C.8090208@nyu.edu>

This is a strange coincidence.  I'm definitely no expert GHC hacker but 
I started (highly preliminary) work on a JVM backend for GHC a few weeks 
ago.  It's here: 
https://github.com/tjakway/ghcjvm/tree/jvm/compiler/jvmGen/Jvm
(The memory runtime is here: https://github.com/tjakway/lljvm)

I'm very new to this so pardon my ignorance, but I don't understand what 
the benefit is of intercepting STG code and translating that to bytecode 
vs. translating Cmm to bytecode (or Jasmin assembly, as I'd prefer)?  It 
seems like Cmm is designed for backends and the obvious choice.  Or have 
I got this really mixed up?

I hope this isn't out of line considering my overall lack of experience 
but I think I can give some advice:

  * read the JVM 7 spec cover-to-cover.
  * I *_highly_* suggest outputting Jasmin
    <http://web.mit.edu/javadev/packages/jasmin/doc/> assembly instead
    of raw bytecode.  The classfile format is complicated and you will
    have to essentially rewrite Jasmin in Haskell if you don't want to
    reuse it.  Jasmin is also the de facto standard assembler and much
    more thoroughly tested than any homegrown solution we might make.
  * read the LLVM code generator.  This project is more like the LLVM
    backend than the native code generator.
  * Don't go for speed.  The approach that I've begun is to emulate a C
    stack and memory system the RTS can run on top of
    (https://github.com/tjakway/lljvm/blob/master/src/main/java/lljvm/runtime/Memory.java).
    This will make getting /something/ working much faster and also
    solves the problem of how to deal with memcpy/memset/memmove on the
    JVM.  This will of course be _very_ slow (I think) and is not a
    permanent solution.  Can't do everything at once.  Any other
    approach will probably require rewriting the entire RTS from the
    beginning.
  * I don't think Frege is especially useful to this project, though I'd
    love to be proven wrong.  Frege's compilation model is completely
    different from GHC's: they compile Haskell to Java and then send
    that to javac.  Porting GHC to the JVM is really more like writing a
    Cmm to JVM compiler.


I've heard of the LambdaVM project but couldn't find the actual code 
anywhere.  The site where it was hosted appears to be offline.  I'd 
certainly like to look at it if anyone knows where to find it.

Information on Jasmin:
http://web.mit.edu/javadev/packages/jasmin/doc/
http://web.mit.edu/javadev/packages/jasmin/doc/instructions.html
http://web.mit.edu/javadev/packages/jasmin/doc/about.html

Once you've tried manually dealing with constant pools you'll appreciate 
Jonathan Meyer's work!

I forked davidar's <https://github.com/davidar> extended version of 
Jasmin.  The differences versus the original Jasmin are detailed here 
<https://github.com/davidar/jasmin/blob/master/html2x/xt.html>. Some 
nice additions:

  * supports invokedynamic
  * supports .annotation, .inner, .attribute, .deprecated directives
  * better handling of the ldc_w instruction
  * multi-line fields
  * .debug directives
  * signatures for local variables
  * .bytecode directive to specify bytecode version
  * (most importantly, I think): support for the StackMap attribute.  If
    we eventually want to use new JVM instructions like invokedynamic,
    we *need* stack map frames or the JVM will reject our bytecode.  JVM
    7 has options to bypass this (but it's a hack), but they're
    deprecated and I believe not optional going forward.  Alternatively
    we can stick with older bytecode versions indefinitely and not use
    the new features.

(Just to be clear, I forked it in case it was deleted.  I didn't write 
those features, the credit belongs to him).

I think the biggest risk is taking too much on at once.  Any one of 
these subtasks, writing a bytecode assembler, porting the RTS, etc. 
could consume the whole summer if you're not careful.

I'd love to help out with this project!

Sincerely,
Thomas Jakway

-------

Woops, after scrolling back through the emails it looks like someone 
sent out the LambdaVM source.  I'll have to take a look at that.



On 05/02/2016 11:26 AM, Rahul Muttineni wrote:
> Hi GHC Developers,
>
> I've started working on a JVM backend for GHC [1] and I'd love to work 
> on it as my Summer of Haskell project.
>
> Currently, the build system is setup using a mix of Shake (for the RTS 
> build) and Stack (for the main compiler build) and I ensure that most 
> commits build successfully. I have ported the core part of the 
> scheduler and ported over the fundamental types (Capability, StgTSO, 
> Task, StgClosure, etc.) taking advantage of OOP in the implementation 
> when I could.
>
> Additionally, I performed a non-trivial refactor of the hs-java 
> package adding support for inner classes and fields which was very 
> cumbersome to do in the original package. On the frontend, I have 
> tapped into the STG code from the GHC 7.10.3 library and setup a 
> CodeGen monad for generating JVM bytecode. The main task of generating 
> the actual bytecode, porting the more critical parts of the RTS, and 
> adding support for the threaded RTS remain.
>
> The strategy for compilation is as follows:
> - Intercept the STG code in the GHC pipeline
> - Convert from STG->JVM bytecode [2] in a similar manner as STG->Cmm 
> preserving semantics as best as possible [3]
> - Port the GHC RTS (normal & threaded) to Java [4]
> - Put all the generated class files + RTS into a single jar to be run 
> directly by the JVM.
>
> My objectives for the project during the summer are:
> - To implement the compilation strategy mentioned above
> - Implement the Java FFI for foreign imports. [5]
> - Implement the most important [6] PrimOps that GHC supports.
> - Port the base package replacing the C FFI imports with equivalent 
> Java FFI imports. [7]
>
> A little bit about myself: I spent a lot of time studying functional 
> language implementation by reading SPJ's famous book and reading 
> research papers on related topics last summer as self-study.
>
> I took a break and resumed a couple months ago where I spent a lot of 
> time plowing through the STG->Cmm code generator as well as the RTS 
> and going back and forth between them to get a clear understanding of 
> how everything works.
>
> Moreover, I compiled simple Haskell programs and observed the STG, 
> Cmm, and assembly output (by decompiling the final executable with 
> objdump) to understand bits of the code generator where the source 
> code wasn't that clear.
>
> I also spent a great deal of time studying the JVM internals, reading 
> the JVM spec, looking for any new features that could facilitate a 
> high performance implementation [8].
>
> It would be great if someone with an understanding of nuances of the 
> RTS and code generator could mentor me for this project. It has been a 
> blast so far learning all the prerequisites and contemplating the 
> design. I'd be very excited to take this on as a summer project.
>
> Also, given that I have hardly 5 days remaining, does anyone have 
> suggestions on how I can structure the proposal without getting into 
> too many details? There are still some parts of the design I haven't 
> figured out, but I know I could find some solution when I get to it 
> during the porting process.
>
> Thanks,
> Rahul Muttineni
>
> [1] http://github.com/rahulmutt/ghcvm
>
> [2] I intend to organically derive an IR at a later stage to allow for 
> some optimizations by looking at the final working implementation 
> without an IR and looking for patterns of repeated sequences of 
> bytecode and assigning each sequence its own instruction in the IR.
>
> [3] Obviously, the lack of control of memory layouts (besides 
> allocating off the JVM heap using DirectByteBuffers) and lack of 
> general tail calls makes it tough to match the semantics of Cmm, but 
> there are many solutions around it, as can be found in the few papers 
> on translating STG to Java/JVM bytecode.
>
> [4] This is the GHC RTS without GC and profiling since the JVM has 
> great support for those already. Also, lots of care must be taken to 
> ensure that the lock semantics stays in tact during the port.
>
> [5] foreign exports will be dealt at a later stage, but I am taking 
> care of naming the closures nicely so that in the future you don't 
> have to type long names like the labels GHC compiles to call a Haskell 
> function in Java.
>
> [6] Basically all the PrimOps that would be required to provide 
> plumbing for the Prelude functions that can compile beginner-level 
> programs found in books such as Learn You a Haskell for Great Good.
>
> [7] I know that it's a lot more complicated than just replacing FFI 
> calls. I'd have to change around a lot of the code in base as well.
>
> [8] I found that the new "invokedynamic" instruction as well as the 
> MethodHandle API (something like function pointers) that were 
> introduced in JDK 7 could fit the bill. But as of now, I want to get a 
> baseline implementation that is compatible with Java 5 so I will not 
> be utilizing these newer features.
>
>
>
> _______________________________________________
> 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/20160507/fdf5130a/attachment.html>

From ekmett at gmail.com  Sat May  7 16:19:17 2016
From: ekmett at gmail.com (Edward Kmett)
Date: Sat, 7 May 2016 12:19:17 -0400
Subject: Mentor for a JVM backend for GHC
In-Reply-To: <572E0A7C.8090208@nyu.edu>
References: <CANij+eRbvRcNGbMx23xGw2Q8LjZ4x4AzBwVyoi5oM5KfvF+A+Q@mail.gmail.com>
 <572E0A7C.8090208@nyu.edu>
Message-ID: <CAJumaK_fzv9+N5MwWNtB_srK3Y3cPDo14CbT9huevk4Jn1xziw@mail.gmail.com>

By the time it has made it down to Cmm there are a lot of assumptions
about layout in memory -- everything is assumed to be a flat object
made out of 32-bit or 64-bit slots. These assumptions aren't really
suitable for the JVM.

-Edward

On Sat, May 7, 2016 at 11:32 AM, Thomas Jakway <tjakway at nyu.edu> wrote:
> This is a strange coincidence.  I'm definitely no expert GHC hacker but I
> started (highly preliminary) work on a JVM backend for GHC a few weeks ago.
> It's here: https://github.com/tjakway/ghcjvm/tree/jvm/compiler/jvmGen/Jvm
> (The memory runtime is here: https://github.com/tjakway/lljvm)
>
> I'm very new to this so pardon my ignorance, but I don't understand what the
> benefit is of intercepting STG code and translating that to bytecode vs.
> translating Cmm to bytecode (or Jasmin assembly, as I'd prefer)?  It seems
> like Cmm is designed for backends and the obvious choice.  Or have I got
> this really mixed up?
>
> I hope this isn't out of line considering my overall lack of experience but
> I think I can give some advice:
>
> read the JVM 7 spec cover-to-cover.
> I highly suggest outputting Jasmin assembly instead of raw bytecode.  The
> classfile format is complicated and you will have to essentially rewrite
> Jasmin in Haskell if you don't want to reuse it.  Jasmin is also the de
> facto standard assembler and much more thoroughly tested than any homegrown
> solution we might make.
> read the LLVM code generator.  This project is more like the LLVM backend
> than the native code generator.
> Don't go for speed.  The approach that I've begun is to emulate a C stack
> and memory system the RTS can run on top of
> (https://github.com/tjakway/lljvm/blob/master/src/main/java/lljvm/runtime/Memory.java).
> This will make getting something working much faster and also solves the
> problem of how to deal with memcpy/memset/memmove on the JVM.  This will of
> course be very slow (I think) and is not a permanent solution.  Can't do
> everything at once.  Any other approach will probably require rewriting the
> entire RTS from the beginning.
> I don't think Frege is especially useful to this project, though I'd love to
> be proven wrong.  Frege's compilation model is completely different from
> GHC's: they compile Haskell to Java and then send that to javac.  Porting
> GHC to the JVM is really more like writing a Cmm to JVM compiler.
>
>
> I've heard of the LambdaVM project but couldn't find the actual code
> anywhere.  The site where it was hosted appears to be offline.  I'd
> certainly like to look at it if anyone knows where to find it.
>
> Information on Jasmin:
> http://web.mit.edu/javadev/packages/jasmin/doc/
> http://web.mit.edu/javadev/packages/jasmin/doc/instructions.html
> http://web.mit.edu/javadev/packages/jasmin/doc/about.html
>
> Once you've tried manually dealing with constant pools you'll appreciate
> Jonathan Meyer's work!
>
> I forked davidar's extended version of Jasmin.  The differences versus the
> original Jasmin are detailed here.  Some nice additions:
>
> supports invokedynamic
> supports .annotation, .inner, .attribute, .deprecated directives
> better handling of the ldc_w instruction
> multi-line fields
> .debug directives
> signatures for local variables
> .bytecode directive to specify bytecode version
> (most importantly, I think): support for the StackMap attribute.  If we
> eventually want to use new JVM instructions like invokedynamic, we need
> stack map frames or the JVM will reject our bytecode.  JVM 7 has options to
> bypass this (but it's a hack), but they're deprecated and I believe not
> optional going forward.  Alternatively we can stick with older bytecode
> versions indefinitely and not use the new features.
>
> (Just to be clear, I forked it in case it was deleted.  I didn't write those
> features, the credit belongs to him).
>
> I think the biggest risk is taking too much on at once.  Any one of these
> subtasks, writing a bytecode assembler, porting the RTS, etc. could consume
> the whole summer if you're not careful.
>
> I'd love to help out with this project!
>
> Sincerely,
> Thomas Jakway
>
> -------
>
> Woops, after scrolling back through the emails it looks like someone sent
> out the LambdaVM source.  I'll have to take a look at that.
>
>
>
> On 05/02/2016 11:26 AM, Rahul Muttineni wrote:
>
> Hi GHC Developers,
>
> I've started working on a JVM backend for GHC [1] and I'd love to work on it
> as my Summer of Haskell project.
>
> Currently, the build system is setup using a mix of Shake (for the RTS
> build) and Stack (for the main compiler build) and I ensure that most
> commits build successfully. I have ported the core part of the scheduler and
> ported over the fundamental types (Capability, StgTSO, Task, StgClosure,
> etc.) taking advantage of OOP in the implementation when I could.
>
> Additionally, I performed a non-trivial refactor of the hs-java package
> adding support for inner classes and fields which was very cumbersome to do
> in the original package. On the frontend, I have tapped into the STG code
> from the GHC 7.10.3 library and setup a CodeGen monad for generating JVM
> bytecode. The main task of generating the actual bytecode, porting the more
> critical parts of the RTS, and adding support for the threaded RTS remain.
>
> The strategy for compilation is as follows:
> - Intercept the STG code in the GHC pipeline
> - Convert from STG->JVM bytecode [2] in a similar manner as STG->Cmm
> preserving semantics as best as possible [3]
> - Port the GHC RTS (normal & threaded) to Java [4]
> - Put all the generated class files + RTS into a single jar to be run
> directly by the JVM.
>
> My objectives for the project during the summer are:
> - To implement the compilation strategy mentioned above
> - Implement the Java FFI for foreign imports. [5]
> - Implement the most important [6] PrimOps that GHC supports.
> - Port the base package replacing the C FFI imports with equivalent Java FFI
> imports. [7]
>
> A little bit about myself: I spent a lot of time studying functional
> language implementation by reading SPJ's famous book and reading research
> papers on related topics last summer as self-study.
>
> I took a break and resumed a couple months ago where I spent a lot of time
> plowing through the STG->Cmm code generator as well as the RTS and going
> back and forth between them to get a clear understanding of how everything
> works.
>
> Moreover, I compiled simple Haskell programs and observed the STG, Cmm, and
> assembly output (by decompiling the final executable with objdump) to
> understand bits of the code generator where the source code wasn't that
> clear.
>
> I also spent a great deal of time studying the JVM internals, reading the
> JVM spec, looking for any new features that could facilitate a high
> performance implementation [8].
>
> It would be great if someone with an understanding of nuances of the RTS and
> code generator could mentor me for this project. It has been a blast so far
> learning all the prerequisites and contemplating the design. I'd be very
> excited to take this on as a summer project.
>
> Also, given that I have hardly 5 days remaining, does anyone have
> suggestions on how I can structure the proposal without getting into too
> many details? There are still some parts of the design I haven't figured
> out, but I know I could find some solution when I get to it during the
> porting process.
>
> Thanks,
> Rahul Muttineni
>
> [1] http://github.com/rahulmutt/ghcvm
>
> [2] I intend to organically derive an IR at a later stage to allow for some
> optimizations by looking at the final working implementation without an IR
> and looking for patterns of repeated sequences of bytecode and assigning
> each sequence its own instruction in the IR.
>
> [3] Obviously, the lack of control of memory layouts (besides allocating off
> the JVM heap using DirectByteBuffers) and lack of general tail calls makes
> it tough to match the semantics of Cmm, but there are many solutions around
> it, as can be found in the few papers on translating STG to Java/JVM
> bytecode.
>
> [4] This is the GHC RTS without GC and profiling since the JVM has great
> support for those already. Also, lots of care must be taken to ensure that
> the lock semantics stays in tact during the port.
>
> [5] foreign exports will be dealt at a later stage, but I am taking care of
> naming the closures nicely so that in the future you don't have to type long
> names like the labels GHC compiles to call a Haskell function in Java.
>
> [6] Basically all the PrimOps that would be required to provide plumbing for
> the Prelude functions that can compile beginner-level programs found in
> books such as Learn You a Haskell for Great Good.
>
> [7] I know that it's a lot more complicated than just replacing FFI calls.
> I'd have to change around a lot of the code in base as well.
>
> [8] I found that the new "invokedynamic" instruction as well as the
> MethodHandle API (something like function pointers) that were introduced in
> JDK 7 could fit the bill. But as of now, I want to get a baseline
> implementation that is compatible with Java 5 so I will not be utilizing
> these newer features.
>
>
>
> _______________________________________________
> 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 harendra.kumar at gmail.com  Mon May  9 15:10:01 2016
From: harendra.kumar at gmail.com (Harendra Kumar)
Date: Mon, 9 May 2016 20:40:01 +0530
Subject: suboptimal ghc code generation in IO vs equivalent pure code case
Message-ID: <CAPW+kkZzOWYEf2u5V8nqVb4eYjWt+1dH2gEERv0itM1pcd3o0g@mail.gmail.com>

I have a loop which runs millions of times. For some reason I have to run
it in the IO monad. I noticed that when I convert the code from pure to IO
monad the generated assembly code in essence is almost identical except one
difference where it puts a piece of code in a separate block which is
making a huge difference in performance (4-6x slower).

I want to understand what makes GHC to generate code in this way and if
there is anything that can be done at source level (or ghc option)  to
control that.

The pure code looks like this:

        decomposeChars :: [Char] -> [Char]

        decomposeChars [] = []
        decomposeChars [x] =
            case NFD.isDecomposable x of
                True -> decomposeChars (NFD.decomposeChar x)
                False -> [x]
        decomposeChars (x : xs) = decomposeChars [x] ++ decomposeChars xs

The equivalent IO code is this:

        decomposeStrIO :: [Char] -> IO [Char]

        decomposeStrPtr !p = decomposeStrIO
            where
                decomposeStrIO [] = return []
                decomposeStrIO [x] = do
                    res <- NFD.isDecomposable p x
                    case res of
                        True -> decomposeStrIO (NFD.decomposeChar x)
                        False -> return [x]
                decomposeStrIO (x : xs) = do
                    s1 <- decomposeStrIO [x]
                    s2 <- decomposeStrIO xs
                    return (s1 ++ s2)

The difference is in how the code corresponding to the call to the (++)
operation is generated. In the pure case the (++) operation is inline in
the main loop:

_cn5N:
movq $sat_sn2P_info,-48(%r12)
movq %rax,-32(%r12)
movq %rcx,-24(%r12)
movq $:_con_info,-16(%r12)
movq 16(%rbp),%rax
movq %rax,-8(%r12)
movq $GHC.Types.[]_closure+1,(%r12)
leaq -48(%r12),%rsi
leaq -14(%r12),%r14
addq $40,%rbp
jmp GHC.Base.++_info

In the IO monad version this code is placed in a separate block and a call
is placed in the main loop:

the main loop call site:

_cn6A:
movq $sat_sn3w_info,-24(%r12)
movq 8(%rbp),%rax
movq %rax,-8(%r12)
movq %rbx,(%r12)
leaq -24(%r12),%rbx
addq $40,%rbp
jmp *(%rbp)

out of the line block - the code that was in the main loop in the previous
case is now moved to this block (see label _cn5s below):

sat_sn3w_info:
_cn5p:
leaq -16(%rbp),%rax
cmpq %r15,%rax
jb _cn5q
_cn5r:
addq $24,%r12
cmpq 856(%r13),%r12
ja _cn5t
_cn5s:
movq $stg_upd_frame_info,-16(%rbp)
movq %rbx,-8(%rbp)
movq 16(%rbx),%rax
movq 24(%rbx),%rbx
movq $:_con_info,-16(%r12)
movq %rax,-8(%r12)
movq $GHC.Types.[]_closure+1,(%r12)
movq %rbx,%rsi
leaq -14(%r12),%r14
addq $-16,%rbp
jmp GHC.Base.++_info
_cn5t:
movq $24,904(%r13)
_cn5q:
jmp *-16(%r13)

Except this difference the rest of the assembly looks pretty similar in
both the cases. The corresponding dump-simpl output for the pure case:

          False ->
            ++
              @ Char
              (GHC.Types.: @ Char ww_amuh (GHC.Types.[] @ Char))
              (Data.Unicode.Internal.Normalization.decompose_$sdecompose
                 ipv_smuv ipv1_smuD);

And for the IO monad version:

                False ->
                  case $sa1_sn0g ipv_smUT ipv1_smV6 ipv2_imWU
                  of _ [Occ=Dead] { (# ipv4_XmXv, ipv5_XmXx #) ->
                  (# ipv4_XmXv,
                     ++
                       @ Char
                       (GHC.Types.: @ Char sc_sn0b (GHC.Types.[] @ Char))
                       ipv5_XmXx #)
                  };

The dump-simpl output is essentially the same except the difference due to
the realworld token in the IO case. Why is the generated code different? I
will appreciate if someone can throw some light on the reason or can point
to the relevant ghc source to look at where this happens.

I am using ghc-7.10.3 in native code generation mode (no llvm).

Thanks,
Harendra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160509/cb6fb018/attachment.html>

From alois.cochard at gmail.com  Mon May  9 16:48:05 2016
From: alois.cochard at gmail.com (Alois Cochard)
Date: Mon, 9 May 2016 18:48:05 +0200
Subject: Mentor for a JVM backend for GHC
In-Reply-To: <572E0A7C.8090208@nyu.edu>
References: <CANij+eRbvRcNGbMx23xGw2Q8LjZ4x4AzBwVyoi5oM5KfvF+A+Q@mail.gmail.com>
 <572E0A7C.8090208@nyu.edu>
Message-ID: <CAJHA+wrvc5Uki0x2P1gCVNBzHP+2aO_JtqkxSnvFYK3WThMU3A@mail.gmail.com>

I think Jasmin is really overrated, we can clearly do better in Haskell.

FWIW, the Kuna JVM assembler do support stack map frames, a lot of effort
was put into getting this right, it would be a shame to redo this works if
someone looks for a pure haskell implementation.
On 7 May 2016 5:32 pm, "Thomas Jakway" <tjakway at nyu.edu> wrote:

> This is a strange coincidence.  I'm definitely no expert GHC hacker but I
> started (highly preliminary) work on a JVM backend for GHC a few weeks
> ago.  It's here:
> https://github.com/tjakway/ghcjvm/tree/jvm/compiler/jvmGen/Jvm
> (The memory runtime is here: https://github.com/tjakway/lljvm)
>
> I'm very new to this so pardon my ignorance, but I don't understand what
> the benefit is of intercepting STG code and translating that to bytecode
> vs. translating Cmm to bytecode (or Jasmin assembly, as I'd prefer)?  It
> seems like Cmm is designed for backends and the obvious choice.  Or have I
> got this really mixed up?
>
> I hope this isn't out of line considering my overall lack of experience
> but I think I can give some advice:
>
>    - read the JVM 7 spec cover-to-cover.
>    - I *highly* suggest outputting Jasmin
>    <http://web.mit.edu/javadev/packages/jasmin/doc/> assembly instead of
>    raw bytecode.  The classfile format is complicated and you will have to
>    essentially rewrite Jasmin in Haskell if you don't want to reuse it.
>    Jasmin is also the de facto standard assembler and much more thoroughly
>    tested than any homegrown solution we might make.
>    - read the LLVM code generator.  This project is more like the LLVM
>    backend than the native code generator.
>    - Don't go for speed.  The approach that I've begun is to emulate a C
>    stack and memory system the RTS can run on top of (
>    https://github.com/tjakway/lljvm/blob/master/src/main/java/lljvm/runtime/Memory.java).
>    This will make getting *something* working much faster and also solves
>    the problem of how to deal with memcpy/memset/memmove on the JVM.  This
>    will of course be *very* slow (I think) and is not a permanent
>    solution.  Can't do everything at once.  Any other approach will probably
>    require rewriting the entire RTS from the beginning.
>    - I don't think Frege is especially useful to this project, though I'd
>    love to be proven wrong.  Frege's compilation model is completely different
>    from GHC's: they compile Haskell to Java and then send that to javac.
>    Porting GHC to the JVM is really more like writing a Cmm to JVM compiler.
>
>
> I've heard of the LambdaVM project but couldn't find the actual code
> anywhere.  The site where it was hosted appears to be offline.  I'd
> certainly like to look at it if anyone knows where to find it.
>
> Information on Jasmin:
> http://web.mit.edu/javadev/packages/jasmin/doc/
> http://web.mit.edu/javadev/packages/jasmin/doc/instructions.html
> http://web.mit.edu/javadev/packages/jasmin/doc/about.html
>
> Once you've tried manually dealing with constant pools you'll appreciate
> Jonathan Meyer's work!
>
> I forked davidar's <https://github.com/davidar> extended version of
> Jasmin.  The differences versus the original Jasmin are detailed here
> <https://github.com/davidar/jasmin/blob/master/html2x/xt.html>.  Some
> nice additions:
>
>    - supports invokedynamic
>    - supports .annotation, .inner, .attribute, .deprecated directives
>    - better handling of the ldc_w instruction
>    - multi-line fields
>    - .debug directives
>    - signatures for local variables
>    - .bytecode directive to specify bytecode version
>    - (most importantly, I think): support for the StackMap attribute.  If
>    we eventually want to use new JVM instructions like invokedynamic, we
>    *need* stack map frames or the JVM will reject our bytecode.  JVM 7
>    has options to bypass this (but it's a hack), but they're deprecated and I
>    believe not optional going forward.  Alternatively we can stick with older
>    bytecode versions indefinitely and not use the new features.
>
> (Just to be clear, I forked it in case it was deleted.  I didn't write
> those features, the credit belongs to him).
>
> I think the biggest risk is taking too much on at once.  Any one of these
> subtasks, writing a bytecode assembler, porting the RTS, etc. could consume
> the whole summer if you're not careful.
>
> I'd love to help out with this project!
>
> Sincerely,
> Thomas Jakway
>
> -------
>
> Woops, after scrolling back through the emails it looks like someone sent
> out the LambdaVM source.  I'll have to take a look at that.
>
>
> On 05/02/2016 11:26 AM, Rahul Muttineni wrote:
>
> Hi GHC Developers,
>
> I've started working on a JVM backend for GHC [1] and I'd love to work on
> it as my Summer of Haskell project.
>
> Currently, the build system is setup using a mix of Shake (for the RTS
> build) and Stack (for the main compiler build) and I ensure that most
> commits build successfully. I have ported the core part of the scheduler
> and ported over the fundamental types (Capability, StgTSO, Task,
> StgClosure, etc.) taking advantage of OOP in the implementation when I
> could.
>
> Additionally, I performed a non-trivial refactor of the hs-java package
> adding support for inner classes and fields which was very cumbersome to do
> in the original package. On the frontend, I have tapped into the STG code
> from the GHC 7.10.3 library and setup a CodeGen monad for generating JVM
> bytecode. The main task of generating the actual bytecode, porting the more
> critical parts of the RTS, and adding support for the threaded RTS remain.
>
> The strategy for compilation is as follows:
> - Intercept the STG code in the GHC pipeline
> - Convert from STG->JVM bytecode [2] in a similar manner as STG->Cmm
> preserving semantics as best as possible [3]
> - Port the GHC RTS (normal & threaded) to Java [4]
> - Put all the generated class files + RTS into a single jar to be run
> directly by the JVM.
>
> My objectives for the project during the summer are:
> - To implement the compilation strategy mentioned above
> - Implement the Java FFI for foreign imports. [5]
> - Implement the most important [6] PrimOps that GHC supports.
> - Port the base package replacing the C FFI imports with equivalent Java
> FFI imports. [7]
>
> A little bit about myself: I spent a lot of time studying functional
> language implementation by reading SPJ's famous book and reading research
> papers on related topics last summer as self-study.
>
> I took a break and resumed a couple months ago where I spent a lot of time
> plowing through the STG->Cmm code generator as well as the RTS and going
> back and forth between them to get a clear understanding of how everything
> works.
>
> Moreover, I compiled simple Haskell programs and observed the STG, Cmm,
> and assembly output (by decompiling the final executable with objdump) to
> understand bits of the code generator where the source code wasn't that
> clear.
>
> I also spent a great deal of time studying the JVM internals, reading the
> JVM spec, looking for any new features that could facilitate a high
> performance implementation [8].
>
> It would be great if someone with an understanding of nuances of the RTS
> and code generator could mentor me for this project. It has been a blast so
> far learning all the prerequisites and contemplating the design. I'd be
> very excited to take this on as a summer project.
>
> Also, given that I have hardly 5 days remaining, does anyone have
> suggestions on how I can structure the proposal without getting into too
> many details? There are still some parts of the design I haven't figured
> out, but I know I could find some solution when I get to it during the
> porting process.
>
> Thanks,
> Rahul Muttineni
>
> [1] http://github.com/rahulmutt/ghcvm
>
> [2] I intend to organically derive an IR at a later stage to allow for
> some optimizations by looking at the final working implementation without
> an IR and looking for patterns of repeated sequences of bytecode and
> assigning each sequence its own instruction in the IR.
>
> [3] Obviously, the lack of control of memory layouts (besides allocating
> off the JVM heap using DirectByteBuffers) and lack of general tail calls
> makes it tough to match the semantics of Cmm, but there are many solutions
> around it, as can be found in the few papers on translating STG to Java/JVM
> bytecode.
>
> [4] This is the GHC RTS without GC and profiling since the JVM has great
> support for those already. Also, lots of care must be taken to ensure that
> the lock semantics stays in tact during the port.
>
> [5] foreign exports will be dealt at a later stage, but I am taking care
> of naming the closures nicely so that in the future you don't have to type
> long names like the labels GHC compiles to call a Haskell function in Java.
>
> [6] Basically all the PrimOps that would be required to provide plumbing
> for the Prelude functions that can compile beginner-level programs found in
> books such as Learn You a Haskell for Great Good.
>
> [7] I know that it's a lot more complicated than just replacing FFI calls.
> I'd have to change around a lot of the code in base as well.
>
> [8] I found that the new "invokedynamic" instruction as well as the
> MethodHandle API (something like function pointers) that were introduced in
> JDK 7 could fit the bill. But as of now, I want to get a baseline
> implementation that is compatible with Java 5 so I will not be utilizing
> these newer features.
>
>
>
> _______________________________________________
> ghc-devs mailing listghc-devs at haskell.orghttp://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/20160509/38002700/attachment-0001.html>

From alois.cochard at gmail.com  Mon May  9 16:51:53 2016
From: alois.cochard at gmail.com (Alois Cochard)
Date: Mon, 9 May 2016 18:51:53 +0200
Subject: Mentor for a JVM backend for GHC
In-Reply-To: <CAJumaK_fzv9+N5MwWNtB_srK3Y3cPDo14CbT9huevk4Jn1xziw@mail.gmail.com>
References: <CANij+eRbvRcNGbMx23xGw2Q8LjZ4x4AzBwVyoi5oM5KfvF+A+Q@mail.gmail.com>
 <572E0A7C.8090208@nyu.edu>
 <CAJumaK_fzv9+N5MwWNtB_srK3Y3cPDo14CbT9huevk4Jn1xziw@mail.gmail.com>
Message-ID: <CAJHA+wpzKPOb-j9wtLE6o7MaAHCwx+L9ot5dKtW87_544mqZsw@mail.gmail.com>

Totally agree, Cmm is too late.

My aim in Kuna was to start the transformation from Core, targeting
stack-safe JVM bytecode without using Graal or the like.

Yes, I am quite an optimistic person ;-) but I believe it's the path to
take. I'm not interested in Frege like approach for various reasons,
performance being one of them.
On 7 May 2016 6:19 pm, "Edward Kmett" <ekmett at gmail.com> wrote:

> By the time it has made it down to Cmm there are a lot of assumptions
> about layout in memory -- everything is assumed to be a flat object
> made out of 32-bit or 64-bit slots. These assumptions aren't really
> suitable for the JVM.
>
> -Edward
>
> On Sat, May 7, 2016 at 11:32 AM, Thomas Jakway <tjakway at nyu.edu> wrote:
> > This is a strange coincidence.  I'm definitely no expert GHC hacker but I
> > started (highly preliminary) work on a JVM backend for GHC a few weeks
> ago.
> > It's here:
> https://github.com/tjakway/ghcjvm/tree/jvm/compiler/jvmGen/Jvm
> > (The memory runtime is here: https://github.com/tjakway/lljvm)
> >
> > I'm very new to this so pardon my ignorance, but I don't understand what
> the
> > benefit is of intercepting STG code and translating that to bytecode vs.
> > translating Cmm to bytecode (or Jasmin assembly, as I'd prefer)?  It
> seems
> > like Cmm is designed for backends and the obvious choice.  Or have I got
> > this really mixed up?
> >
> > I hope this isn't out of line considering my overall lack of experience
> but
> > I think I can give some advice:
> >
> > read the JVM 7 spec cover-to-cover.
> > I highly suggest outputting Jasmin assembly instead of raw bytecode.  The
> > classfile format is complicated and you will have to essentially rewrite
> > Jasmin in Haskell if you don't want to reuse it.  Jasmin is also the de
> > facto standard assembler and much more thoroughly tested than any
> homegrown
> > solution we might make.
> > read the LLVM code generator.  This project is more like the LLVM backend
> > than the native code generator.
> > Don't go for speed.  The approach that I've begun is to emulate a C stack
> > and memory system the RTS can run on top of
> > (
> https://github.com/tjakway/lljvm/blob/master/src/main/java/lljvm/runtime/Memory.java
> ).
> > This will make getting something working much faster and also solves the
> > problem of how to deal with memcpy/memset/memmove on the JVM.  This will
> of
> > course be very slow (I think) and is not a permanent solution.  Can't do
> > everything at once.  Any other approach will probably require rewriting
> the
> > entire RTS from the beginning.
> > I don't think Frege is especially useful to this project, though I'd
> love to
> > be proven wrong.  Frege's compilation model is completely different from
> > GHC's: they compile Haskell to Java and then send that to javac.  Porting
> > GHC to the JVM is really more like writing a Cmm to JVM compiler.
> >
> >
> > I've heard of the LambdaVM project but couldn't find the actual code
> > anywhere.  The site where it was hosted appears to be offline.  I'd
> > certainly like to look at it if anyone knows where to find it.
> >
> > Information on Jasmin:
> > http://web.mit.edu/javadev/packages/jasmin/doc/
> > http://web.mit.edu/javadev/packages/jasmin/doc/instructions.html
> > http://web.mit.edu/javadev/packages/jasmin/doc/about.html
> >
> > Once you've tried manually dealing with constant pools you'll appreciate
> > Jonathan Meyer's work!
> >
> > I forked davidar's extended version of Jasmin.  The differences versus
> the
> > original Jasmin are detailed here.  Some nice additions:
> >
> > supports invokedynamic
> > supports .annotation, .inner, .attribute, .deprecated directives
> > better handling of the ldc_w instruction
> > multi-line fields
> > .debug directives
> > signatures for local variables
> > .bytecode directive to specify bytecode version
> > (most importantly, I think): support for the StackMap attribute.  If we
> > eventually want to use new JVM instructions like invokedynamic, we need
> > stack map frames or the JVM will reject our bytecode.  JVM 7 has options
> to
> > bypass this (but it's a hack), but they're deprecated and I believe not
> > optional going forward.  Alternatively we can stick with older bytecode
> > versions indefinitely and not use the new features.
> >
> > (Just to be clear, I forked it in case it was deleted.  I didn't write
> those
> > features, the credit belongs to him).
> >
> > I think the biggest risk is taking too much on at once.  Any one of these
> > subtasks, writing a bytecode assembler, porting the RTS, etc. could
> consume
> > the whole summer if you're not careful.
> >
> > I'd love to help out with this project!
> >
> > Sincerely,
> > Thomas Jakway
> >
> > -------
> >
> > Woops, after scrolling back through the emails it looks like someone sent
> > out the LambdaVM source.  I'll have to take a look at that.
> >
> >
> >
> > On 05/02/2016 11:26 AM, Rahul Muttineni wrote:
> >
> > Hi GHC Developers,
> >
> > I've started working on a JVM backend for GHC [1] and I'd love to work
> on it
> > as my Summer of Haskell project.
> >
> > Currently, the build system is setup using a mix of Shake (for the RTS
> > build) and Stack (for the main compiler build) and I ensure that most
> > commits build successfully. I have ported the core part of the scheduler
> and
> > ported over the fundamental types (Capability, StgTSO, Task, StgClosure,
> > etc.) taking advantage of OOP in the implementation when I could.
> >
> > Additionally, I performed a non-trivial refactor of the hs-java package
> > adding support for inner classes and fields which was very cumbersome to
> do
> > in the original package. On the frontend, I have tapped into the STG code
> > from the GHC 7.10.3 library and setup a CodeGen monad for generating JVM
> > bytecode. The main task of generating the actual bytecode, porting the
> more
> > critical parts of the RTS, and adding support for the threaded RTS
> remain.
> >
> > The strategy for compilation is as follows:
> > - Intercept the STG code in the GHC pipeline
> > - Convert from STG->JVM bytecode [2] in a similar manner as STG->Cmm
> > preserving semantics as best as possible [3]
> > - Port the GHC RTS (normal & threaded) to Java [4]
> > - Put all the generated class files + RTS into a single jar to be run
> > directly by the JVM.
> >
> > My objectives for the project during the summer are:
> > - To implement the compilation strategy mentioned above
> > - Implement the Java FFI for foreign imports. [5]
> > - Implement the most important [6] PrimOps that GHC supports.
> > - Port the base package replacing the C FFI imports with equivalent Java
> FFI
> > imports. [7]
> >
> > A little bit about myself: I spent a lot of time studying functional
> > language implementation by reading SPJ's famous book and reading research
> > papers on related topics last summer as self-study.
> >
> > I took a break and resumed a couple months ago where I spent a lot of
> time
> > plowing through the STG->Cmm code generator as well as the RTS and going
> > back and forth between them to get a clear understanding of how
> everything
> > works.
> >
> > Moreover, I compiled simple Haskell programs and observed the STG, Cmm,
> and
> > assembly output (by decompiling the final executable with objdump) to
> > understand bits of the code generator where the source code wasn't that
> > clear.
> >
> > I also spent a great deal of time studying the JVM internals, reading the
> > JVM spec, looking for any new features that could facilitate a high
> > performance implementation [8].
> >
> > It would be great if someone with an understanding of nuances of the RTS
> and
> > code generator could mentor me for this project. It has been a blast so
> far
> > learning all the prerequisites and contemplating the design. I'd be very
> > excited to take this on as a summer project.
> >
> > Also, given that I have hardly 5 days remaining, does anyone have
> > suggestions on how I can structure the proposal without getting into too
> > many details? There are still some parts of the design I haven't figured
> > out, but I know I could find some solution when I get to it during the
> > porting process.
> >
> > Thanks,
> > Rahul Muttineni
> >
> > [1] http://github.com/rahulmutt/ghcvm
> >
> > [2] I intend to organically derive an IR at a later stage to allow for
> some
> > optimizations by looking at the final working implementation without an
> IR
> > and looking for patterns of repeated sequences of bytecode and assigning
> > each sequence its own instruction in the IR.
> >
> > [3] Obviously, the lack of control of memory layouts (besides allocating
> off
> > the JVM heap using DirectByteBuffers) and lack of general tail calls
> makes
> > it tough to match the semantics of Cmm, but there are many solutions
> around
> > it, as can be found in the few papers on translating STG to Java/JVM
> > bytecode.
> >
> > [4] This is the GHC RTS without GC and profiling since the JVM has great
> > support for those already. Also, lots of care must be taken to ensure
> that
> > the lock semantics stays in tact during the port.
> >
> > [5] foreign exports will be dealt at a later stage, but I am taking care
> of
> > naming the closures nicely so that in the future you don't have to type
> long
> > names like the labels GHC compiles to call a Haskell function in Java.
> >
> > [6] Basically all the PrimOps that would be required to provide plumbing
> for
> > the Prelude functions that can compile beginner-level programs found in
> > books such as Learn You a Haskell for Great Good.
> >
> > [7] I know that it's a lot more complicated than just replacing FFI
> calls.
> > I'd have to change around a lot of the code in base as well.
> >
> > [8] I found that the new "invokedynamic" instruction as well as the
> > MethodHandle API (something like function pointers) that were introduced
> in
> > JDK 7 could fit the bill. But as of now, I want to get a baseline
> > implementation that is compatible with Java 5 so I will not be utilizing
> > these newer features.
> >
> >
> >
> > _______________________________________________
> > 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/20160509/f0e937fb/attachment.html>

From dan.doel at gmail.com  Tue May 10 01:21:56 2016
From: dan.doel at gmail.com (Dan Doel)
Date: Mon, 9 May 2016 21:21:56 -0400
Subject: suboptimal ghc code generation in IO vs equivalent pure code case
In-Reply-To: <CAPW+kkbszGf8_UfVc6sE7b3A6UHMfB04N03DBj_UZ9W02ofS=Q@mail.gmail.com>
References: <CAPW+kkbszGf8_UfVc6sE7b3A6UHMfB04N03DBj_UZ9W02ofS=Q@mail.gmail.com>
Message-ID: <CAHEA9tObezBkM7MZtczO+r6cUK=r2eYruNFmw1CbejZfQzYyDA@mail.gmail.com>

I'm no expert on reading GHC's generated assembly. However, there may
be a line you've overlooked in explaining the difference, namely:

    movq $stg_upd_frame_info,-16(%rbp)

This appears only in the IO code, according to what you've pasted, and
it appears to be pushing an update frame (I think). Update frames are
used as part of lazy evaluation, to ensure that work only happens
once, barring very short race conditions. So, at a guess, I would say
that your IO-based code is creating extra updatable closures, which
isn't free.

It's sometimes difficult to see the difference at the core level. It
will probably be clearer at the STG level, because the expression
language is more disciplined there. But, for instance, your pure code
tail calls (++), whereas your IO code returns an unboxed tuple with
the same sort of expression that is in the pure tail call. However,
complex expressions like that can't really be put in an unboxed tuple
at the STG level, so what will happen is that the complex expression
will be let (closure allocation), and the closure will be returned in
the unboxed tuple. So that is the source of the difference. A more
perspicuous picture would be something like:

  Pure:
    False ->
      let {
        l1 = : ww_amuh []
        l2 = Data.Unicode.Internal.Normalization.decompose_$sdecompose
ipv_smuv ipv1_smuD
      } in ++ l1 l2


  IO:
    False ->
      case $sa1_sn0g ipv_smUT ipv1_smV6 ipv2_imWU
      of _ { (# ipv4_XmXv, ipv5_XmXx #) ->
      let {
        l1 = : sc_sn0b []
        l3 = ++ l1 ipv5_XmXx
      } in (# ipv4_XmXv, l3 #)

I can't say for certain that that's the only thing making a
difference, but it might be one thing.

-- Dan


On Mon, May 9, 2016 at 10:23 AM, Harendra Kumar
<harendra.kumar at gmail.com> wrote:
> I have a loop which runs millions of times. For some reason I have to run it
> in the IO monad. I noticed that when I convert the code from pure to IO
> monad the generated assembly code in essence is almost identical except one
> difference where it puts a piece of code in a separate block which is making
> a huge difference in performance (4-6x slower).
>
> I want to understand what makes GHC to generate code in this way and if
> there is anything that can be done at source level (or ghc option)  to
> control that.
>
> The pure code looks like this:
>
>         decomposeChars :: [Char] -> [Char]
>
>         decomposeChars [] = []
>         decomposeChars [x] =
>             case NFD.isDecomposable x of
>                 True -> decomposeChars (NFD.decomposeChar x)
>                 False -> [x]
>         decomposeChars (x : xs) = decomposeChars [x] ++ decomposeChars xs
>
> The equivalent IO code is this:
>
>         decomposeStrIO :: [Char] -> IO [Char]
>
>         decomposeStrPtr !p = decomposeStrIO
>             where
>                 decomposeStrIO [] = return []
>                 decomposeStrIO [x] = do
>                     res <- NFD.isDecomposable p x
>                     case res of
>                         True -> decomposeStrIO (NFD.decomposeChar x)
>                         False -> return [x]
>                 decomposeStrIO (x : xs) = do
>                     s1 <- decomposeStrIO [x]
>                     s2 <- decomposeStrIO xs
>                     return (s1 ++ s2)
>
> The difference is in how the code corresponding to the call to the (++)
> operation is generated. In the pure case the (++) operation is inline in the
> main loop:
>
> _cn5N:
> movq $sat_sn2P_info,-48(%r12)
> movq %rax,-32(%r12)
> movq %rcx,-24(%r12)
> movq $:_con_info,-16(%r12)
> movq 16(%rbp),%rax
> movq %rax,-8(%r12)
> movq $GHC.Types.[]_closure+1,(%r12)
> leaq -48(%r12),%rsi
> leaq -14(%r12),%r14
> addq $40,%rbp
> jmp GHC.Base.++_info
>
> In the IO monad version this code is placed in a separate block and a call
> is placed in the main loop:
>
> the main loop call site:
>
> _cn6A:
> movq $sat_sn3w_info,-24(%r12)
> movq 8(%rbp),%rax
> movq %rax,-8(%r12)
> movq %rbx,(%r12)
> leaq -24(%r12),%rbx
> addq $40,%rbp
> jmp *(%rbp)
>
> out of the line block - the code that was in the main loop in the previous
> case is now moved to this block (see label _cn5s below):
>
> sat_sn3w_info:
> _cn5p:
> leaq -16(%rbp),%rax
> cmpq %r15,%rax
> jb _cn5q
> _cn5r:
> addq $24,%r12
> cmpq 856(%r13),%r12
> ja _cn5t
> _cn5s:
> movq $stg_upd_frame_info,-16(%rbp)
> movq %rbx,-8(%rbp)
> movq 16(%rbx),%rax
> movq 24(%rbx),%rbx
> movq $:_con_info,-16(%r12)
> movq %rax,-8(%r12)
> movq $GHC.Types.[]_closure+1,(%r12)
> movq %rbx,%rsi
> leaq -14(%r12),%r14
> addq $-16,%rbp
> jmp GHC.Base.++_info
> _cn5t:
> movq $24,904(%r13)
> _cn5q:
> jmp *-16(%r13)
>
> Except this difference the rest of the assembly looks pretty similar in both
> the cases. The corresponding dump-simpl output for the pure case:
>
>           False ->
>             ++
>               @ Char
>               (GHC.Types.: @ Char ww_amuh (GHC.Types.[] @ Char))
>               (Data.Unicode.Internal.Normalization.decompose_$sdecompose
>                  ipv_smuv ipv1_smuD);
>
> And for the IO monad version:
>
>                 False ->
>                   case $sa1_sn0g ipv_smUT ipv1_smV6 ipv2_imWU
>                   of _ [Occ=Dead] { (# ipv4_XmXv, ipv5_XmXx #) ->
>                   (# ipv4_XmXv,
>                      ++
>                        @ Char
>                        (GHC.Types.: @ Char sc_sn0b (GHC.Types.[] @ Char))
>                        ipv5_XmXx #)
>                   };
>
> The dump-simpl output is essentially the same except the difference due to
> the realworld token in the IO case. Why is the generated code different? I
> will appreciate if someone can throw some light on the reason or can point
> to the relevant ghc source to look at where this happens.
>
> I am using ghc-7.10.3 in native code generation mode (no llvm).
>
> Thanks,
> Harendra
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>

From rahulmutt at gmail.com  Tue May 10 02:29:15 2016
From: rahulmutt at gmail.com (rahulmutt at gmail.com)
Date: Tue, 10 May 2016 07:59:15 +0530
Subject: Mentor for a JVM backend for GHC
In-Reply-To: <572E0A7C.8090208@nyu.edu>
References: <CANij+eRbvRcNGbMx23xGw2Q8LjZ4x4AzBwVyoi5oM5KfvF+A+Q@mail.gmail.com>
 <572E0A7C.8090208@nyu.edu>
Message-ID: <20160510022915.5886033.19819.19362@gmail.com>

An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160510/8eaec627/attachment.html>

From rahulmutt at gmail.com  Tue May 10 02:43:07 2016
From: rahulmutt at gmail.com (rahulmutt at gmail.com)
Date: Tue, 10 May 2016 08:13:07 +0530
Subject: Mentor for a JVM backend for GHC
In-Reply-To: <CAJHA+wpzKPOb-j9wtLE6o7MaAHCwx+L9ot5dKtW87_544mqZsw@mail.gmail.com>
References: <CANij+eRbvRcNGbMx23xGw2Q8LjZ4x4AzBwVyoi5oM5KfvF+A+Q@mail.gmail.com>
 <572E0A7C.8090208@nyu.edu>
 <CAJumaK_fzv9+N5MwWNtB_srK3Y3cPDo14CbT9huevk4Jn1xziw@mail.gmail.com>
 <CAJHA+wpzKPOb-j9wtLE6o7MaAHCwx+L9ot5dKtW87_544mqZsw@mail.gmail.com>
Message-ID: <20160510024307.5886033.9548.19367@gmail.com>

An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160510/3f07aa81/attachment-0001.html>

From simonpj at microsoft.com  Tue May 10 08:43:35 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 10 May 2016 08:43:35 +0000
Subject: Harbourmaster is failing
Message-ID: <bbd6cb110ff844709987e88b8afd54a9@DB4PR30MB030.064d.mgd.msft.net>

Lots of early Harbourmaster fails
https://phabricator.haskell.org/harbormaster/build/11545/

Simon

In file included from includes/Stg.h:213:0,



from includes/Rts.h:30,



from includes/dist-derivedconstants/header/tmp.c:13:



includes/stg/Types.h:31:2: error: #import is a deprecated GCC extension [-Werror=deprecated]



#import <inttypes.h>



^



cc1: all warnings being treated as errors


Executing "gcc" failed
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160510/7533f0ec/attachment.html>

From harendra.kumar at gmail.com  Tue May 10 08:45:15 2016
From: harendra.kumar at gmail.com (Harendra Kumar)
Date: Tue, 10 May 2016 14:15:15 +0530
Subject: suboptimal ghc code generation in IO vs equivalent pure code case
In-Reply-To: <CAHEA9tObezBkM7MZtczO+r6cUK=r2eYruNFmw1CbejZfQzYyDA@mail.gmail.com>
References: <CAPW+kkbszGf8_UfVc6sE7b3A6UHMfB04N03DBj_UZ9W02ofS=Q@mail.gmail.com>
 <CAHEA9tObezBkM7MZtczO+r6cUK=r2eYruNFmw1CbejZfQzYyDA@mail.gmail.com>
Message-ID: <CAPW+kkaUwUcDK-CROAYLTqjh42WehPEiU1iygCMWYWLgYAz7TQ@mail.gmail.com>

Thanks Dan, that helped. I did notice and suspect the update frame and the
unboxed tuple but given my limited knowledge about ghc/core/stg/cmm I was
not sure what is going on. In fact I thought that the intermediate tuple
should get optimized out since it is required only because of the realworld
token which is not real. But it might be difficult to see that at this
level?

What you are saying may be true for the current implementation but in
theory can we eliminate the intermediate closure?

I observed that the same unboxed tuple results in an inline code for (:)
constructor. I rewrote the source a bit differently which resulted in this
core:

              case ipv1_amWI of _ [Occ=Dead] {
                False ->
                  case a1_smWm xs_aloV ipv_amWH
                  of _ [Occ=Dead] { (# ipv2_XmXf, ipv3_XmXh #) ->
                  (# ipv2_XmXf, GHC.Types.: @ Char x_aloU ipv3_XmXh #)
                  };
                True ->
                  case a1_smWm (NFD.decomposeChar x_aloU) ipv_amWH
                  of _ [Occ=Dead] { (# ipv2_XmXf, ipv3_XmXh #) ->
                  case a1_smWm xs_aloV ipv2_XmXf
                  of _ [Occ=Dead] { (# ipv4_XmXk, ipv5_XmXm #) ->
                  (# ipv4_XmXk, ++ @ Char ipv3_XmXh ipv5_XmXm #)
                  }
                  }
              }

We can see that both True and the False case are returning an unboxed
tuple. The only difference is (:) vs (++). But the generated assembly is
different for both cases:

(++) has a closure as before:

sat_sn0Z_info:
_cn2c:
leaq -16(%rbp),%rax
cmpq %r15,%rax
jb _cn2d
_cn2e:
movq $stg_upd_frame_info,-16(%rbp)
movq %rbx,-8(%rbp)
movq 24(%rbx),%rsi
movq 16(%rbx),%r14
addq $-16,%rbp
jmp GHC.Base.++_info

(:) is treated differently and generated inline as you can see below:

_cn2I:
movq $sat_sn0Z_info,-24(%r12)
movq 8(%rbp),%rax
movq %rax,-8(%r12)
movq %rbx,(%r12)
leaq -24(%r12),%rbx
addq $16,%rbp
jmp *(%rbp)
.
.
.
block_cn2u_info:
_cn2u:
addq $24,%r12
cmpq 856(%r13),%r12
ja _cn2C
_cn2B:
movq $:_con_info,-16(%r12)
movq 8(%rbp),%rax
movq %rax,-8(%r12)
movq %rbx,(%r12)
leaq -14(%r12),%rbx
addq $24,%rbp
jmp *(%rbp)

So why is that? Why can't we generate (++) inline similar to (:)? How do we
make this decision? Is there a theoretical reason for this or this is just
an implementation artifact?

Since the tuple is required only for passing the realworld token, ideally I
wouldn't want it to make a difference to the generated code. Otherwise I
would always have to worry about such performance side effects when using
ST/IO.

-harendra


On 10 May 2016 at 06:51, Dan Doel <dan.doel at gmail.com> wrote:

> I'm no expert on reading GHC's generated assembly. However, there may
> be a line you've overlooked in explaining the difference, namely:
>
>     movq $stg_upd_frame_info,-16(%rbp)
>
> This appears only in the IO code, according to what you've pasted, and
> it appears to be pushing an update frame (I think). Update frames are
> used as part of lazy evaluation, to ensure that work only happens
> once, barring very short race conditions. So, at a guess, I would say
> that your IO-based code is creating extra updatable closures, which
> isn't free.
>
> It's sometimes difficult to see the difference at the core level. It
> will probably be clearer at the STG level, because the expression
> language is more disciplined there. But, for instance, your pure code
> tail calls (++), whereas your IO code returns an unboxed tuple with
> the same sort of expression that is in the pure tail call. However,
> complex expressions like that can't really be put in an unboxed tuple
> at the STG level, so what will happen is that the complex expression
> will be let (closure allocation), and the closure will be returned in
> the unboxed tuple. So that is the source of the difference. A more
> perspicuous picture would be something like:
>
>   Pure:
>     False ->
>       let {
>         l1 = : ww_amuh []
>         l2 = Data.Unicode.Internal.Normalization.decompose_$sdecompose
> ipv_smuv ipv1_smuD
>       } in ++ l1 l2
>
>
>   IO:
>     False ->
>       case $sa1_sn0g ipv_smUT ipv1_smV6 ipv2_imWU
>       of _ { (# ipv4_XmXv, ipv5_XmXx #) ->
>       let {
>         l1 = : sc_sn0b []
>         l3 = ++ l1 ipv5_XmXx
>       } in (# ipv4_XmXv, l3 #)
>
> I can't say for certain that that's the only thing making a
> difference, but it might be one thing.
>
> -- Dan
>
>
> On Mon, May 9, 2016 at 10:23 AM, Harendra Kumar
> <harendra.kumar at gmail.com> wrote:
> > I have a loop which runs millions of times. For some reason I have to
> run it
> > in the IO monad. I noticed that when I convert the code from pure to IO
> > monad the generated assembly code in essence is almost identical except
> one
> > difference where it puts a piece of code in a separate block which is
> making
> > a huge difference in performance (4-6x slower).
> >
> > I want to understand what makes GHC to generate code in this way and if
> > there is anything that can be done at source level (or ghc option)  to
> > control that.
> >
> > The pure code looks like this:
> >
> >         decomposeChars :: [Char] -> [Char]
> >
> >         decomposeChars [] = []
> >         decomposeChars [x] =
> >             case NFD.isDecomposable x of
> >                 True -> decomposeChars (NFD.decomposeChar x)
> >                 False -> [x]
> >         decomposeChars (x : xs) = decomposeChars [x] ++ decomposeChars xs
> >
> > The equivalent IO code is this:
> >
> >         decomposeStrIO :: [Char] -> IO [Char]
> >
> >         decomposeStrPtr !p = decomposeStrIO
> >             where
> >                 decomposeStrIO [] = return []
> >                 decomposeStrIO [x] = do
> >                     res <- NFD.isDecomposable p x
> >                     case res of
> >                         True -> decomposeStrIO (NFD.decomposeChar x)
> >                         False -> return [x]
> >                 decomposeStrIO (x : xs) = do
> >                     s1 <- decomposeStrIO [x]
> >                     s2 <- decomposeStrIO xs
> >                     return (s1 ++ s2)
> >
> > The difference is in how the code corresponding to the call to the (++)
> > operation is generated. In the pure case the (++) operation is inline in
> the
> > main loop:
> >
> > _cn5N:
> > movq $sat_sn2P_info,-48(%r12)
> > movq %rax,-32(%r12)
> > movq %rcx,-24(%r12)
> > movq $:_con_info,-16(%r12)
> > movq 16(%rbp),%rax
> > movq %rax,-8(%r12)
> > movq $GHC.Types.[]_closure+1,(%r12)
> > leaq -48(%r12),%rsi
> > leaq -14(%r12),%r14
> > addq $40,%rbp
> > jmp GHC.Base.++_info
> >
> > In the IO monad version this code is placed in a separate block and a
> call
> > is placed in the main loop:
> >
> > the main loop call site:
> >
> > _cn6A:
> > movq $sat_sn3w_info,-24(%r12)
> > movq 8(%rbp),%rax
> > movq %rax,-8(%r12)
> > movq %rbx,(%r12)
> > leaq -24(%r12),%rbx
> > addq $40,%rbp
> > jmp *(%rbp)
> >
> > out of the line block - the code that was in the main loop in the
> previous
> > case is now moved to this block (see label _cn5s below):
> >
> > sat_sn3w_info:
> > _cn5p:
> > leaq -16(%rbp),%rax
> > cmpq %r15,%rax
> > jb _cn5q
> > _cn5r:
> > addq $24,%r12
> > cmpq 856(%r13),%r12
> > ja _cn5t
> > _cn5s:
> > movq $stg_upd_frame_info,-16(%rbp)
> > movq %rbx,-8(%rbp)
> > movq 16(%rbx),%rax
> > movq 24(%rbx),%rbx
> > movq $:_con_info,-16(%r12)
> > movq %rax,-8(%r12)
> > movq $GHC.Types.[]_closure+1,(%r12)
> > movq %rbx,%rsi
> > leaq -14(%r12),%r14
> > addq $-16,%rbp
> > jmp GHC.Base.++_info
> > _cn5t:
> > movq $24,904(%r13)
> > _cn5q:
> > jmp *-16(%r13)
> >
> > Except this difference the rest of the assembly looks pretty similar in
> both
> > the cases. The corresponding dump-simpl output for the pure case:
> >
> >           False ->
> >             ++
> >               @ Char
> >               (GHC.Types.: @ Char ww_amuh (GHC.Types.[] @ Char))
> >               (Data.Unicode.Internal.Normalization.decompose_$sdecompose
> >                  ipv_smuv ipv1_smuD);
> >
> > And for the IO monad version:
> >
> >                 False ->
> >                   case $sa1_sn0g ipv_smUT ipv1_smV6 ipv2_imWU
> >                   of _ [Occ=Dead] { (# ipv4_XmXv, ipv5_XmXx #) ->
> >                   (# ipv4_XmXv,
> >                      ++
> >                        @ Char
> >                        (GHC.Types.: @ Char sc_sn0b (GHC.Types.[] @ Char))
> >                        ipv5_XmXx #)
> >                   };
> >
> > The dump-simpl output is essentially the same except the difference due
> to
> > the realworld token in the IO case. Why is the generated code different?
> I
> > will appreciate if someone can throw some light on the reason or can
> point
> > to the relevant ghc source to look at where this happens.
> >
> > I am using ghc-7.10.3 in native code generation mode (no llvm).
> >
> > Thanks,
> > Harendra
> >
> > _______________________________________________
> > Glasgow-haskell-users mailing list
> > Glasgow-haskell-users at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160510/4189c62a/attachment-0001.html>

From simonpj at microsoft.com  Tue May 10 08:50:41 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 10 May 2016 08:50:41 +0000
Subject: Harbourmaster is failing
In-Reply-To: <bbd6cb110ff844709987e88b8afd54a9@DB4PR30MB030.064d.mgd.msft.net>
References: <bbd6cb110ff844709987e88b8afd54a9@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <47f01ac8604d40e18e70b84f8043e090@DB4PR30MB030.064d.mgd.msft.net>

Bother. This is killing my build.   I had to switch of ?Werror.
Anyone know what is going on?
Simon


make --no-print-directory -f ghc.mk phase=1 phase_1_builds

inplace/bin/deriveConstants --gen-header -o includes/dist-derivedconstants/header/DerivedConstants.h --tmpdir includes/dist-derivedconstants/header/ --gcc-program "gcc" --gcc-flag -Wall --gcc-flag -Werror --gcc-flag -Werror=unused-but-set-variable --gcc-flag -Wno-error=inline --gcc-flag -std=gnu99 --gcc-flag -fno-stack-protector --gcc-flag -Iincludes --gcc-flag -Iincludes/dist --gcc-flag -Iincludes/dist-derivedconstants/header --gcc-flag -Iincludes/dist-ghcconstants/header --gcc-flag -Irts --gcc-flag -fcommon --nm-program "/usr/bin/nm" --objdump-program "/usr/bin/objdump" --target-os "linux"

In file included from includes/Stg.h:213:0,

                 from includes/Rts.h:30,

                 from includes/dist-derivedconstants/header/tmp.c:13:

includes/stg/Types.h:31:2: error: #import is a deprecated GCC extension [-Werror=deprecated]

cc1: all warnings being treated as errors

Executing "gcc" failed

make[1]: *** [includes/dist-derivedconstants/header/DerivedConstants.h] Error 1

make: *** [all] Error 2


From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Simon Peyton Jones
Sent: 10 May 2016 09:44
To: ghc-devs <ghc-devs at haskell.org>
Subject: Harbourmaster is failing

Lots of early Harbourmaster fails
https://phabricator.haskell.org/harbormaster/build/11545/

Simon

In file included from includes/Stg.h:213:0,



from includes/Rts.h:30,



from includes/dist-derivedconstants/header/tmp.c:13:



includes/stg/Types.h:31:2: error: #import is a deprecated GCC extension [-Werror=deprecated]



#import <inttypes.h>



^



cc1: all warnings being treated as errors


Executing "gcc" failed
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160510/2bd04b37/attachment.html>

From ezyang at mit.edu  Tue May 10 08:58:16 2016
From: ezyang at mit.edu (Edward Z. Yang)
Date: Tue, 10 May 2016 01:58:16 -0700
Subject: Harbourmaster is failing
In-Reply-To: <47f01ac8604d40e18e70b84f8043e090@DB4PR30MB030.064d.mgd.msft.net>
References: <bbd6cb110ff844709987e88b8afd54a9@DB4PR30MB030.064d.mgd.msft.net>
 <47f01ac8604d40e18e70b84f8043e090@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <1462870675-sup-1289@sabre>

260a5648c299636a94b12b9b97bf9743b0a1496d introduced
the #import.  Probably should be an #include.

Edward

Excerpts from Simon Peyton Jones's message of 2016-05-10 01:50:41 -0700:
> Bother. This is killing my build.   I had to switch of ?Werror.
> Anyone know what is going on?
> Simon
> 
> 
> make --no-print-directory -f ghc.mk phase=1 phase_1_builds
> 
> inplace/bin/deriveConstants --gen-header -o includes/dist-derivedconstants/header/DerivedConstants.h --tmpdir includes/dist-derivedconstants/header/ --gcc-program "gcc" --gcc-flag -Wall --gcc-flag -Werror --gcc-flag -Werror=unused-but-set-variable --gcc-flag -Wno-error=inline --gcc-flag -std=gnu99 --gcc-flag -fno-stack-protector --gcc-flag -Iincludes --gcc-flag -Iincludes/dist --gcc-flag -Iincludes/dist-derivedconstants/header --gcc-flag -Iincludes/dist-ghcconstants/header --gcc-flag -Irts --gcc-flag -fcommon --nm-program "/usr/bin/nm" --objdump-program "/usr/bin/objdump" --target-os "linux"
> 
> In file included from includes/Stg.h:213:0,
> 
>                  from includes/Rts.h:30,
> 
>                  from includes/dist-derivedconstants/header/tmp.c:13:
> 
> includes/stg/Types.h:31:2: error: #import is a deprecated GCC extension [-Werror=deprecated]
> 
> cc1: all warnings being treated as errors
> 
> Executing "gcc" failed
> 
> make[1]: *** [includes/dist-derivedconstants/header/DerivedConstants.h] Error 1
> 
> make: *** [all] Error 2
> 
> 
> From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Simon Peyton Jones
> Sent: 10 May 2016 09:44
> To: ghc-devs <ghc-devs at haskell.org>
> Subject: Harbourmaster is failing
> 
> Lots of early Harbourmaster fails
> https://phabricator.haskell.org/harbormaster/build/11545/
> 
> Simon
> 
> In file included from includes/Stg.h:213:0,
> 
> 
> 
> from includes/Rts.h:30,
> 
> 
> 
> from includes/dist-derivedconstants/header/tmp.c:13:
> 
> 
> 
> includes/stg/Types.h:31:2: error: #import is a deprecated GCC extension [-Werror=deprecated]
> 
> 
> 
> #import <inttypes.h>
> 
> 
> 
> ^
> 
> 
> 
> cc1: all warnings being treated as errors
> 
> 
> Executing "gcc" failed

From ben at smart-cactus.org  Tue May 10 10:02:56 2016
From: ben at smart-cactus.org (Ben Gamari)
Date: Tue, 10 May 2016 12:02:56 +0200
Subject: Harbourmaster is failing
In-Reply-To: <bbd6cb110ff844709987e88b8afd54a9@DB4PR30MB030.064d.mgd.msft.net>
References: <bbd6cb110ff844709987e88b8afd54a9@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <87mvny5iy7.fsf@smart-cactus.org>

Simon Peyton Jones <simonpj at microsoft.com> writes:

> Lots of early Harbourmaster fails
> https://phabricator.haskell.org/harbormaster/build/11545/
>
Fixed; the commit pointed out by ezyang snuck in to one of my merges.
Sorry about that!

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/20160510/41e29720/attachment-0001.sig>

From simonpj at microsoft.com  Tue May 10 14:10:12 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 10 May 2016 14:10:12 +0000
Subject: Determining if an instance is provided by the environment
In-Reply-To: <1462580960-sup-2046@sabre>
References: <1462489986-sup-9818@sabre>
 <27d11f3496bf4fdd8b75c7e88bca3629@DB4PR30MB030.064d.mgd.msft.net>
 <1462578011-sup-7528@sabre>
 <CAM8C2CDQwyx6vLEZKD__FCjVBoDDowxB=znOWOv7-qKnNqw3bg@mail.gmail.com>
 <1462580960-sup-2046@sabre>
Message-ID: <08f58228f2b94986a7bddbed8f583a0f@DB4PR30MB030.064d.mgd.msft.net>

|  I think I need to pass in a 'CtGiven' for 'Show a'.  However, I don't
|  know what to pass as the evidence to the 'CtGiven'
|  constraints.  My guess is that it doesn't matter?

Correct, since you just want a yes/no answer.  Just make up some fresh Ids with newEvVar.

Simon

|  -----Original Message-----
|  From: Edward Z. Yang [mailto:ezyang at mit.edu]
|  Sent: 07 May 2016 01:34
|  To: David Fox <dsf at seereason.com>
|  Cc: Simon Peyton Jones <simonpj at microsoft.com>; ghc-devs <ghc-
|  devs at haskell.org>
|  Subject: Re: Determining if an instance is provided by the environment
|  
|  Well, I have to write the new variant of this function :)
|  
|  Simon, I ran into a minor complication: if my instance is something
|  like:
|  
|      instance Show a => Show [a]
|  
|  I think I need to pass in a 'CtGiven' for 'Show a'.  However, I don't
|  know what to pass as the evidence to the 'CtGiven'
|  constraints.  My guess is that it doesn't matter?
|  
|  Edward
|  
|  Excerpts from David Fox's message of 2016-05-06 17:06:41 -0700:
|  > Is there a way to connect this to template-haskell or haskell-src-
|  exts code?
|  >
|  > On Fri, May 6, 2016 at 4:40 PM, Edward Z. Yang <ezyang at mit.edu>
|  wrote:
|  >
|  > > Thanks Simon, that has all the ingredients I need.
|  > >
|  > > I wrote some more docs for the function:
|  > > https://phabricator.haskell.org/D2180
|  > >
|  > > Edward
|  > >
|  > > Excerpts from Simon Peyton Jones's message of 2016-05-06 02:05:31 -
|  0700:
|  > > > You probably want a variant on TcDeriv.simplifyDeriv, shorn of
|  its
|  > > complex error reporting.
|  > > >
|  > > > Simon
|  > > >
|  > > > |  -----Original Message-----
|  > > > |  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf
|  > > > | Of  Edward Z. Yang
|  > > > |  Sent: 06 May 2016 00:21
|  > > > |  To: ghc-devs <ghc-devs at haskell.org>
|  > > > |  Subject: Determining if an instance is provided by the
|  > > > | environment
|  > > > |
|  > > > |  Hello all,
|  > > > |
|  > > > |  Suppose I have a ClsInst from typechecking the following
|  > > > | instance
|  > > > |  declaration:
|  > > > |
|  > > > |      instance Show [Char] -- i.e. String
|  > > > |
|  > > > |  I'd now like to answer the question: "Is this instance
|  'provided'
|  > > > |  by the instance environment?"  For example, this instance is
|  > > > | provided  given that I have these two instances in the
|  environment:
|  > > > |
|  > > > |      instance Show a => Show [a] -- (1)
|  > > > |      instance Show Char          -- (2)
|  > > > |
|  > > > |  However, if I have just instance (1) in the environment, it's
|  > > > | not  provided (and if you tried to use show "foo", you'd get
|  the
|  > > > | error that  Char is not an instance of Show.)
|  > > > |
|  > > > |  Is there are convenient way to do this from TcM?  With
|  'tcMatchTys'
|  > > > |  and I can easily test if there is some instance in the
|  > > > | environment  which *matches* my instance head (e.g., Show [a]
|  > > > | matches Show [Char])  but this doesn't tell me if all the
|  > > > | resulting constraints are
|  > > solvable.
|  > > > |
|  > > > |  Thanks,
|  > > > |  Edward
|  > > > |  _______________________________________________
|  > > > |  ghc-devs mailing list
|  > > > |  ghc-devs at haskell.org
|  > > > |
|  > >
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail
|  > > .ha
|  > > > |  skell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
|  > > > |  devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com
|  > > %7c8c304d9b355244c6
|  > > > |
|  > >
|  ee7208d3753be740%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=iWdrnb
|  > > 6hC
|  > > > |  8pexyVkWNG22G%2fgdO10tCBy8nuCxhnO0M8%3d
|  > > _______________________________________________
|  > > ghc-devs mailing list
|  > > ghc-devs at haskell.org
|  > >
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail
|  > > .haskell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
|  devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c7183659043984718
|  62ec08d3760f3aa2%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=LU%2fYHTo
|  y3Y4lSkMdJZD4PrHyAvuWiMOOg0Xm9RE5OTg%3d
|  > >

From alois.cochard at gmail.com  Wed May 11 11:10:02 2016
From: alois.cochard at gmail.com (=?UTF-8?Q?Alo=C3=AFs_Cochard?=)
Date: Wed, 11 May 2016 13:10:02 +0200
Subject: Mentor for a JVM backend for GHC
In-Reply-To: <20160510024307.5886033.9548.19367@gmail.com>
References: <CANij+eRbvRcNGbMx23xGw2Q8LjZ4x4AzBwVyoi5oM5KfvF+A+Q@mail.gmail.com>
 <572E0A7C.8090208@nyu.edu>
 <CAJumaK_fzv9+N5MwWNtB_srK3Y3cPDo14CbT9huevk4Jn1xziw@mail.gmail.com>
 <CAJHA+wpzKPOb-j9wtLE6o7MaAHCwx+L9ot5dKtW87_544mqZsw@mail.gmail.com>
 <20160510024307.5886033.9548.19367@gmail.com>
Message-ID: <CAJHA+woA6wdLf71vgriv0MdErZo8L1ooKZDbWQJ6qU5CUVVuOA@mail.gmail.com>

Hi Rahul,

Thanks for the feedback, and good to hear you are thinking about using it
as an assembler!
First thing I'll have to do is to extract the assembler itself from "Kuna",
so it can be reused by yourself. I'll be happy to give support and
implement new features as needed, I know some important operations are
still missing but have a clear idea how to ad dthem.

Then a bit of history, where this project comes from, and why it had no
commit since December...

Long story short, I got trapped working on a FP library in Scala, and had
left this project aside in the meantime (had strong interest from folks
asking for me to look into this Scala stuff, and at the time not much
interest in Kuna... which the opposite of my personal preference... so I
was extremely happy to read your initial message here!).

Now back to our common interest, the reason I "chose" Core, it's because it
seems fundamentally impossible to avoid having an interpreter in order to
get stack safe execution of STG on the JVM. That is a fundamental
limitation, that is the core thing I want to experiment with... Creating a
JVM assembler and a minimal Lambda core calculus was kind of just an excuse
to get to this core issue (I'm thinking about control flow analysis and
complex program transformation/optimization in order to get there).

That being said, the path I would like to take is quite complex, full of
unknowns, I would love to share the ideas I have in mind, but I fear it
might be out of scope of your actual goal: getting a workable
implementation ASAP.

So, I suppose you are fine writing a small (hopefully performant) STG-like
Java interpreter used during runtime (that's basically what I'm trying to
avoid with my experiment), which I think is a reasonable path to follow in
order to get a GHC JVM implementation soon. I would be very interested to
help you on this, first by giving support on the JVM assembler (that will
be extracted from Kuna), then also by proposing myself as a mentor. I'm not
sure exactly how things goes there, how the process is handled... but I'll
learn about it, I did notify Edward Kmett of my interest.

My gut feeling is that it should be fine to use STG with the approach you
follow, I also feel some technics could be shared between GHC JVM and the
Kuna experiment (where the later could be seen as the a sandbox/test-bed
for the former).

Anyway as you said: "Again, all these issues can be looked at once a
performance baseline has been established.".

Totally agree, that's why I don't want to share too much of my experimental
ideas atm, let's focus on a realistic initial implementation (for which I
have lot of ideas to share as well). Again, I'm ready to assist you as much
as possible, implementation missing features in the assembler, I already
read so much of this specification..... ;-)

In case you are using IRC/IM/Gitter let me knows, so we could discuss more
directly.

Looking forward hearing from you,

Alo?s


On 10 May 2016 at 04:43, <rahulmutt at gmail.com> wrote:

> Hi Alois,
>
> I just checked out Kuna, and it looks like a great project. For others the
> link to the repo is https://github.com/aloiscochard/kuna. I think I'll go
> with it since not having to implement StackMapTables will save me a lot of
> time.
>
> I'm interested in your approach, can you explain more, especially the
> stack-safe bytecode part? And I noticed the last commit was in December. Is
> there any particular reason you stopped the project?
>
> I chose STG over Core because Core has an embedded language of coercions
> which complicates the code generation (or maybe they can simply be
> ignored?), and the terms are not in administrative normal form which
> requires more effort to manage. But a thought did cross my mind that
> certain Core optimizations might actually need to be turned off ?because
> the resulting STG might be in a form that might not get translated to the
> most efficient JVM bytecode. Again, all these issues can be looked at once
> a performance baseline has been established.
>
> Thanks,
> Rahul Muttineni
>
> Sent from my BlackBerry 10 smartphone.
> *From: *Alois Cochard
> *Sent: *Monday 9 May 2016 10:21 PM
> *To: *Edward Kmett
> *Cc: *ghc-devs at haskell.org
> *Subject: *Re: Mentor for a JVM backend for GHC
>
> Totally agree, Cmm is too late.
>
> My aim in Kuna was to start the transformation from Core, targeting
> stack-safe JVM bytecode without using Graal or the like.
>
> Yes, I am quite an optimistic person ;-) but I believe it's the path to
> take. I'm not interested in Frege like approach for various reasons,
> performance being one of them.
> On 7 May 2016 6:19 pm, "Edward Kmett" <ekmett at gmail.com> wrote:
>
>> By the time it has made it down to Cmm there are a lot of assumptions
>> about layout in memory -- everything is assumed to be a flat object
>> made out of 32-bit or 64-bit slots. These assumptions aren't really
>> suitable for the JVM.
>>
>> -Edward
>>
>> On Sat, May 7, 2016 at 11:32 AM, Thomas Jakway <tjakway at nyu.edu> wrote:
>> > This is a strange coincidence.  I'm definitely no expert GHC hacker but
>> I
>> > started (highly preliminary) work on a JVM backend for GHC a few weeks
>> ago.
>> > It's here:
>> https://github.com/tjakway/ghcjvm/tree/jvm/compiler/jvmGen/Jvm
>> > (The memory runtime is here: https://github.com/tjakway/lljvm)
>> >
>> > I'm very new to this so pardon my ignorance, but I don't understand
>> what the
>> > benefit is of intercepting STG code and translating that to bytecode vs.
>> > translating Cmm to bytecode (or Jasmin assembly, as I'd prefer)?  It
>> seems
>> > like Cmm is designed for backends and the obvious choice.  Or have I got
>> > this really mixed up?
>> >
>> > I hope this isn't out of line considering my overall lack of experience
>> but
>> > I think I can give some advice:
>> >
>> > read the JVM 7 spec cover-to-cover.
>> > I highly suggest outputting Jasmin assembly instead of raw bytecode.
>> The
>> > classfile format is complicated and you will have to essentially rewrite
>> > Jasmin in Haskell if you don't want to reuse it.  Jasmin is also the de
>> > facto standard assembler and much more thoroughly tested than any
>> homegrown
>> > solution we might make.
>> > read the LLVM code generator.  This project is more like the LLVM
>> backend
>> > than the native code generator.
>> > Don't go for speed.  The approach that I've begun is to emulate a C
>> stack
>> > and memory system the RTS can run on top of
>> > (
>> https://github.com/tjakway/lljvm/blob/master/src/main/java/lljvm/runtime/Memory.java
>> ).
>> > This will make getting something working much faster and also solves the
>> > problem of how to deal with memcpy/memset/memmove on the JVM.  This
>> will of
>> > course be very slow (I think) and is not a permanent solution.  Can't do
>> > everything at once.  Any other approach will probably require rewriting
>> the
>> > entire RTS from the beginning.
>> > I don't think Frege is especially useful to this project, though I'd
>> love to
>> > be proven wrong.  Frege's compilation model is completely different from
>> > GHC's: they compile Haskell to Java and then send that to javac.
>> Porting
>> > GHC to the JVM is really more like writing a Cmm to JVM compiler.
>> >
>> >
>> > I've heard of the LambdaVM project but couldn't find the actual code
>> > anywhere.  The site where it was hosted appears to be offline.  I'd
>> > certainly like to look at it if anyone knows where to find it.
>> >
>> > Information on Jasmin:
>> > http://web.mit.edu/javadev/packages/jasmin/doc/
>> > http://web.mit.edu/javadev/packages/jasmin/doc/instructions.html
>> > http://web.mit.edu/javadev/packages/jasmin/doc/about.html
>> >
>> > Once you've tried manually dealing with constant pools you'll appreciate
>> > Jonathan Meyer's work!
>> >
>> > I forked davidar's extended version of Jasmin.  The differences versus
>> the
>> > original Jasmin are detailed here.  Some nice additions:
>> >
>> > supports invokedynamic
>> > supports .annotation, .inner, .attribute, .deprecated directives
>> > better handling of the ldc_w instruction
>> > multi-line fields
>> > .debug directives
>> > signatures for local variables
>> > .bytecode directive to specify bytecode version
>> > (most importantly, I think): support for the StackMap attribute.  If we
>> > eventually want to use new JVM instructions like invokedynamic, we need
>> > stack map frames or the JVM will reject our bytecode.  JVM 7 has
>> options to
>> > bypass this (but it's a hack), but they're deprecated and I believe not
>> > optional going forward.  Alternatively we can stick with older bytecode
>> > versions indefinitely and not use the new features.
>> >
>> > (Just to be clear, I forked it in case it was deleted.  I didn't write
>> those
>> > features, the credit belongs to him).
>> >
>> > I think the biggest risk is taking too much on at once.  Any one of
>> these
>> > subtasks, writing a bytecode assembler, porting the RTS, etc. could
>> consume
>> > the whole summer if you're not careful.
>> >
>> > I'd love to help out with this project!
>> >
>> > Sincerely,
>> > Thomas Jakway
>> >
>> > -------
>> >
>> > Woops, after scrolling back through the emails it looks like someone
>> sent
>> > out the LambdaVM source.  I'll have to take a look at that.
>> >
>> >
>> >
>> > On 05/02/2016 11:26 AM, Rahul Muttineni wrote:
>> >
>> > Hi GHC Developers,
>> >
>> > I've started working on a JVM backend for GHC [1] and I'd love to work
>> on it
>> > as my Summer of Haskell project.
>> >
>> > Currently, the build system is setup using a mix of Shake (for the RTS
>> > build) and Stack (for the main compiler build) and I ensure that most
>> > commits build successfully. I have ported the core part of the
>> scheduler and
>> > ported over the fundamental types (Capability, StgTSO, Task, StgClosure,
>> > etc.) taking advantage of OOP in the implementation when I could.
>> >
>> > Additionally, I performed a non-trivial refactor of the hs-java package
>> > adding support for inner classes and fields which was very cumbersome
>> to do
>> > in the original package. On the frontend, I have tapped into the STG
>> code
>> > from the GHC 7.10.3 library and setup a CodeGen monad for generating JVM
>> > bytecode. The main task of generating the actual bytecode, porting the
>> more
>> > critical parts of the RTS, and adding support for the threaded RTS
>> remain.
>> >
>> > The strategy for compilation is as follows:
>> > - Intercept the STG code in the GHC pipeline
>> > - Convert from STG->JVM bytecode [2] in a similar manner as STG->Cmm
>> > preserving semantics as best as possible [3]
>> > - Port the GHC RTS (normal & threaded) to Java [4]
>> > - Put all the generated class files + RTS into a single jar to be run
>> > directly by the JVM.
>> >
>> > My objectives for the project during the summer are:
>> > - To implement the compilation strategy mentioned above
>> > - Implement the Java FFI for foreign imports. [5]
>> > - Implement the most important [6] PrimOps that GHC supports.
>> > - Port the base package replacing the C FFI imports with equivalent
>> Java FFI
>> > imports. [7]
>> >
>> > A little bit about myself: I spent a lot of time studying functional
>> > language implementation by reading SPJ's famous book and reading
>> research
>> > papers on related topics last summer as self-study.
>> >
>> > I took a break and resumed a couple months ago where I spent a lot of
>> time
>> > plowing through the STG->Cmm code generator as well as the RTS and going
>> > back and forth between them to get a clear understanding of how
>> everything
>> > works.
>> >
>> > Moreover, I compiled simple Haskell programs and observed the STG, Cmm,
>> and
>> > assembly output (by decompiling the final executable with objdump) to
>> > understand bits of the code generator where the source code wasn't that
>> > clear.
>> >
>> > I also spent a great deal of time studying the JVM internals, reading
>> the
>> > JVM spec, looking for any new features that could facilitate a high
>> > performance implementation [8].
>> >
>> > It would be great if someone with an understanding of nuances of the
>> RTS and
>> > code generator could mentor me for this project. It has been a blast so
>> far
>> > learning all the prerequisites and contemplating the design. I'd be very
>> > excited to take this on as a summer project.
>> >
>> > Also, given that I have hardly 5 days remaining, does anyone have
>> > suggestions on how I can structure the proposal without getting into too
>> > many details? There are still some parts of the design I haven't figured
>> > out, but I know I could find some solution when I get to it during the
>> > porting process.
>> >
>> > Thanks,
>> > Rahul Muttineni
>> >
>> > [1] http://github.com/rahulmutt/ghcvm
>> >
>> > [2] I intend to organically derive an IR at a later stage to allow for
>> some
>> > optimizations by looking at the final working implementation without an
>> IR
>> > and looking for patterns of repeated sequences of bytecode and assigning
>> > each sequence its own instruction in the IR.
>> >
>> > [3] Obviously, the lack of control of memory layouts (besides
>> allocating off
>> > the JVM heap using DirectByteBuffers) and lack of general tail calls
>> makes
>> > it tough to match the semantics of Cmm, but there are many solutions
>> around
>> > it, as can be found in the few papers on translating STG to Java/JVM
>> > bytecode.
>> >
>> > [4] This is the GHC RTS without GC and profiling since the JVM has great
>> > support for those already. Also, lots of care must be taken to ensure
>> that
>> > the lock semantics stays in tact during the port.
>> >
>> > [5] foreign exports will be dealt at a later stage, but I am taking
>> care of
>> > naming the closures nicely so that in the future you don't have to type
>> long
>> > names like the labels GHC compiles to call a Haskell function in Java.
>> >
>> > [6] Basically all the PrimOps that would be required to provide
>> plumbing for
>> > the Prelude functions that can compile beginner-level programs found in
>> > books such as Learn You a Haskell for Great Good.
>> >
>> > [7] I know that it's a lot more complicated than just replacing FFI
>> calls.
>> > I'd have to change around a lot of the code in base as well.
>> >
>> > [8] I found that the new "invokedynamic" instruction as well as the
>> > MethodHandle API (something like function pointers) that were
>> introduced in
>> > JDK 7 could fit the bill. But as of now, I want to get a baseline
>> > implementation that is compatible with Java 5 so I will not be utilizing
>> > these newer features.
>> >
>> >
>> >
>> > _______________________________________________
>> > 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
>>
>
>


-- 
*?\ois*
http://twitter.com/aloiscochard
http://github.com/aloiscochard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160511/b029a1f6/attachment-0001.html>

From ben at well-typed.com  Wed May 11 15:28:35 2016
From: ben at well-typed.com (Ben Gamari)
Date: Wed, 11 May 2016 17:28:35 +0200
Subject: vectorisation code?
In-Reply-To: <56A7A7AD.6030105@apeiron.net>
References: <54C039D0.4020206@apeiron.net>
 <6AA9EDDD-2444-4ADE-8675-793745BBA374@cse.unsw.edu.au>
 <618BE556AADD624C9C918AA5D5911BEF562AF251@DB3PRD3001MB020.064d.mgd.msft.net>
 <54C10257.5030907@apeiron.net> <87twziq0fo.fsf@gmail.com>
 <54C11F26.9080201@apeiron.net>
 <CE891DF4-53B1-44E3-B841-A0A0AA045EF3@cse.unsw.edu.au>
 <87io2lg3x4.fsf@smart-cactus.org> <56A239DF.4070006@apeiron.net>
 <CAD3WKgih9VuwfhgzBUBV2dqU6ha58y_3JZVggZTd2AvYtFQpKw@mail.gmail.com>
 <20160122145759.GA7974@apeiron.net>
 <3541c1a536d24f5794e432150833b428@DB4PR30MB030.064d.mgd.msft.net>
 <56A25776.20403@apeiron.net> <878u3ce0nr.fsf@smart-cactus.org>
 <56A7A7AD.6030105@apeiron.net>
Message-ID: <874ma462cc.fsf@smart-cactus.org>

Geoffrey Mainland <mainland at apeiron.net> writes:

> On 01/26/2016 12:00 PM, Ben Gamari wrote:
> 
>> We discussed this in today's meeting. The consensus seems to be that
>> this is worth doing; let's make it happen.
>>
>> As I mentioned yesterday, I would be happy to provide the infrastructure
>> necessary to produce full testsuite results on a nightly basis. I
>> already do nightly builds and setting up some sort of monitoring is
>> something that I've been meaning to do for some time now.
>>
>> Geoff, could you brush the cob-webs off of the vectoriser and post a
>> patch to Phabricator?
>>
>> Cheers,
>>
>> - Ben
>>
>
> Yes, I will take this on, but it may take a few months to happen.
>
Hi Geoff,

Has there been any motion on this front?

It would be great if we could get this taken care of soon.

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/20160511/f222a278/attachment.sig>

From ben at well-typed.com  Wed May 11 15:33:35 2016
From: ben at well-typed.com (Ben Gamari)
Date: Wed, 11 May 2016 17:33:35 +0200
Subject: [ANNOUNCE] GHC 8.0.1 source tarball available
References: <877ffpu3ax.fsf@smart-cactus.org>
Message-ID: <8737po6240.fsf@smart-cactus.org>

> [ Unknown signature status ]
tl;dr: If you would like to produce a binary distribution for GHC
       8.0.1 then let us know, grab the source distribution and start
       building. The binary distributions will be all released one week
       from today.


Hello GHC packagers,

I am happy to at long last announce the release of the 8.0.1 source
distribution to binary packagers. You will find the usual artifacts at

    http://downloads.haskell.org/~ghc/8.0.1/

These tarballs are derived from GHC commit

    e99c1e2516aeb283172c7e6898508238e33cf065.

For this release we are again following our new release policy [1],
with a one-week delay between the release of the source and binary
distributions. The goal of this policy is to give all platforms the
opportunity for support from the first day of a release.

If all of the expected binary releases are submitted before the
week-long delay has elapsed, we will move forward with the release of
the binaries on an accelerated schedule. It would be appreciated if you
could reply to this message confirming that you intend to offer a binary
distribution for this release.

Otherwise, let either Austin or I know if you have any trouble building
your distribution. As usual I'll hold off on pushing the release git tag
until we have a few binaries built in case we encounter unexpected
issues.

Good luck and thanks for all of your work!

Cheers,

- Ben


[1] https://mail.haskell.org/pipermail/ghc-devs/2016-March/011546.html
-------------- 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/20160511/06de07c8/attachment.sig>

From mainland at apeiron.net  Wed May 11 15:47:58 2016
From: mainland at apeiron.net (Geoffrey Mainland)
Date: Wed, 11 May 2016 11:47:58 -0400
Subject: vectorisation code?
In-Reply-To: <874ma462cc.fsf@smart-cactus.org>
References: <54C039D0.4020206@apeiron.net>
 <6AA9EDDD-2444-4ADE-8675-793745BBA374@cse.unsw.edu.au>
 <618BE556AADD624C9C918AA5D5911BEF562AF251@DB3PRD3001MB020.064d.mgd.msft.net>
 <54C10257.5030907@apeiron.net> <87twziq0fo.fsf@gmail.com>
 <54C11F26.9080201@apeiron.net>
 <CE891DF4-53B1-44E3-B841-A0A0AA045EF3@cse.unsw.edu.au>
 <87io2lg3x4.fsf@smart-cactus.org> <56A239DF.4070006@apeiron.net>
 <CAD3WKgih9VuwfhgzBUBV2dqU6ha58y_3JZVggZTd2AvYtFQpKw@mail.gmail.com>
 <20160122145759.GA7974@apeiron.net>
 <3541c1a536d24f5794e432150833b428@DB4PR30MB030.064d.mgd.msft.net>
 <56A25776.20403@apeiron.net> <878u3ce0nr.fsf@smart-cactus.org>
 <56A7A7AD.6030105@apeiron.net> <874ma462cc.fsf@smart-cactus.org>
Message-ID: <5733542E.4030509@apeiron.net>

On 05/11/2016 11:28 AM, Ben Gamari wrote:
> Geoffrey Mainland <mainland at apeiron.net> writes:
>
>> On 01/26/2016 12:00 PM, Ben Gamari wrote:
>>
>>> We discussed this in today's meeting. The consensus seems to be that
>>> this is worth doing; let's make it happen.
>>>
>>> As I mentioned yesterday, I would be happy to provide the infrastructure
>>> necessary to produce full testsuite results on a nightly basis. I
>>> already do nightly builds and setting up some sort of monitoring is
>>> something that I've been meaning to do for some time now.
>>>
>>> Geoff, could you brush the cob-webs off of the vectoriser and post a
>>> patch to Phabricator?
>>>
>>> Cheers,
>>>
>>> - Ben
>>>
>> Yes, I will take this on, but it may take a few months to happen.
>>
> Hi Geoff,
>
> Has there been any motion on this front?
>
> It would be great if we could get this taken care of soon.
>
> Cheers,
>
> - Ben
>

Hi Ben,

Progress is stalled on a rewrite of DPH's use of TH since TH is no
longer available in stage1. There is no reason this can't be worked
around, just that it's more work than I initially expected.

I agree that it would be good to get this taken care of soon, but that
is generically true of almost all things :) I was planning on getting
this done for 8.2. If there is a reason for more urgency, let's discuss.

Cheers,
Geoff

From ben at well-typed.com  Wed May 11 16:56:56 2016
From: ben at well-typed.com (Ben Gamari)
Date: Wed, 11 May 2016 18:56:56 +0200
Subject: vectorisation code?
In-Reply-To: <5733542E.4030509@apeiron.net>
References: <54C039D0.4020206@apeiron.net>
 <6AA9EDDD-2444-4ADE-8675-793745BBA374@cse.unsw.edu.au>
 <618BE556AADD624C9C918AA5D5911BEF562AF251@DB3PRD3001MB020.064d.mgd.msft.net>
 <54C10257.5030907@apeiron.net> <87twziq0fo.fsf@gmail.com>
 <54C11F26.9080201@apeiron.net>
 <CE891DF4-53B1-44E3-B841-A0A0AA045EF3@cse.unsw.edu.au>
 <87io2lg3x4.fsf@smart-cactus.org> <56A239DF.4070006@apeiron.net>
 <CAD3WKgih9VuwfhgzBUBV2dqU6ha58y_3JZVggZTd2AvYtFQpKw@mail.gmail.com>
 <20160122145759.GA7974@apeiron.net>
 <3541c1a536d24f5794e432150833b428@DB4PR30MB030.064d.mgd.msft.net>
 <56A25776.20403@apeiron.net> <878u3ce0nr.fsf@smart-cactus.org>
 <56A7A7AD.6030105@apeiron.net> <874ma462cc.fsf@smart-cactus.org>
 <5733542E.4030509@apeiron.net>
Message-ID: <87wpn04jon.fsf@smart-cactus.org>

Geoffrey Mainland <mainland at apeiron.net> writes:

> On 05/11/2016 11:28 AM, Ben Gamari wrote:
>> Geoffrey Mainland <mainland at apeiron.net> writes:
>>
>>> Yes, I will take this on, but it may take a few months to happen.
>>>
>> Hi Geoff,
>>
>> Has there been any motion on this front?
>>
>> It would be great if we could get this taken care of soon.
>>
>> Cheers,
>>
>> - Ben
>>
>
> Hi Ben,
>
> Progress is stalled on a rewrite of DPH's use of TH since TH is no
> longer available in stage1. There is no reason this can't be worked
> around, just that it's more work than I initially expected.
>
Alright, thanks for the update Geoff!

> I agree that it would be good to get this taken care of soon, but that
> is generically true of almost all things :) I was planning on getting
> this done for 8.2. If there is a reason for more urgency, let's discuss.
>
There's nothing terribly urgent, although it would be nice just to get
this sorted out. Out of curiosity is there a branch posted somewhere for
those of us who want to play along at home?

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/20160511/3049479b/attachment.sig>

From carter.schonwald at gmail.com  Wed May 11 17:02:57 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Wed, 11 May 2016 13:02:57 -0400
Subject: [ANNOUNCE] GHC 8.0.1 source tarball available
In-Reply-To: <8737po6240.fsf@smart-cactus.org>
References: <877ffpu3ax.fsf@smart-cactus.org> <8737po6240.fsf@smart-cactus.org>
Message-ID: <CAHYVw0xKONXWBm8DWncLMmGC-gpyNRLJMvHbi=eNBLb1m4S_YA@mail.gmail.com>

i hit tar: ghc-8.0.1/utils/haddock/doc/haddock/*: Cannot stat: No such file
or directory
whats that about?
i can try to poke at it this evening too



On Wed, May 11, 2016 at 11:33 AM, Ben Gamari <ben at well-typed.com> wrote:

> > [ Unknown signature status ]
> tl;dr: If you would like to produce a binary distribution for GHC
>        8.0.1 then let us know, grab the source distribution and start
>        building. The binary distributions will be all released one week
>        from today.
>
>
> Hello GHC packagers,
>
> I am happy to at long last announce the release of the 8.0.1 source
> distribution to binary packagers. You will find the usual artifacts at
>
>     http://downloads.haskell.org/~ghc/8.0.1/
>
> These tarballs are derived from GHC commit
>
>     e99c1e2516aeb283172c7e6898508238e33cf065.
>
> For this release we are again following our new release policy [1],
> with a one-week delay between the release of the source and binary
> distributions. The goal of this policy is to give all platforms the
> opportunity for support from the first day of a release.
>
> If all of the expected binary releases are submitted before the
> week-long delay has elapsed, we will move forward with the release of
> the binaries on an accelerated schedule. It would be appreciated if you
> could reply to this message confirming that you intend to offer a binary
> distribution for this release.
>
> Otherwise, let either Austin or I know if you have any trouble building
> your distribution. As usual I'll hold off on pushing the release git tag
> until we have a few binaries built in case we encounter unexpected
> issues.
>
> Good luck and thanks for all of your work!
>
> Cheers,
>
> - Ben
>
>
> [1] https://mail.haskell.org/pipermail/ghc-devs/2016-March/011546.html
>
> _______________________________________________
> 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/20160511/36704322/attachment.html>

From carter.schonwald at gmail.com  Wed May 11 17:25:20 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Wed, 11 May 2016 13:25:20 -0400
Subject: [ANNOUNCE] GHC 8.0.1 source tarball available
In-Reply-To: <CAHYVw0xKONXWBm8DWncLMmGC-gpyNRLJMvHbi=eNBLb1m4S_YA@mail.gmail.com>
References: <877ffpu3ax.fsf@smart-cactus.org> <8737po6240.fsf@smart-cactus.org>
 <CAHYVw0xKONXWBm8DWncLMmGC-gpyNRLJMvHbi=eNBLb1m4S_YA@mail.gmail.com>
Message-ID: <CAHYVw0ybp50MpiUCHK_RqSpYd2uxZQfSUcJAP+1kopMBjADR7w@mail.gmail.com>

that build confusion aside:
https://wellposed-carter-files.s3.amazonaws.com/opensource/ghc/releasebuild-unofficial/ghc-8.0.1-x86_64-apple-darwin-gcc5.tar.xz

shasum -a512 ghc-8.0.1-x86_64-apple-darwin-gcc5.tar.xz
54025a674cf95eaf5f26f46617164592266b76f17c740f17feb134208c7e6e25d1b685a9fc95877a3449c0e496492d8a55da2dae6ddade6a8cc8de8441415073
is the hash of the build i've uploaded

On Wed, May 11, 2016 at 1:02 PM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> i hit tar: ghc-8.0.1/utils/haddock/doc/haddock/*: Cannot stat: No such
> file or directory
> whats that about?
> i can try to poke at it this evening too
>
>
>
> On Wed, May 11, 2016 at 11:33 AM, Ben Gamari <ben at well-typed.com> wrote:
>
>> > [ Unknown signature status ]
>> tl;dr: If you would like to produce a binary distribution for GHC
>>        8.0.1 then let us know, grab the source distribution and start
>>        building. The binary distributions will be all released one week
>>        from today.
>>
>>
>> Hello GHC packagers,
>>
>> I am happy to at long last announce the release of the 8.0.1 source
>> distribution to binary packagers. You will find the usual artifacts at
>>
>>     http://downloads.haskell.org/~ghc/8.0.1/
>>
>> These tarballs are derived from GHC commit
>>
>>     e99c1e2516aeb283172c7e6898508238e33cf065.
>>
>> For this release we are again following our new release policy [1],
>> with a one-week delay between the release of the source and binary
>> distributions. The goal of this policy is to give all platforms the
>> opportunity for support from the first day of a release.
>>
>> If all of the expected binary releases are submitted before the
>> week-long delay has elapsed, we will move forward with the release of
>> the binaries on an accelerated schedule. It would be appreciated if you
>> could reply to this message confirming that you intend to offer a binary
>> distribution for this release.
>>
>> Otherwise, let either Austin or I know if you have any trouble building
>> your distribution. As usual I'll hold off on pushing the release git tag
>> until we have a few binaries built in case we encounter unexpected
>> issues.
>>
>> Good luck and thanks for all of your work!
>>
>> Cheers,
>>
>> - Ben
>>
>>
>> [1] https://mail.haskell.org/pipermail/ghc-devs/2016-March/011546.html
>>
>> _______________________________________________
>> 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/20160511/a687546a/attachment-0001.html>

From ben at well-typed.com  Wed May 11 18:21:26 2016
From: ben at well-typed.com (Ben Gamari)
Date: Wed, 11 May 2016 20:21:26 +0200
Subject: [ANNOUNCE] GHC 8.0.1 source tarball available
In-Reply-To: <8737po6240.fsf@smart-cactus.org>
References: <877ffpu3ax.fsf@smart-cactus.org> <8737po6240.fsf@smart-cactus.org>
Message-ID: <87mvnw4frt.fsf@smart-cactus.org>

Ben Gamari <ben at well-typed.com> writes:

> [ Unknown signature status ]
>> [ Unknown signature status ]
> tl;dr: If you would like to produce a binary distribution for GHC
>        8.0.1 then let us know, grab the source distribution and start
>        building. The binary distributions will be all released one week
>        from today.
>
>
> Hello GHC packagers,
>
Given that there appear to be haddock issues, perhaps builders should
hold off a little bit on building more distributions. I'll try to have a
look into the issue shortly (although wasn't able to reproduce the
failure the first time around).

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/20160511/66a1036d/attachment.sig>

From george.colpitts at gmail.com  Wed May 11 19:42:17 2016
From: george.colpitts at gmail.com (George Colpitts)
Date: Wed, 11 May 2016 19:42:17 +0000
Subject: [ANNOUNCE] GHC 8.0.1 source tarball available
In-Reply-To: <CAHYVw0xKONXWBm8DWncLMmGC-gpyNRLJMvHbi=eNBLb1m4S_YA@mail.gmail.com>
References: <877ffpu3ax.fsf@smart-cactus.org> <8737po6240.fsf@smart-cactus.org>
 <CAHYVw0xKONXWBm8DWncLMmGC-gpyNRLJMvHbi=eNBLb1m4S_YA@mail.gmail.com>
Message-ID: <CAB-d4A4hcygsOQWuYe+rkN075NqxYrCzEQofMPN+yvcNxviocQ@mail.gmail.com>

I didn't hit that issue AFAIK, the build seemed to go fine (on a mac)

On Wed, May 11, 2016 at 2:03 PM Carter Schonwald <carter.schonwald at gmail.com>
wrote:

> i hit tar: ghc-8.0.1/utils/haddock/doc/haddock/*: Cannot stat: No such
> file or directory
> whats that about?
> i can try to poke at it this evening too
>
>
>
> On Wed, May 11, 2016 at 11:33 AM, Ben Gamari <ben at well-typed.com> wrote:
>
>> > [ Unknown signature status ]
>> tl;dr: If you would like to produce a binary distribution for GHC
>>        8.0.1 then let us know, grab the source distribution and start
>>        building. The binary distributions will be all released one week
>>        from today.
>>
>>
>> Hello GHC packagers,
>>
>> I am happy to at long last announce the release of the 8.0.1 source
>> distribution to binary packagers. You will find the usual artifacts at
>>
>>     http://downloads.haskell.org/~ghc/8.0.1/
>>
>> These tarballs are derived from GHC commit
>>
>>     e99c1e2516aeb283172c7e6898508238e33cf065.
>>
>> For this release we are again following our new release policy [1],
>> with a one-week delay between the release of the source and binary
>> distributions. The goal of this policy is to give all platforms the
>> opportunity for support from the first day of a release.
>>
>> If all of the expected binary releases are submitted before the
>> week-long delay has elapsed, we will move forward with the release of
>> the binaries on an accelerated schedule. It would be appreciated if you
>> could reply to this message confirming that you intend to offer a binary
>> distribution for this release.
>>
>> Otherwise, let either Austin or I know if you have any trouble building
>> your distribution. As usual I'll hold off on pushing the release git tag
>> until we have a few binaries built in case we encounter unexpected
>> issues.
>>
>> Good luck and thanks for all of your work!
>>
>> Cheers,
>>
>> - Ben
>>
>>
>> [1] https://mail.haskell.org/pipermail/ghc-devs/2016-March/011546.html
>>
>> _______________________________________________
>> 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/20160511/e81ab8f8/attachment.html>

From george.colpitts at gmail.com  Wed May 11 22:31:10 2016
From: george.colpitts at gmail.com (George Colpitts)
Date: Wed, 11 May 2016 22:31:10 +0000
Subject: [ANNOUNCE] GHC 8.0.1 source tarball available
In-Reply-To: <CAB-d4A4hcygsOQWuYe+rkN075NqxYrCzEQofMPN+yvcNxviocQ@mail.gmail.com>
References: <877ffpu3ax.fsf@smart-cactus.org> <8737po6240.fsf@smart-cactus.org>
 <CAHYVw0xKONXWBm8DWncLMmGC-gpyNRLJMvHbi=eNBLb1m4S_YA@mail.gmail.com>
 <CAB-d4A4hcygsOQWuYe+rkN075NqxYrCzEQofMPN+yvcNxviocQ@mail.gmail.com>
Message-ID: <CAB-d4A5F2pt5uSGmoXH9e458cMp=ekMBoZ5kWRhfJWMR5F0q5w@mail.gmail.com>

Sorry maybe I did hit it when I did a make install, it ended

cp: utils/haddock/doc/haddock: No such file or directory
bash-3.2$

Carter, not sure if that is the same issue you encountered

Thanks
George

On Wed, May 11, 2016 at 4:42 PM George Colpitts <george.colpitts at gmail.com>
wrote:

> I didn't hit that issue AFAIK, the build seemed to go fine (on a mac)
>
>
> On Wed, May 11, 2016 at 2:03 PM Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
>
>> i hit tar: ghc-8.0.1/utils/haddock/doc/haddock/*: Cannot stat: No such
>> file or directory
>> whats that about?
>> i can try to poke at it this evening too
>>
>>
>>
>> On Wed, May 11, 2016 at 11:33 AM, Ben Gamari <ben at well-typed.com> wrote:
>>
>>> > [ Unknown signature status ]
>>> tl;dr: If you would like to produce a binary distribution for GHC
>>>        8.0.1 then let us know, grab the source distribution and start
>>>        building. The binary distributions will be all released one week
>>>        from today.
>>>
>>>
>>> Hello GHC packagers,
>>>
>>> I am happy to at long last announce the release of the 8.0.1 source
>>> distribution to binary packagers. You will find the usual artifacts at
>>>
>>>     http://downloads.haskell.org/~ghc/8.0.1/
>>>
>>> These tarballs are derived from GHC commit
>>>
>>>     e99c1e2516aeb283172c7e6898508238e33cf065.
>>>
>>> For this release we are again following our new release policy [1],
>>> with a one-week delay between the release of the source and binary
>>> distributions. The goal of this policy is to give all platforms the
>>> opportunity for support from the first day of a release.
>>>
>>> If all of the expected binary releases are submitted before the
>>> week-long delay has elapsed, we will move forward with the release of
>>> the binaries on an accelerated schedule. It would be appreciated if you
>>> could reply to this message confirming that you intend to offer a binary
>>> distribution for this release.
>>>
>>> Otherwise, let either Austin or I know if you have any trouble building
>>> your distribution. As usual I'll hold off on pushing the release git tag
>>> until we have a few binaries built in case we encounter unexpected
>>> issues.
>>>
>>> Good luck and thanks for all of your work!
>>>
>>> Cheers,
>>>
>>> - Ben
>>>
>>>
>>> [1] https://mail.haskell.org/pipermail/ghc-devs/2016-March/011546.html
>>>
>>> _______________________________________________
>>> 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/20160511/3a4ee57d/attachment.html>

From carter.schonwald at gmail.com  Wed May 11 23:19:50 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Wed, 11 May 2016 19:19:50 -0400
Subject: [ANNOUNCE] GHC 8.0.1 source tarball available
In-Reply-To: <CAB-d4A5F2pt5uSGmoXH9e458cMp=ekMBoZ5kWRhfJWMR5F0q5w@mail.gmail.com>
References: <877ffpu3ax.fsf@smart-cactus.org> <8737po6240.fsf@smart-cactus.org>
 <CAHYVw0xKONXWBm8DWncLMmGC-gpyNRLJMvHbi=eNBLb1m4S_YA@mail.gmail.com>
 <CAB-d4A4hcygsOQWuYe+rkN075NqxYrCzEQofMPN+yvcNxviocQ@mail.gmail.com>
 <CAB-d4A5F2pt5uSGmoXH9e458cMp=ekMBoZ5kWRhfJWMR5F0q5w@mail.gmail.com>
Message-ID: <CAHYVw0wjnaRHQ3E0o3B6beaJ2KnJU9AsGLjO_MRkhyc-ytdFtw@mail.gmail.com>

Yup

On Wednesday, May 11, 2016, George Colpitts <george.colpitts at gmail.com>
wrote:

> Sorry maybe I did hit it when I did a make install, it ended
>
> cp: utils/haddock/doc/haddock: No such file or directory
> bash-3.2$
>
> Carter, not sure if that is the same issue you encountered
>
> Thanks
> George
>
> On Wed, May 11, 2016 at 4:42 PM George Colpitts <george.colpitts at gmail.com
> <javascript:_e(%7B%7D,'cvml','george.colpitts at gmail.com');>> wrote:
>
>> I didn't hit that issue AFAIK, the build seemed to go fine (on a mac)
>>
>>
>> On Wed, May 11, 2016 at 2:03 PM Carter Schonwald <
>> carter.schonwald at gmail.com
>> <javascript:_e(%7B%7D,'cvml','carter.schonwald at gmail.com');>> wrote:
>>
>>> i hit tar: ghc-8.0.1/utils/haddock/doc/haddock/*: Cannot stat: No such
>>> file or directory
>>> whats that about?
>>> i can try to poke at it this evening too
>>>
>>>
>>>
>>> On Wed, May 11, 2016 at 11:33 AM, Ben Gamari <ben at well-typed.com
>>> <javascript:_e(%7B%7D,'cvml','ben at well-typed.com');>> wrote:
>>>
>>>> > [ Unknown signature status ]
>>>> tl;dr: If you would like to produce a binary distribution for GHC
>>>>        8.0.1 then let us know, grab the source distribution and start
>>>>        building. The binary distributions will be all released one week
>>>>        from today.
>>>>
>>>>
>>>> Hello GHC packagers,
>>>>
>>>> I am happy to at long last announce the release of the 8.0.1 source
>>>> distribution to binary packagers. You will find the usual artifacts at
>>>>
>>>>     http://downloads.haskell.org/~ghc/8.0.1/
>>>>
>>>> These tarballs are derived from GHC commit
>>>>
>>>>     e99c1e2516aeb283172c7e6898508238e33cf065.
>>>>
>>>> For this release we are again following our new release policy [1],
>>>> with a one-week delay between the release of the source and binary
>>>> distributions. The goal of this policy is to give all platforms the
>>>> opportunity for support from the first day of a release.
>>>>
>>>> If all of the expected binary releases are submitted before the
>>>> week-long delay has elapsed, we will move forward with the release of
>>>> the binaries on an accelerated schedule. It would be appreciated if you
>>>> could reply to this message confirming that you intend to offer a binary
>>>> distribution for this release.
>>>>
>>>> Otherwise, let either Austin or I know if you have any trouble building
>>>> your distribution. As usual I'll hold off on pushing the release git tag
>>>> until we have a few binaries built in case we encounter unexpected
>>>> issues.
>>>>
>>>> Good luck and thanks for all of your work!
>>>>
>>>> Cheers,
>>>>
>>>> - Ben
>>>>
>>>>
>>>> [1] https://mail.haskell.org/pipermail/ghc-devs/2016-March/011546.html
>>>>
>>>> _______________________________________________
>>>> ghc-devs mailing list
>>>> ghc-devs at haskell.org
>>>> <javascript:_e(%7B%7D,'cvml','ghc-devs at haskell.org');>
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>>
>>>>
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> <javascript:_e(%7B%7D,'cvml','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/20160511/564523e0/attachment-0001.html>

From dan.doel at gmail.com  Thu May 12 00:11:50 2016
From: dan.doel at gmail.com (Dan Doel)
Date: Wed, 11 May 2016 20:11:50 -0400
Subject: suboptimal ghc code generation in IO vs equivalent pure code case
In-Reply-To: <CAPW+kkaUwUcDK-CROAYLTqjh42WehPEiU1iygCMWYWLgYAz7TQ@mail.gmail.com>
References: <CAPW+kkbszGf8_UfVc6sE7b3A6UHMfB04N03DBj_UZ9W02ofS=Q@mail.gmail.com>
 <CAHEA9tObezBkM7MZtczO+r6cUK=r2eYruNFmw1CbejZfQzYyDA@mail.gmail.com>
 <CAPW+kkaUwUcDK-CROAYLTqjh42WehPEiU1iygCMWYWLgYAz7TQ@mail.gmail.com>
Message-ID: <CAHEA9tP_YT=u+DukGtU3VRM4HxsLQdh_DCk0CzaDp7h7dd-JOQ@mail.gmail.com>

On Tue, May 10, 2016 at 4:45 AM, Harendra Kumar
<harendra.kumar at gmail.com> wrote:
> Thanks Dan, that helped. I did notice and suspect the update frame and the
> unboxed tuple but given my limited knowledge about ghc/core/stg/cmm I was
> not sure what is going on. In fact I thought that the intermediate tuple
> should get optimized out since it is required only because of the realworld
> token which is not real. But it might be difficult to see that at this
> level?

The token exists as far as the STG level is concerned, I think,
because that is the only thing ensuring that things happen in the
right order. And the closure must be built to have properly formed
STG. So optimizing away the closure building would have to happen at a
level lower than STG, and I guess there is no such optimization. I'm
not sure how easy it would be to do.

> What you are saying may be true for the current implementation but in theory
> can we eliminate the intermediate closure?

I don't know. I'm a bit skeptical that building this one closure is
the only thing causing your code to be a factor of 5 slower. For
instance, another difference in the core is that the recursive call
corresponding to the result s2 happens before allocating the
additional closure. That is the case statement that unpacks the
unboxed tuple. And the whole loop happens this way, so it is actually
building a structure corresponding to the entire output list in memory
rather eagerly.

By contrast, your pure function is able to act in a streaming fashion,
if consumed properly, where only enough of the result is built to keep
driving the rest of the program. It probably runs in constant space,
while your IO-based loop has a footprint linear in the size of the
input list (in addition to having slightly more overhead per character
because of the one extra thunk), because it is a more eager program.

And having an asymptotically larger memory footprint is more likely to
explain a 5x slowdown than allocating one extra thunk for each list
concatenation, I think. (Of course, it could also be some other
factor, as well.)

You should probably run with +RTS -s (compiling with -rtsopts), and
see if the IO version has a much larger maximum residency.

Anyhow, this is fundamental to writing the algorithm using IO. It's an
algorithm that's a sequence of steps that happen in order, the number
of steps is proportional to the input list, and part of those steps is
putting stuff in memory for the results.

> So why is that? Why can't we generate (++) inline similar to (:)? How do we
> make this decision? Is there a theoretical reason for this or this is just
> an implementation artifact?

The difference between these two is that (++) is a function call, and
(:) is a constructor. Constructors are a special case, and don't need
to have all the provisions that functions in general do. The best way
to learn what the differences are is probably to read the paper about
the STG machine.

Hope this is a more fruitful lead, but it may be that there's not a
lot that can be done, without doing some baroque things to your
algorithm, because of the necessity of its using IO.

-- Dan

From george.colpitts at gmail.com  Thu May 12 00:12:36 2016
From: george.colpitts at gmail.com (George Colpitts)
Date: Thu, 12 May 2016 00:12:36 +0000
Subject: [ANNOUNCE] GHC 8.0.1 source tarball available
In-Reply-To: <CAHYVw0xKONXWBm8DWncLMmGC-gpyNRLJMvHbi=eNBLb1m4S_YA@mail.gmail.com>
References: <877ffpu3ax.fsf@smart-cactus.org> <8737po6240.fsf@smart-cactus.org>
 <CAHYVw0xKONXWBm8DWncLMmGC-gpyNRLJMvHbi=eNBLb1m4S_YA@mail.gmail.com>
Message-ID: <CAB-d4A4mAmyj=q_pnDzoOB5rrQx9VkzfUuUtYpWWEnstTRpk+Q@mail.gmail.com>

Using the ghc I built from the source tarball I encountered a problem  in
doing a cabal install -j5 hlint (on a Mac). I got

cabal install -j5 hlint
...
Failed to install extra-1.4.6
Build log ( /Users/gcolpitts/.cabal/logs/extra-1.4.6.log ):
/Users/gcolpitts/.cabal/logs/extra-1.4.6.log: openFile: does not exist (No
such file or directory)

I didn't have this problem with earlier versions of ghc 8 when did cabal
install hlint but I'm not sure if the versions involved in previous hlint
components were the same

Cheers
George


On Wed, May 11, 2016 at 2:03 PM Carter Schonwald <carter.schonwald at gmail.com>
wrote:

> i hit tar: ghc-8.0.1/utils/haddock/doc/haddock/*: Cannot stat: No such
> file or directory
> whats that about?
> i can try to poke at it this evening too
>
>
>
> On Wed, May 11, 2016 at 11:33 AM, Ben Gamari <ben at well-typed.com> wrote:
>
>> > [ Unknown signature status ]
>> tl;dr: If you would like to produce a binary distribution for GHC
>>        8.0.1 then let us know, grab the source distribution and start
>>        building. The binary distributions will be all released one week
>>        from today.
>>
>>
>> Hello GHC packagers,
>>
>> I am happy to at long last announce the release of the 8.0.1 source
>> distribution to binary packagers. You will find the usual artifacts at
>>
>>     http://downloads.haskell.org/~ghc/8.0.1/
>>
>> These tarballs are derived from GHC commit
>>
>>     e99c1e2516aeb283172c7e6898508238e33cf065.
>>
>> For this release we are again following our new release policy [1],
>> with a one-week delay between the release of the source and binary
>> distributions. The goal of this policy is to give all platforms the
>> opportunity for support from the first day of a release.
>>
>> If all of the expected binary releases are submitted before the
>> week-long delay has elapsed, we will move forward with the release of
>> the binaries on an accelerated schedule. It would be appreciated if you
>> could reply to this message confirming that you intend to offer a binary
>> distribution for this release.
>>
>> Otherwise, let either Austin or I know if you have any trouble building
>> your distribution. As usual I'll hold off on pushing the release git tag
>> until we have a few binaries built in case we encounter unexpected
>> issues.
>>
>> Good luck and thanks for all of your work!
>>
>> Cheers,
>>
>> - Ben
>>
>>
>> [1] https://mail.haskell.org/pipermail/ghc-devs/2016-March/011546.html
>>
>> _______________________________________________
>> 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/20160512/19fc210f/attachment.html>

From george.colpitts at gmail.com  Thu May 12 00:51:34 2016
From: george.colpitts at gmail.com (George Colpitts)
Date: Thu, 12 May 2016 00:51:34 +0000
Subject: [ANNOUNCE] GHC 8.0.1 source tarball available
In-Reply-To: <CAB-d4A4mAmyj=q_pnDzoOB5rrQx9VkzfUuUtYpWWEnstTRpk+Q@mail.gmail.com>
References: <877ffpu3ax.fsf@smart-cactus.org> <8737po6240.fsf@smart-cactus.org>
 <CAHYVw0xKONXWBm8DWncLMmGC-gpyNRLJMvHbi=eNBLb1m4S_YA@mail.gmail.com>
 <CAB-d4A4mAmyj=q_pnDzoOB5rrQx9VkzfUuUtYpWWEnstTRpk+Q@mail.gmail.com>
Message-ID: <CAB-d4A6voMVK+B5rUYndO-AYGADG+eGrsHLPyz+b0YwYQrjASw@mail.gmail.com>

seems to be intermittent, I have got past this problem

On Wed, May 11, 2016 at 9:12 PM George Colpitts <george.colpitts at gmail.com>
wrote:

> Using the ghc I built from the source tarball I encountered a problem  in
> doing a cabal install -j5 hlint (on a Mac). I got
>
> cabal install -j5 hlint
> ...
> Failed to install extra-1.4.6
> Build log ( /Users/gcolpitts/.cabal/logs/extra-1.4.6.log ):
> /Users/gcolpitts/.cabal/logs/extra-1.4.6.log: openFile: does not exist (No
> such file or directory)
>
> I didn't have this problem with earlier versions of ghc 8 when did cabal
> install hlint but I'm not sure if the versions involved in previous hlint
> components were the same
>
> Cheers
> George
>
>
> On Wed, May 11, 2016 at 2:03 PM Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
>
>> i hit tar: ghc-8.0.1/utils/haddock/doc/haddock/*: Cannot stat: No such
>> file or directory
>> whats that about?
>> i can try to poke at it this evening too
>>
>>
>>
>> On Wed, May 11, 2016 at 11:33 AM, Ben Gamari <ben at well-typed.com> wrote:
>>
>>> > [ Unknown signature status ]
>>> tl;dr: If you would like to produce a binary distribution for GHC
>>>        8.0.1 then let us know, grab the source distribution and start
>>>        building. The binary distributions will be all released one week
>>>        from today.
>>>
>>>
>>> Hello GHC packagers,
>>>
>>> I am happy to at long last announce the release of the 8.0.1 source
>>> distribution to binary packagers. You will find the usual artifacts at
>>>
>>>     http://downloads.haskell.org/~ghc/8.0.1/
>>>
>>> These tarballs are derived from GHC commit
>>>
>>>     e99c1e2516aeb283172c7e6898508238e33cf065.
>>>
>>> For this release we are again following our new release policy [1],
>>> with a one-week delay between the release of the source and binary
>>> distributions. The goal of this policy is to give all platforms the
>>> opportunity for support from the first day of a release.
>>>
>>> If all of the expected binary releases are submitted before the
>>> week-long delay has elapsed, we will move forward with the release of
>>> the binaries on an accelerated schedule. It would be appreciated if you
>>> could reply to this message confirming that you intend to offer a binary
>>> distribution for this release.
>>>
>>> Otherwise, let either Austin or I know if you have any trouble building
>>> your distribution. As usual I'll hold off on pushing the release git tag
>>> until we have a few binaries built in case we encounter unexpected
>>> issues.
>>>
>>> Good luck and thanks for all of your work!
>>>
>>> Cheers,
>>>
>>> - Ben
>>>
>>>
>>> [1] https://mail.haskell.org/pipermail/ghc-devs/2016-March/011546.html
>>>
>>> _______________________________________________
>>> 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/20160512/c4ebb4e1/attachment.html>

From carter.schonwald at gmail.com  Thu May 12 02:51:18 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Wed, 11 May 2016 22:51:18 -0400
Subject: [ANNOUNCE] GHC 8.0.1 source tarball available
In-Reply-To: <CAB-d4A6voMVK+B5rUYndO-AYGADG+eGrsHLPyz+b0YwYQrjASw@mail.gmail.com>
References: <877ffpu3ax.fsf@smart-cactus.org> <8737po6240.fsf@smart-cactus.org>
 <CAHYVw0xKONXWBm8DWncLMmGC-gpyNRLJMvHbi=eNBLb1m4S_YA@mail.gmail.com>
 <CAB-d4A4mAmyj=q_pnDzoOB5rrQx9VkzfUuUtYpWWEnstTRpk+Q@mail.gmail.com>
 <CAB-d4A6voMVK+B5rUYndO-AYGADG+eGrsHLPyz+b0YwYQrjASw@mail.gmail.com>
Message-ID: <CAHYVw0zgOFQT+OzOLCaL9FW_XJyMnAUTBC5D_acwhEBexc-5xA@mail.gmail.com>

Which version of cabal the binary vs Cabal the lib  etc did you use?

Is this package level parallel builds or module level?
I definitely hit a hard to reproduce problem where sublime Haskell would
sometimes hang on stderr output from a vanilla cabal build invocation.

What command let's you reproduce it intermittently? Also how many cores /
ram does the machine have?

On Wednesday, May 11, 2016, George Colpitts <george.colpitts at gmail.com>
wrote:

> seems to be intermittent, I have got past this problem
>
> On Wed, May 11, 2016 at 9:12 PM George Colpitts <george.colpitts at gmail.com
> <javascript:_e(%7B%7D,'cvml','george.colpitts at gmail.com');>> wrote:
>
>> Using the ghc I built from the source tarball I encountered a problem  in
>> doing a cabal install -j5 hlint (on a Mac). I got
>>
>> cabal install -j5 hlint
>> ...
>> Failed to install extra-1.4.6
>> Build log ( /Users/gcolpitts/.cabal/logs/extra-1.4.6.log ):
>> /Users/gcolpitts/.cabal/logs/extra-1.4.6.log: openFile: does not exist (No
>> such file or directory)
>>
>> I didn't have this problem with earlier versions of ghc 8 when did cabal
>> install hlint but I'm not sure if the versions involved in previous hlint
>> components were the same
>>
>> Cheers
>> George
>>
>>
>> On Wed, May 11, 2016 at 2:03 PM Carter Schonwald <
>> carter.schonwald at gmail.com
>> <javascript:_e(%7B%7D,'cvml','carter.schonwald at gmail.com');>> wrote:
>>
>>> i hit tar: ghc-8.0.1/utils/haddock/doc/haddock/*: Cannot stat: No such
>>> file or directory
>>> whats that about?
>>> i can try to poke at it this evening too
>>>
>>>
>>>
>>> On Wed, May 11, 2016 at 11:33 AM, Ben Gamari <ben at well-typed.com
>>> <javascript:_e(%7B%7D,'cvml','ben at well-typed.com');>> wrote:
>>>
>>>> > [ Unknown signature status ]
>>>> tl;dr: If you would like to produce a binary distribution for GHC
>>>>        8.0.1 then let us know, grab the source distribution and start
>>>>        building. The binary distributions will be all released one week
>>>>        from today.
>>>>
>>>>
>>>> Hello GHC packagers,
>>>>
>>>> I am happy to at long last announce the release of the 8.0.1 source
>>>> distribution to binary packagers. You will find the usual artifacts at
>>>>
>>>>     http://downloads.haskell.org/~ghc/8.0.1/
>>>>
>>>> These tarballs are derived from GHC commit
>>>>
>>>>     e99c1e2516aeb283172c7e6898508238e33cf065.
>>>>
>>>> For this release we are again following our new release policy [1],
>>>> with a one-week delay between the release of the source and binary
>>>> distributions. The goal of this policy is to give all platforms the
>>>> opportunity for support from the first day of a release.
>>>>
>>>> If all of the expected binary releases are submitted before the
>>>> week-long delay has elapsed, we will move forward with the release of
>>>> the binaries on an accelerated schedule. It would be appreciated if you
>>>> could reply to this message confirming that you intend to offer a binary
>>>> distribution for this release.
>>>>
>>>> Otherwise, let either Austin or I know if you have any trouble building
>>>> your distribution. As usual I'll hold off on pushing the release git tag
>>>> until we have a few binaries built in case we encounter unexpected
>>>> issues.
>>>>
>>>> Good luck and thanks for all of your work!
>>>>
>>>> Cheers,
>>>>
>>>> - Ben
>>>>
>>>>
>>>> [1] https://mail.haskell.org/pipermail/ghc-devs/2016-March/011546.html
>>>>
>>>> _______________________________________________
>>>> ghc-devs mailing list
>>>> ghc-devs at haskell.org
>>>> <javascript:_e(%7B%7D,'cvml','ghc-devs at haskell.org');>
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>>
>>>>
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> <javascript:_e(%7B%7D,'cvml','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/20160511/4cee4858/attachment-0001.html>

From juhpetersen at gmail.com  Thu May 12 05:24:34 2016
From: juhpetersen at gmail.com (Jens Petersen)
Date: Thu, 12 May 2016 14:24:34 +0900
Subject: [ANNOUNCE] GHC 8.0.1 source tarball available
In-Reply-To: <8737po6240.fsf@smart-cactus.org>
References: <877ffpu3ax.fsf@smart-cactus.org> <8737po6240.fsf@smart-cactus.org>
Message-ID: <CAEDGBq+93NbkotcTqG-kiq3Ck5WFRN4N6NTx_Lwf_eFzKx04hw@mail.gmail.com>

On 12 May 2016 at 00:33, Ben Gamari <ben at well-typed.com> wrote:
> I am happy to at long last announce the release of the 8.0.1 source
> distribution to binary packagers.

I am going to build it in my Fedora Copr repo.

One thing I noticed is that Cabal got reverted from version 1.24.1.0
in RC4 to 1.24.0.0?
Is that intentional?
(I managed to build cabal-install-1.24.0.0 with Cabal-1.24.1.0 but not
1.24.0.0 with RC4.)

Thanks, Jens

From ben at well-typed.com  Thu May 12 10:47:05 2016
From: ben at well-typed.com (Ben Gamari)
Date: Thu, 12 May 2016 12:47:05 +0200
Subject: [ANNOUNCE] GHC 8.0.1 source tarball available
In-Reply-To: <8737po6240.fsf@smart-cactus.org>
References: <877ffpu3ax.fsf@smart-cactus.org> <8737po6240.fsf@smart-cactus.org>
Message-ID: <87y47f3652.fsf@smart-cactus.org>

Ben Gamari <ben at well-typed.com> writes:

> [ Unknown signature status ]
>> [ Unknown signature status ]
> tl;dr: If you would like to produce a binary distribution for GHC
>        8.0.1 then let us know, grab the source distribution and start
>        building. The binary distributions will be all released one week
>        from today.
>
>
> Hello GHC packagers,
>
> I am happy to at long last announce the release of the 8.0.1 source
> distribution to binary packagers. You will find the usual artifacts at
>
>     http://downloads.haskell.org/~ghc/8.0.1/
>
> These tarballs are derived from GHC commit
>
Sorry about the false start earlier. It seems there were a few tricky
bits in the integration between haddock and GHC's build system that
weren't quite right. This should be fixed now.

I've pushed the result to the ghc-8.0 branch and have pushed a set of
new source tarballs to the usual URL. The new release commit is

    b594f8191273f4c913bc8413d30fd3061bb577c1

Again, I'll hold off a bit longer in pushing the tag in case there are
further issues. As always, let me know if you have any issues (and
thanks to those who alerted me of the Haddock issue).

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/20160512/9347e10e/attachment.sig>

From hvriedel at gmail.com  Thu May 12 10:52:11 2016
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Thu, 12 May 2016 12:52:11 +0200
Subject: [ANNOUNCE] GHC 8.0.1 source tarball available
In-Reply-To: <87y47f3652.fsf@smart-cactus.org> (Ben Gamari's message of "Thu, 
 12 May 2016 12:47:05 +0200")
References: <877ffpu3ax.fsf@smart-cactus.org>
 <8737po6240.fsf@smart-cactus.org> <87y47f3652.fsf@smart-cactus.org>
Message-ID: <87mvnvblb8.fsf@gmail.com>

On 2016-05-12 at 12:47:05 +0200, Ben Gamari wrote:

[...]

> I've pushed the result to the ghc-8.0 branch and have pushed a set of
> new source tarballs to the usual URL. The new release commit is
>
>     b594f8191273f4c913bc8413d30fd3061bb577c1

fyi, an easy way to verify you have the intended tarball is:

$ tar xOf ghc-8.0.1-src.tar.xz ghc-8.0.1/GIT_COMMIT_ID; echo
e99c1e2516aeb283172c7e6898508238e33cf065

(that's the old one)


PS: I've just been told the md5sum of the new tarball is
    94da3386c0de519eeea37586edd90187
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160512/2d1dc855/attachment.sig>

From rahulmutt at gmail.com  Thu May 12 19:14:34 2016
From: rahulmutt at gmail.com (Rahul Muttineni)
Date: Fri, 13 May 2016 00:44:34 +0530
Subject: Mentor for a JVM backend for GHC
In-Reply-To: <CAJHA+woA6wdLf71vgriv0MdErZo8L1ooKZDbWQJ6qU5CUVVuOA@mail.gmail.com>
References: <CANij+eRbvRcNGbMx23xGw2Q8LjZ4x4AzBwVyoi5oM5KfvF+A+Q@mail.gmail.com>
 <572E0A7C.8090208@nyu.edu>
 <CAJumaK_fzv9+N5MwWNtB_srK3Y3cPDo14CbT9huevk4Jn1xziw@mail.gmail.com>
 <CAJHA+wpzKPOb-j9wtLE6o7MaAHCwx+L9ot5dKtW87_544mqZsw@mail.gmail.com>
 <20160510024307.5886033.9548.19367@gmail.com>
 <CAJHA+woA6wdLf71vgriv0MdErZo8L1ooKZDbWQJ6qU5CUVVuOA@mail.gmail.com>
Message-ID: <CANij+eSaM+6+dB6dwjd6kCyBqYBQxo9vo_8a-GuGdA2=2WwzQA@mail.gmail.com>

Hi Alois,

I can see a nice feedback loop between GHCVM and Kuna that can help
accelerate both projects. Let's this discuss offline so that this thread
isn't flooded with a discussion that will probably get lost in time later?
We'll try to keep the results of our discussions public, either in the
GHCVM Wiki or elsewhere so that people know what's going on.

Thanks,
Rahul


On Wed, May 11, 2016 at 4:40 PM, Alo?s Cochard <alois.cochard at gmail.com>
wrote:

> Hi Rahul,
>
> Thanks for the feedback, and good to hear you are thinking about using it
> as an assembler!
> First thing I'll have to do is to extract the assembler itself from
> "Kuna", so it can be reused by yourself. I'll be happy to give support and
> implement new features as needed, I know some important operations are
> still missing but have a clear idea how to ad dthem.
>
> Then a bit of history, where this project comes from, and why it had no
> commit since December...
>
> Long story short, I got trapped working on a FP library in Scala, and had
> left this project aside in the meantime (had strong interest from folks
> asking for me to look into this Scala stuff, and at the time not much
> interest in Kuna... which the opposite of my personal preference... so I
> was extremely happy to read your initial message here!).
>
> Now back to our common interest, the reason I "chose" Core, it's because
> it seems fundamentally impossible to avoid having an interpreter in order
> to get stack safe execution of STG on the JVM. That is a fundamental
> limitation, that is the core thing I want to experiment with... Creating a
> JVM assembler and a minimal Lambda core calculus was kind of just an excuse
> to get to this core issue (I'm thinking about control flow analysis and
> complex program transformation/optimization in order to get there).
>
> That being said, the path I would like to take is quite complex, full of
> unknowns, I would love to share the ideas I have in mind, but I fear it
> might be out of scope of your actual goal: getting a workable
> implementation ASAP.
>
> So, I suppose you are fine writing a small (hopefully performant) STG-like
> Java interpreter used during runtime (that's basically what I'm trying to
> avoid with my experiment), which I think is a reasonable path to follow in
> order to get a GHC JVM implementation soon. I would be very interested to
> help you on this, first by giving support on the JVM assembler (that will
> be extracted from Kuna), then also by proposing myself as a mentor. I'm not
> sure exactly how things goes there, how the process is handled... but I'll
> learn about it, I did notify Edward Kmett of my interest.
>
> My gut feeling is that it should be fine to use STG with the approach you
> follow, I also feel some technics could be shared between GHC JVM and the
> Kuna experiment (where the later could be seen as the a sandbox/test-bed
> for the former).
>
> Anyway as you said: "Again, all these issues can be looked at once a
> performance baseline has been established.".
>
> Totally agree, that's why I don't want to share too much of my
> experimental ideas atm, let's focus on a realistic initial implementation
> (for which I have lot of ideas to share as well). Again, I'm ready to
> assist you as much as possible, implementation missing features in the
> assembler, I already read so much of this specification..... ;-)
>
> In case you are using IRC/IM/Gitter let me knows, so we could discuss more
> directly.
>
> Looking forward hearing from you,
>
> Alo?s
>
>
> On 10 May 2016 at 04:43, <rahulmutt at gmail.com> wrote:
>
>> Hi Alois,
>>
>> I just checked out Kuna, and it looks like a great project. For others
>> the link to the repo is https://github.com/aloiscochard/kuna. I think
>> I'll go with it since not having to implement StackMapTables will save me a
>> lot of time.
>>
>> I'm interested in your approach, can you explain more, especially the
>> stack-safe bytecode part? And I noticed the last commit was in December. Is
>> there any particular reason you stopped the project?
>>
>> I chose STG over Core because Core has an embedded language of coercions
>> which complicates the code generation (or maybe they can simply be
>> ignored?), and the terms are not in administrative normal form which
>> requires more effort to manage. But a thought did cross my mind that
>> certain Core optimizations might actually need to be turned off ?because
>> the resulting STG might be in a form that might not get translated to the
>> most efficient JVM bytecode. Again, all these issues can be looked at once
>> a performance baseline has been established.
>>
>> Thanks,
>> Rahul Muttineni
>>
>> Sent from my BlackBerry 10 smartphone.
>> *From: *Alois Cochard
>> *Sent: *Monday 9 May 2016 10:21 PM
>> *To: *Edward Kmett
>> *Cc: *ghc-devs at haskell.org
>> *Subject: *Re: Mentor for a JVM backend for GHC
>>
>> Totally agree, Cmm is too late.
>>
>> My aim in Kuna was to start the transformation from Core, targeting
>> stack-safe JVM bytecode without using Graal or the like.
>>
>> Yes, I am quite an optimistic person ;-) but I believe it's the path to
>> take. I'm not interested in Frege like approach for various reasons,
>> performance being one of them.
>> On 7 May 2016 6:19 pm, "Edward Kmett" <ekmett at gmail.com> wrote:
>>
>>> By the time it has made it down to Cmm there are a lot of assumptions
>>> about layout in memory -- everything is assumed to be a flat object
>>> made out of 32-bit or 64-bit slots. These assumptions aren't really
>>> suitable for the JVM.
>>>
>>> -Edward
>>>
>>> On Sat, May 7, 2016 at 11:32 AM, Thomas Jakway <tjakway at nyu.edu> wrote:
>>> > This is a strange coincidence.  I'm definitely no expert GHC hacker
>>> but I
>>> > started (highly preliminary) work on a JVM backend for GHC a few weeks
>>> ago.
>>> > It's here:
>>> https://github.com/tjakway/ghcjvm/tree/jvm/compiler/jvmGen/Jvm
>>> > (The memory runtime is here: https://github.com/tjakway/lljvm)
>>> >
>>> > I'm very new to this so pardon my ignorance, but I don't understand
>>> what the
>>> > benefit is of intercepting STG code and translating that to bytecode
>>> vs.
>>> > translating Cmm to bytecode (or Jasmin assembly, as I'd prefer)?  It
>>> seems
>>> > like Cmm is designed for backends and the obvious choice.  Or have I
>>> got
>>> > this really mixed up?
>>> >
>>> > I hope this isn't out of line considering my overall lack of
>>> experience but
>>> > I think I can give some advice:
>>> >
>>> > read the JVM 7 spec cover-to-cover.
>>> > I highly suggest outputting Jasmin assembly instead of raw bytecode.
>>> The
>>> > classfile format is complicated and you will have to essentially
>>> rewrite
>>> > Jasmin in Haskell if you don't want to reuse it.  Jasmin is also the de
>>> > facto standard assembler and much more thoroughly tested than any
>>> homegrown
>>> > solution we might make.
>>> > read the LLVM code generator.  This project is more like the LLVM
>>> backend
>>> > than the native code generator.
>>> > Don't go for speed.  The approach that I've begun is to emulate a C
>>> stack
>>> > and memory system the RTS can run on top of
>>> > (
>>> https://github.com/tjakway/lljvm/blob/master/src/main/java/lljvm/runtime/Memory.java
>>> ).
>>> > This will make getting something working much faster and also solves
>>> the
>>> > problem of how to deal with memcpy/memset/memmove on the JVM.  This
>>> will of
>>> > course be very slow (I think) and is not a permanent solution.  Can't
>>> do
>>> > everything at once.  Any other approach will probably require
>>> rewriting the
>>> > entire RTS from the beginning.
>>> > I don't think Frege is especially useful to this project, though I'd
>>> love to
>>> > be proven wrong.  Frege's compilation model is completely different
>>> from
>>> > GHC's: they compile Haskell to Java and then send that to javac.
>>> Porting
>>> > GHC to the JVM is really more like writing a Cmm to JVM compiler.
>>> >
>>> >
>>> > I've heard of the LambdaVM project but couldn't find the actual code
>>> > anywhere.  The site where it was hosted appears to be offline.  I'd
>>> > certainly like to look at it if anyone knows where to find it.
>>> >
>>> > Information on Jasmin:
>>> > http://web.mit.edu/javadev/packages/jasmin/doc/
>>> > http://web.mit.edu/javadev/packages/jasmin/doc/instructions.html
>>> > http://web.mit.edu/javadev/packages/jasmin/doc/about.html
>>> >
>>> > Once you've tried manually dealing with constant pools you'll
>>> appreciate
>>> > Jonathan Meyer's work!
>>> >
>>> > I forked davidar's extended version of Jasmin.  The differences versus
>>> the
>>> > original Jasmin are detailed here.  Some nice additions:
>>> >
>>> > supports invokedynamic
>>> > supports .annotation, .inner, .attribute, .deprecated directives
>>> > better handling of the ldc_w instruction
>>> > multi-line fields
>>> > .debug directives
>>> > signatures for local variables
>>> > .bytecode directive to specify bytecode version
>>> > (most importantly, I think): support for the StackMap attribute.  If we
>>> > eventually want to use new JVM instructions like invokedynamic, we need
>>> > stack map frames or the JVM will reject our bytecode.  JVM 7 has
>>> options to
>>> > bypass this (but it's a hack), but they're deprecated and I believe not
>>> > optional going forward.  Alternatively we can stick with older bytecode
>>> > versions indefinitely and not use the new features.
>>> >
>>> > (Just to be clear, I forked it in case it was deleted.  I didn't write
>>> those
>>> > features, the credit belongs to him).
>>> >
>>> > I think the biggest risk is taking too much on at once.  Any one of
>>> these
>>> > subtasks, writing a bytecode assembler, porting the RTS, etc. could
>>> consume
>>> > the whole summer if you're not careful.
>>> >
>>> > I'd love to help out with this project!
>>> >
>>> > Sincerely,
>>> > Thomas Jakway
>>> >
>>> > -------
>>> >
>>> > Woops, after scrolling back through the emails it looks like someone
>>> sent
>>> > out the LambdaVM source.  I'll have to take a look at that.
>>> >
>>> >
>>> >
>>> > On 05/02/2016 11:26 AM, Rahul Muttineni wrote:
>>> >
>>> > Hi GHC Developers,
>>> >
>>> > I've started working on a JVM backend for GHC [1] and I'd love to work
>>> on it
>>> > as my Summer of Haskell project.
>>> >
>>> > Currently, the build system is setup using a mix of Shake (for the RTS
>>> > build) and Stack (for the main compiler build) and I ensure that most
>>> > commits build successfully. I have ported the core part of the
>>> scheduler and
>>> > ported over the fundamental types (Capability, StgTSO, Task,
>>> StgClosure,
>>> > etc.) taking advantage of OOP in the implementation when I could.
>>> >
>>> > Additionally, I performed a non-trivial refactor of the hs-java package
>>> > adding support for inner classes and fields which was very cumbersome
>>> to do
>>> > in the original package. On the frontend, I have tapped into the STG
>>> code
>>> > from the GHC 7.10.3 library and setup a CodeGen monad for generating
>>> JVM
>>> > bytecode. The main task of generating the actual bytecode, porting the
>>> more
>>> > critical parts of the RTS, and adding support for the threaded RTS
>>> remain.
>>> >
>>> > The strategy for compilation is as follows:
>>> > - Intercept the STG code in the GHC pipeline
>>> > - Convert from STG->JVM bytecode [2] in a similar manner as STG->Cmm
>>> > preserving semantics as best as possible [3]
>>> > - Port the GHC RTS (normal & threaded) to Java [4]
>>> > - Put all the generated class files + RTS into a single jar to be run
>>> > directly by the JVM.
>>> >
>>> > My objectives for the project during the summer are:
>>> > - To implement the compilation strategy mentioned above
>>> > - Implement the Java FFI for foreign imports. [5]
>>> > - Implement the most important [6] PrimOps that GHC supports.
>>> > - Port the base package replacing the C FFI imports with equivalent
>>> Java FFI
>>> > imports. [7]
>>> >
>>> > A little bit about myself: I spent a lot of time studying functional
>>> > language implementation by reading SPJ's famous book and reading
>>> research
>>> > papers on related topics last summer as self-study.
>>> >
>>> > I took a break and resumed a couple months ago where I spent a lot of
>>> time
>>> > plowing through the STG->Cmm code generator as well as the RTS and
>>> going
>>> > back and forth between them to get a clear understanding of how
>>> everything
>>> > works.
>>> >
>>> > Moreover, I compiled simple Haskell programs and observed the STG,
>>> Cmm, and
>>> > assembly output (by decompiling the final executable with objdump) to
>>> > understand bits of the code generator where the source code wasn't that
>>> > clear.
>>> >
>>> > I also spent a great deal of time studying the JVM internals, reading
>>> the
>>> > JVM spec, looking for any new features that could facilitate a high
>>> > performance implementation [8].
>>> >
>>> > It would be great if someone with an understanding of nuances of the
>>> RTS and
>>> > code generator could mentor me for this project. It has been a blast
>>> so far
>>> > learning all the prerequisites and contemplating the design. I'd be
>>> very
>>> > excited to take this on as a summer project.
>>> >
>>> > Also, given that I have hardly 5 days remaining, does anyone have
>>> > suggestions on how I can structure the proposal without getting into
>>> too
>>> > many details? There are still some parts of the design I haven't
>>> figured
>>> > out, but I know I could find some solution when I get to it during the
>>> > porting process.
>>> >
>>> > Thanks,
>>> > Rahul Muttineni
>>> >
>>> > [1] http://github.com/rahulmutt/ghcvm
>>> >
>>> > [2] I intend to organically derive an IR at a later stage to allow for
>>> some
>>> > optimizations by looking at the final working implementation without
>>> an IR
>>> > and looking for patterns of repeated sequences of bytecode and
>>> assigning
>>> > each sequence its own instruction in the IR.
>>> >
>>> > [3] Obviously, the lack of control of memory layouts (besides
>>> allocating off
>>> > the JVM heap using DirectByteBuffers) and lack of general tail calls
>>> makes
>>> > it tough to match the semantics of Cmm, but there are many solutions
>>> around
>>> > it, as can be found in the few papers on translating STG to Java/JVM
>>> > bytecode.
>>> >
>>> > [4] This is the GHC RTS without GC and profiling since the JVM has
>>> great
>>> > support for those already. Also, lots of care must be taken to ensure
>>> that
>>> > the lock semantics stays in tact during the port.
>>> >
>>> > [5] foreign exports will be dealt at a later stage, but I am taking
>>> care of
>>> > naming the closures nicely so that in the future you don't have to
>>> type long
>>> > names like the labels GHC compiles to call a Haskell function in Java.
>>> >
>>> > [6] Basically all the PrimOps that would be required to provide
>>> plumbing for
>>> > the Prelude functions that can compile beginner-level programs found in
>>> > books such as Learn You a Haskell for Great Good.
>>> >
>>> > [7] I know that it's a lot more complicated than just replacing FFI
>>> calls.
>>> > I'd have to change around a lot of the code in base as well.
>>> >
>>> > [8] I found that the new "invokedynamic" instruction as well as the
>>> > MethodHandle API (something like function pointers) that were
>>> introduced in
>>> > JDK 7 could fit the bill. But as of now, I want to get a baseline
>>> > implementation that is compatible with Java 5 so I will not be
>>> utilizing
>>> > these newer features.
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > 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
>>>
>>
>>
>
>
> --
> *?\ois*
> http://twitter.com/aloiscochard
> http://github.com/aloiscochard
>



-- 
Rahul Muttineni
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160513/6e89a2e2/attachment-0001.html>

From carter.schonwald at gmail.com  Thu May 12 21:14:36 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Thu, 12 May 2016 17:14:36 -0400
Subject: [ANNOUNCE] GHC 8.0.1 source tarball available
In-Reply-To: <87mvnvblb8.fsf@gmail.com>
References: <877ffpu3ax.fsf@smart-cactus.org> <8737po6240.fsf@smart-cactus.org>
 <87y47f3652.fsf@smart-cactus.org> <87mvnvblb8.fsf@gmail.com>
Message-ID: <CAHYVw0wvic5CoFB-Ez28e4kXjaerO9N6wYiOL-PbsVZ+6yeJwA@mail.gmail.com>

my built with the fresher tarball (matching the md5 sum that herbert
mentions)
is at
https://wellposed-carter-files.s3.amazonaws.com/opensource/ghc/releasebuild-unofficial/ghc-8.0.1-x86_64-apple-darwin-built-with-gcc5.tar.xz

and the sha info is
shasum -a512 ghc-8.0.1-x86_64-apple-darwin-built-with-gcc5.tar.xz
e6a1688e4bdb96328f866ec79bb6182e3d49833a86099026078effa3556d5d96832a10e095a0fe92d35480fbe243f6472c3361217955ac0e758ea6814cd295bd

On Thu, May 12, 2016 at 6:52 AM, Herbert Valerio Riedel <hvriedel at gmail.com>
wrote:

> On 2016-05-12 at 12:47:05 +0200, Ben Gamari wrote:
>
> [...]
>
> > I've pushed the result to the ghc-8.0 branch and have pushed a set of
> > new source tarballs to the usual URL. The new release commit is
> >
> >     b594f8191273f4c913bc8413d30fd3061bb577c1
>
> fyi, an easy way to verify you have the intended tarball is:
>
> $ tar xOf ghc-8.0.1-src.tar.xz ghc-8.0.1/GIT_COMMIT_ID; echo
> e99c1e2516aeb283172c7e6898508238e33cf065
>
> (that's the old one)
>
>
> PS: I've just been told the md5sum of the new tarball is
>     94da3386c0de519eeea37586edd90187
>
> _______________________________________________
> 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/20160512/cc886bc4/attachment.html>

From ezyang at mit.edu  Thu May 12 22:40:03 2016
From: ezyang at mit.edu (Edward Z. Yang)
Date: Thu, 12 May 2016 15:40:03 -0700
Subject: Stop rejecting Summary: Signed-off-by: ... OR patch Phabricator
Message-ID: <1463092518-sup-2918@sabre>

Hey guys,

Currently the commit hooks reject commit messages that look like:

    Summary: Signed-off-by: Edward Z. Yang <ezyang at cs.stanford.edu>

Unfortunately, if I do a one line commit message with -s, Phabricator
will automatically reformat my message to have this.

This is dumb. Either:

    1) You should stop rejecting these commit messages, or

    2) You should patch Phabricator to stop munging the messages
    this way.  The message formatting is done server-side so as
    a client I have no way of changing it, you need to fix it.
    This URL has some guidance on how to do it:
        https://secure.phabricator.com/T6055

I'd offer to edit the hook myself but there does not seem to be
any canonical location where the hooks are versioned.

Thanks,
Edward

From pali.gabor at gmail.com  Fri May 13 05:55:05 2016
From: pali.gabor at gmail.com (=?UTF-8?B?UMOhbGkgR8OhYm9yIErDoW5vcw==?=)
Date: Fri, 13 May 2016 07:55:05 +0200
Subject: [ANNOUNCE] GHC 8.0.1 source tarball available
In-Reply-To: <87y47f3652.fsf@smart-cactus.org>
References: <877ffpu3ax.fsf@smart-cactus.org> <8737po6240.fsf@smart-cactus.org>
 <87y47f3652.fsf@smart-cactus.org>
Message-ID: <CAHnG2CyGG8du==yXO1Wy_Jz43wsTnhbAcVNaFoHHrJa3=vDYRQ@mail.gmail.com>

Hi there,

2016-05-12 12:47 GMT+02:00 Ben Gamari <ben at well-typed.com>:
> Ben Gamari <ben at well-typed.com> writes:
> Sorry about the false start earlier. It seems there were a few tricky
> bits in the integration between haddock and GHC's build system that
> weren't quite right. This should be fixed now.

I have tried to build the source tarball on FreeBSD, but it always
stops somewhere around the documentation bits with the following error
message:

[..]
make -C utils/haddock/doc html SPHINX_BUILD=/usr/local/bin/sphinx-build
make: illegal option -- -
usage: make [-BPSXeiknpqrstv] [-C directory] [-D variable]
        [-d flags] [-E variable] [-f makefile] [-I directory]
        [-j max_jobs] [-m directory] [-V variable]
        [variable=value] [target ...]
utils/haddock/doc/ghc.mk:22: recipe for target 'html_utils/haddock/doc' failed
gmake[1]: *** [html_utils/haddock/doc] Error 2
Makefile:129: recipe for target 'all' failed
gmake: *** [all] Error 2

That is probably because FreeBSD has GNU make(1) as `gmake`, it should
be invoked with that name.  I suspect that, for some reason (which is
unknown to me), the value of the $(MAKE) variable is not respected at
the recursive invocation of make(1).

Unfortunately, I will not have the time to figure this out today, so I
am just reporting this without a proposal for the fix.

Thanks,
G?bor

From pali.gabor at gmail.com  Fri May 13 05:58:58 2016
From: pali.gabor at gmail.com (=?UTF-8?B?UMOhbGkgR8OhYm9yIErDoW5vcw==?=)
Date: Fri, 13 May 2016 07:58:58 +0200
Subject: [ANNOUNCE] GHC 8.0.1 source tarball available
In-Reply-To: <CAHnG2CyGG8du==yXO1Wy_Jz43wsTnhbAcVNaFoHHrJa3=vDYRQ@mail.gmail.com>
References: <877ffpu3ax.fsf@smart-cactus.org> <8737po6240.fsf@smart-cactus.org>
 <87y47f3652.fsf@smart-cactus.org>
 <CAHnG2CyGG8du==yXO1Wy_Jz43wsTnhbAcVNaFoHHrJa3=vDYRQ@mail.gmail.com>
Message-ID: <CAHnG2CyCA13Yvxc9ce2OgogEcP04MUy7_4YiyKcbAFRmBEaSSA@mail.gmail.com>

2016-05-13 7:55 GMT+02:00 P?li G?bor J?nos <pali.gabor at gmail.com>:
> That is probably because FreeBSD has GNU make(1) as `gmake`, it should
> be invoked with that name.  I suspect that, for some reason (which is
> unknown to me), the value of the $(MAKE) variable is not respected at
> the recursive invocation of make(1).
>
> Unfortunately, I will not have the time to figure this out today, so I
> am just reporting this without a proposal for the fix.

Ohh, I was quick to surrender: all you have to do is to
s/make/$(MAKE)/ in line 22 at utils/haddock/doc/ghc.mk.

From hvriedel at gmail.com  Fri May 13 07:00:38 2016
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Fri, 13 May 2016 09:00:38 +0200
Subject: Stop rejecting Summary: Signed-off-by: ... OR patch Phabricator
In-Reply-To: <1463092518-sup-2918@sabre> (Edward Z. Yang's message of "Thu, 12
 May 2016 15:40:03 -0700")
References: <1463092518-sup-2918@sabre>
Message-ID: <87oa8av3vt.fsf@gmail.com>

On 2016-05-13 at 00:40:03 +0200, Edward Z. Yang wrote:
> Currently the commit hooks reject commit messages that look like:
>
>     Summary: Signed-off-by: Edward Z. Yang <ezyang at cs.stanford.edu>
>
> Unfortunately, if I do a one line commit message with -s, Phabricator
> will automatically reformat my message to have this.

...and that's exactly why I invested time to write that hook in the
first place, because Phabricator blatantly violates Git convention
regarding the git commit message format. Stock Phabricator insists on
its own "structured" Git commit format, thereby breaking almost every
Git-tool which expects the usual git-trailer grammar.

I've been meaning to fix this (and another related issue of Phabricator
using whitespaces in trailer-keys[1] which unsurpisingly breaks git
tooling as well but for a different reason, as well as the annoying
issue of Signed-off-by lines sometimes confusing Phabricator...*sigh*)
in Phabricator for some time but never got to it, but...

>     2) You should patch Phabricator to stop munging the messages
>     this way.  The message formatting is done server-side so as
>     a client I have no way of changing it, you need to fix it.
>     This URL has some guidance on how to do it:
>         https://secure.phabricator.com/T6055
>
> I'd offer to edit the hook myself but there does not seem to be
> any canonical location where the hooks are versioned.

...I've tried to patch phabricator as suggested in T6055 (and commented
there), but it seems I need to tweak Phabricator's commit msg parser as
well...



 [1]: E.g. "Reviewed By:" instead of the better supported "Reviewed-by:",
      see e.g. https://git.wiki.kernel.org/index.php/CommitMessageConventions
  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160513/db6f9fa8/attachment.sig>

From trp at bluewin.ch  Fri May 13 14:38:01 2016
From: trp at bluewin.ch (Peter Trommler)
Date: Fri, 13 May 2016 16:38:01 +0200
Subject: arc stopped working
Message-ID: <0BAC1400-110C-4012-81BB-4A545AD303E6@bluewin.ch>

Hi *,

I am getting the following error message from arc:

peter at montebre:/local/home/peter/ghc> arc diff
Usage Exception: Failed to load phutil library at location '/local/home/peter/ghc/.arc-linters/arcanist-external-json-linter'. This library is specified by the "load" setting in ".arcconfig". Check that the setting is correct and the library is located in the right place.

I looked at '/local/home/peter/ghc/.arc-linters/arcanist-external-json-linter' and it is an empty directory.
`arc upgrade` did not fix the issue.

What can I do to fix arc?

Thanks, Peter

From eric at seidel.io  Fri May 13 14:50:31 2016
From: eric at seidel.io (Eric Seidel)
Date: Fri, 13 May 2016 07:50:31 -0700
Subject: arc stopped working
In-Reply-To: <0BAC1400-110C-4012-81BB-4A545AD303E6@bluewin.ch>
References: <0BAC1400-110C-4012-81BB-4A545AD303E6@bluewin.ch>
Message-ID: <1463151031.2331199.606989057.5B7B6F28@webmail.messagingengine.com>

Have you tried `git submodule update --init`? I believe the arc linter
is a submodule.

On Fri, May 13, 2016, at 07:38, Peter Trommler wrote:
> Hi *,
> 
> I am getting the following error message from arc:
> 
> peter at montebre:/local/home/peter/ghc> arc diff
> Usage Exception: Failed to load phutil library at location
> '/local/home/peter/ghc/.arc-linters/arcanist-external-json-linter'. This
> library is specified by the "load" setting in ".arcconfig". Check that
> the setting is correct and the library is located in the right place.
> 
> I looked at
> '/local/home/peter/ghc/.arc-linters/arcanist-external-json-linter' and it
> is an empty directory.
> `arc upgrade` did not fix the issue.
> 
> What can I do to fix arc?
> 
> Thanks, Peter
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From trp at bluewin.ch  Fri May 13 15:03:11 2016
From: trp at bluewin.ch (Peter Trommler)
Date: Fri, 13 May 2016 17:03:11 +0200
Subject: arc stopped working
In-Reply-To: <1463151031.2331199.606989057.5B7B6F28@webmail.messagingengine.com>
References: <0BAC1400-110C-4012-81BB-4A545AD303E6@bluewin.ch>
 <1463151031.2331199.606989057.5B7B6F28@webmail.messagingengine.com>
Message-ID: <A572BFD0-63B7-42A0-8B6E-0A49CB1A22C8@bluewin.ch>

Hi Eric,

Thanks a lot. That fixed arc for me.

Peter

> On 13.05.2016, at 16:50, Eric Seidel <eric at seidel.io> wrote:
> 
> Have you tried `git submodule update --init`? I believe the arc linter
> is a submodule.
> 
> On Fri, May 13, 2016, at 07:38, Peter Trommler wrote:
>> Hi *,
>> 
>> I am getting the following error message from arc:
>> 
>> peter at montebre:/local/home/peter/ghc> arc diff
>> Usage Exception: Failed to load phutil library at location
>> '/local/home/peter/ghc/.arc-linters/arcanist-external-json-linter'. This
>> library is specified by the "load" setting in ".arcconfig". Check that
>> the setting is correct and the library is located in the right place.
>> 
>> I looked at
>> '/local/home/peter/ghc/.arc-linters/arcanist-external-json-linter' and it
>> is an empty directory.
>> `arc upgrade` did not fix the issue.
>> 
>> What can I do to fix arc?
>> 
>> Thanks, Peter
>> _______________________________________________
>> 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 pali.gabor at gmail.com  Sat May 14 06:49:27 2016
From: pali.gabor at gmail.com (=?UTF-8?B?UMOhbGkgR8OhYm9yIErDoW5vcw==?=)
Date: Sat, 14 May 2016 08:49:27 +0200
Subject: [ANNOUNCE] GHC 8.0.1 source tarball available
In-Reply-To: <CAHnG2CyCA13Yvxc9ce2OgogEcP04MUy7_4YiyKcbAFRmBEaSSA@mail.gmail.com>
References: <877ffpu3ax.fsf@smart-cactus.org> <8737po6240.fsf@smart-cactus.org>
 <87y47f3652.fsf@smart-cactus.org>
 <CAHnG2CyGG8du==yXO1Wy_Jz43wsTnhbAcVNaFoHHrJa3=vDYRQ@mail.gmail.com>
 <CAHnG2CyCA13Yvxc9ce2OgogEcP04MUy7_4YiyKcbAFRmBEaSSA@mail.gmail.com>
Message-ID: <CAHnG2CzK=c7+s+iVvmKW+WovO184B7UJmSKXN8okxUzCeL-Uxw@mail.gmail.com>

2016-05-13 7:58 GMT+02:00 P?li G?bor J?nos <pali.gabor at gmail.com>:
> 2016-05-13 7:55 GMT+02:00 P?li G?bor J?nos <pali.gabor at gmail.com>:
>> That is probably because FreeBSD has GNU make(1) as `gmake`, it should
>> be invoked with that name.  I suspect that, for some reason (which is
>> unknown to me), the value of the $(MAKE) variable is not respected at
>> the recursive invocation of make(1).
[..]
> Ohh, I was quick to surrender: all you have to do is to
> s/make/$(MAKE)/ in line 22 at utils/haddock/doc/ghc.mk.

All right, everything is now filed as #12058.

From ben at well-typed.com  Sat May 14 09:28:51 2016
From: ben at well-typed.com (Ben Gamari)
Date: Sat, 14 May 2016 11:28:51 +0200
Subject: [ANNOUNCE] GHC 8.0.1 source tarball available
In-Reply-To: <CAHnG2CzK=c7+s+iVvmKW+WovO184B7UJmSKXN8okxUzCeL-Uxw@mail.gmail.com>
References: <877ffpu3ax.fsf@smart-cactus.org>
 <8737po6240.fsf@smart-cactus.org> <87y47f3652.fsf@smart-cactus.org>
 <CAHnG2CyGG8du==yXO1Wy_Jz43wsTnhbAcVNaFoHHrJa3=vDYRQ@mail.gmail.com>
 <CAHnG2CyCA13Yvxc9ce2OgogEcP04MUy7_4YiyKcbAFRmBEaSSA@mail.gmail.com>
 <CAHnG2CzK=c7+s+iVvmKW+WovO184B7UJmSKXN8okxUzCeL-Uxw@mail.gmail.com>
Message-ID: <874ma12dkc.fsf@smart-cactus.org>

P?li G?bor J?nos <pali.gabor at gmail.com> writes:

> 2016-05-13 7:58 GMT+02:00 P?li G?bor J?nos <pali.gabor at gmail.com>:
>> 2016-05-13 7:55 GMT+02:00 P?li G?bor J?nos <pali.gabor at gmail.com>:
>>> That is probably because FreeBSD has GNU make(1) as `gmake`, it should
>>> be invoked with that name.  I suspect that, for some reason (which is
>>> unknown to me), the value of the $(MAKE) variable is not respected at
>>> the recursive invocation of make(1).
> [..]
>> Ohh, I was quick to surrender: all you have to do is to
>> s/make/$(MAKE)/ in line 22 at utils/haddock/doc/ghc.mk.
>
> All right, everything is now filed as #12058.

Thanks P?li! This should now be fixed on the ghc-8.0 branch. The
question how is what should be done about for the 8.0.1 release. It
seems that there are two decisions to be made here,

 1. Do we cut a new source tarball and bump the tag?
 2. If so, do we throw out the existing binary distributions?

The pragmatist in me wants to answer 1) yes, 2) no, although I do
dislike the idea of distributing binaries that weren't derived from the
associated source tarball.

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/20160514/3a88d328/attachment.sig>

From jan.stolarek at p.lodz.pl  Sat May 14 09:43:59 2016
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Sat, 14 May 2016 11:43:59 +0200
Subject: [ANNOUNCE] GHC 8.0.1 source tarball available
In-Reply-To: <8737po6240.fsf@smart-cactus.org>
References: <877ffpu3ax.fsf@smart-cactus.org> <8737po6240.fsf@smart-cactus.org>
Message-ID: <201605141143.59133.jan.stolarek@p.lodz.pl>

I am getting a build error under openSUSE 11.4:

make -C utils/haddock/doc html SPHINX_BUILD=/usr/bin/sphinx-build
/usr/bin/sphinx-build -b html . .build-html
Running Sphinx v1.2.3
loading translations [en]... done
loading pickled environment... not yet created

Theme error:
no theme named 'alabaster' found (missing theme.conf?)
make[2]: *** [html] Error 1
make[1]: *** [html_utils/haddock/doc] Error 2
make: *** [all] Error 2

Any suggestions how to fix it?

Janek


Dnia ?roda, 11 maja 2016, Ben Gamari napisa?:
> > [ Unknown signature status ]
>
> tl;dr: If you would like to produce a binary distribution for GHC
>        8.0.1 then let us know, grab the source distribution and start
>        building. The binary distributions will be all released one week
>        from today.
>
>
> Hello GHC packagers,
>
> I am happy to at long last announce the release of the 8.0.1 source
> distribution to binary packagers. You will find the usual artifacts at
>
>     http://downloads.haskell.org/~ghc/8.0.1/
>
> These tarballs are derived from GHC commit
>
>     e99c1e2516aeb283172c7e6898508238e33cf065.
>
> For this release we are again following our new release policy [1],
> with a one-week delay between the release of the source and binary
> distributions. The goal of this policy is to give all platforms the
> opportunity for support from the first day of a release.
>
> If all of the expected binary releases are submitted before the
> week-long delay has elapsed, we will move forward with the release of
> the binaries on an accelerated schedule. It would be appreciated if you
> could reply to this message confirming that you intend to offer a binary
> distribution for this release.
>
> Otherwise, let either Austin or I know if you have any trouble building
> your distribution. As usual I'll hold off on pushing the release git tag
> until we have a few binaries built in case we encounter unexpected
> issues.
>
> Good luck and thanks for all of your work!
>
> Cheers,
>
> - Ben
>
>
> [1] https://mail.haskell.org/pipermail/ghc-devs/2016-March/011546.html

 

--- 
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 ben at smart-cactus.org  Sat May 14 10:05:11 2016
From: ben at smart-cactus.org (Ben Gamari)
Date: Sat, 14 May 2016 12:05:11 +0200
Subject: [ANNOUNCE] GHC 8.0.1 source tarball available
In-Reply-To: <201605141143.59133.jan.stolarek@p.lodz.pl>
References: <877ffpu3ax.fsf@smart-cactus.org>
 <8737po6240.fsf@smart-cactus.org> <201605141143.59133.jan.stolarek@p.lodz.pl>
Message-ID: <871t552bvs.fsf@smart-cactus.org>

Jan Stolarek <jan.stolarek at p.lodz.pl> writes:

> I am getting a build error under openSUSE 11.4:
>
> make -C utils/haddock/doc html SPHINX_BUILD=/usr/bin/sphinx-build
> /usr/bin/sphinx-build -b html . .build-html
> Running Sphinx v1.2.3
> loading translations [en]... done
> loading pickled environment... not yet created
>
> Theme error:
> no theme named 'alabaster' found (missing theme.conf?)
> make[2]: *** [html] Error 1
> make[1]: *** [html_utils/haddock/doc] Error 2
> make: *** [all] Error 2
>
> Any suggestions how to fix it?
>
Yes, it seems that the theme that haddock requests was first introduced
to Sphinx in version 1.3. I have encountered this issue myself as well
and yesterday pushed a patch vendorizing the alabaster repository to
ensure that we can build with earlier Sphinx versions. Without this
patch the workaround is to `pip install alabaster` or disable building
of Sphinx documentation.

So, be we yet again have the question of how to deal with this change. I really don't
know what I want to let Haddock's documentation hold up the GHC release
any more than it already has. As I indicated earlier, the prospect of
releasing binaries which weren't derived from the official source
release isn't terribly attractive but may be the best we can do here.
The alternative would be do release 8.0.1 as-is with some notes in the
release notes and immediately start preparing an 8.0.2 after its is
released.

Thoughts?

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/20160514/6bb602a9/attachment.sig>

From karel.gardas at centrum.cz  Sat May 14 11:06:15 2016
From: karel.gardas at centrum.cz (Karel Gardas)
Date: Sat, 14 May 2016 13:06:15 +0200
Subject: [ANNOUNCE] GHC 8.0.1 source tarball available
In-Reply-To: <874ma12dkc.fsf@smart-cactus.org>
References: <877ffpu3ax.fsf@smart-cactus.org>
 <8737po6240.fsf@smart-cactus.org> <87y47f3652.fsf@smart-cactus.org>
 <CAHnG2CyGG8du==yXO1Wy_Jz43wsTnhbAcVNaFoHHrJa3=vDYRQ@mail.gmail.com>
 <CAHnG2CyCA13Yvxc9ce2OgogEcP04MUy7_4YiyKcbAFRmBEaSSA@mail.gmail.com>
 <CAHnG2CzK=c7+s+iVvmKW+WovO184B7UJmSKXN8okxUzCeL-Uxw@mail.gmail.com>
 <874ma12dkc.fsf@smart-cactus.org>
Message-ID: <573706A7.9030408@centrum.cz>

On 05/14/16 11:28 AM, Ben Gamari wrote:
> P?li G?bor J?nos <pali.gabor at gmail.com> writes:
>
>> 2016-05-13 7:58 GMT+02:00 P?li G?bor J?nos <pali.gabor at gmail.com>:
>>> 2016-05-13 7:55 GMT+02:00 P?li G?bor J?nos <pali.gabor at gmail.com>:
>>>> That is probably because FreeBSD has GNU make(1) as `gmake`, it should
>>>> be invoked with that name.  I suspect that, for some reason (which is
>>>> unknown to me), the value of the $(MAKE) variable is not respected at
>>>> the recursive invocation of make(1).
>> [..]
>>> Ohh, I was quick to surrender: all you have to do is to
>>> s/make/$(MAKE)/ in line 22 at utils/haddock/doc/ghc.mk.
>>
>> All right, everything is now filed as #12058.
>
> Thanks P?li! This should now be fixed on the ghc-8.0 branch. The
> question how is what should be done about for the 8.0.1 release. It
> seems that there are two decisions to be made here,
>
>   1. Do we cut a new source tarball and bump the tag?
>   2. If so, do we throw out the existing binary distributions?
>
> The pragmatist in me wants to answer 1) yes, 2) no, although I do
> dislike the idea of distributing binaries that weren't derived from the
> associated source tarball.

This is interesting since I build dists for solaris and openbsd and none 
of those were affected by the bug. I guess all other Linuxes naturally 
use gnu make as `make' and Windows in msys too so only non-GNU/non-Linux 
systems should be affected and from those only FreeBSD has caught this. 
If this is true, then I would recommend "no" to both points and leave 
the fix in 8.0 branch for 8.0.2...

or! you can create 8.0.1b sources and rebuild on FreeBSD to have 8.0.1b 
binary dist for this platform. Anyway I think nobody will shoot anyone 
if Gabor just fix it in his own tree and rebuild silently fixed 8.0.1.

Cheers,
Karel


From harendra.kumar at gmail.com  Sat May 14 11:40:15 2016
From: harendra.kumar at gmail.com (Harendra Kumar)
Date: Sat, 14 May 2016 17:10:15 +0530
Subject: suboptimal ghc code generation in IO vs equivalent pure code case
In-Reply-To: <CAHEA9tP_YT=u+DukGtU3VRM4HxsLQdh_DCk0CzaDp7h7dd-JOQ@mail.gmail.com>
References: <CAPW+kkbszGf8_UfVc6sE7b3A6UHMfB04N03DBj_UZ9W02ofS=Q@mail.gmail.com>
 <CAHEA9tObezBkM7MZtczO+r6cUK=r2eYruNFmw1CbejZfQzYyDA@mail.gmail.com>
 <CAPW+kkaUwUcDK-CROAYLTqjh42WehPEiU1iygCMWYWLgYAz7TQ@mail.gmail.com>
 <CAHEA9tP_YT=u+DukGtU3VRM4HxsLQdh_DCk0CzaDp7h7dd-JOQ@mail.gmail.com>
Message-ID: <CAPW+kkbAo7w0TiVEuphJ3FcCqp-z3tG2nWB7iyu0RpAi4dox_A@mail.gmail.com>

You are right about the way IO code is generated because of the ordering
semantics. The IO version builds the list entirely in a recursive fashion
before returning it while the pure code builds it lazily. I wrote very
simple versions to keep things simpler:

Pure version:

f [] = []
f (x : xs) = x : f xs


time                11.08 ms   (10.86 ms .. 11.34 ms)
Measured for a million elements in the list

     104,041,264 bytes allocated in the heap
          16,728 bytes copied during GC
          35,992 bytes maximum residency (1 sample(s))
          21,352 bytes maximum slop
               1 MB total memory in use (0 MB lost due to fragmentation)


IO version:
f [] = return []
f (x : xs) = do
    rest <- f xs
    return $ x : rest

time                 79.66 ms   (75.49 ms .. 82.55 ms)

     208,654,560 bytes allocated in the heap
     121,045,336 bytes copied during GC
      27,679,344 bytes maximum residency (8 sample(s))
         383,376 bytes maximum slop
              66 MB total memory in use (0 MB lost due to fragmentation)

Even though this is a small program not doing much and therefore enhancing
even small differences to a great degree, I am not sure if I can completely
explain the difference in slowness of the order of 7.5x by just the
recursive vs lazy building of the list. I am wondering if there is anything
that is worth further investigating and improving here.

-harendra

On 12 May 2016 at 05:41, Dan Doel <dan.doel at gmail.com> wrote:
>
> On Tue, May 10, 2016 at 4:45 AM, Harendra Kumar
> <harendra.kumar at gmail.com> wrote:
> > Thanks Dan, that helped. I did notice and suspect the update frame and
the
> > unboxed tuple but given my limited knowledge about ghc/core/stg/cmm I
was
> > not sure what is going on. In fact I thought that the intermediate tuple
> > should get optimized out since it is required only because of the
realworld
> > token which is not real. But it might be difficult to see that at this
> > level?
>
> The token exists as far as the STG level is concerned, I think,
> because that is the only thing ensuring that things happen in the
> right order. And the closure must be built to have properly formed
> STG. So optimizing away the closure building would have to happen at a
> level lower than STG, and I guess there is no such optimization. I'm
> not sure how easy it would be to do.
>
> > What you are saying may be true for the current implementation but in
theory
> > can we eliminate the intermediate closure?
>
> I don't know. I'm a bit skeptical that building this one closure is
> the only thing causing your code to be a factor of 5 slower. For
> instance, another difference in the core is that the recursive call
> corresponding to the result s2 happens before allocating the
> additional closure. That is the case statement that unpacks the
> unboxed tuple. And the whole loop happens this way, so it is actually
> building a structure corresponding to the entire output list in memory
> rather eagerly.
>
> By contrast, your pure function is able to act in a streaming fashion,
> if consumed properly, where only enough of the result is built to keep
> driving the rest of the program. It probably runs in constant space,
> while your IO-based loop has a footprint linear in the size of the
> input list (in addition to having slightly more overhead per character
> because of the one extra thunk), because it is a more eager program.
>
> And having an asymptotically larger memory footprint is more likely to
> explain a 5x slowdown than allocating one extra thunk for each list
> concatenation, I think. (Of course, it could also be some other
> factor, as well.)
>
> You should probably run with +RTS -s (compiling with -rtsopts), and
> see if the IO version has a much larger maximum residency.
>
> Anyhow, this is fundamental to writing the algorithm using IO. It's an
> algorithm that's a sequence of steps that happen in order, the number
> of steps is proportional to the input list, and part of those steps is
> putting stuff in memory for the results.
>
> > So why is that? Why can't we generate (++) inline similar to (:)? How
do we
> > make this decision? Is there a theoretical reason for this or this is
just
> > an implementation artifact?
>
> The difference between these two is that (++) is a function call, and
> (:) is a constructor. Constructors are a special case, and don't need
> to have all the provisions that functions in general do. The best way
> to learn what the differences are is probably to read the paper about
> the STG machine.
>
> Hope this is a more fruitful lead, but it may be that there's not a
> lot that can be done, without doing some baroque things to your
> algorithm, because of the necessity of its using IO.
>
> -- Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160514/bb266c93/attachment-0001.html>

From harendra.kumar at gmail.com  Sat May 14 18:31:02 2016
From: harendra.kumar at gmail.com (Harendra Kumar)
Date: Sun, 15 May 2016 00:01:02 +0530
Subject: suboptimal ghc code generation in IO vs equivalent pure code case
In-Reply-To: <CAPW+kkbAo7w0TiVEuphJ3FcCqp-z3tG2nWB7iyu0RpAi4dox_A@mail.gmail.com>
References: <CAPW+kkbszGf8_UfVc6sE7b3A6UHMfB04N03DBj_UZ9W02ofS=Q@mail.gmail.com>
 <CAHEA9tObezBkM7MZtczO+r6cUK=r2eYruNFmw1CbejZfQzYyDA@mail.gmail.com>
 <CAPW+kkaUwUcDK-CROAYLTqjh42WehPEiU1iygCMWYWLgYAz7TQ@mail.gmail.com>
 <CAHEA9tP_YT=u+DukGtU3VRM4HxsLQdh_DCk0CzaDp7h7dd-JOQ@mail.gmail.com>
 <CAPW+kkbAo7w0TiVEuphJ3FcCqp-z3tG2nWB7iyu0RpAi4dox_A@mail.gmail.com>
Message-ID: <CAPW+kkbfKu1KuhS=-EipnHOjwrY7_WKncN+4+7=Xmv_zaSg6ZA@mail.gmail.com>

The difference seems to be entirely due to memory pressure. At list size
1000 both pure version and IO version perform equally. But as the size of
the list increases the pure version scales linearly while the IO version
degrades exponentially. Here are the execution times per list element in ns
as the list size increases:

Size of list  Pure       IO
1000           8.7          8.3
10000         8.7          18
100000       8.8          63
1000000     9.3          786

This seems to be due to increased GC activity in the IO case. The GC stats
for list size 1 million are:

IO case:       %GC     time      66.1%  (61.1% elapsed)
Pure case:   %GC     time       2.6%  (3.3% elapsed)

Not sure if there is a way to write this code in IO monad which can reduce
this overhead.

-harendra


On 14 May 2016 at 17:10, Harendra Kumar <harendra.kumar at gmail.com> wrote:
>
> You are right about the way IO code is generated because of the ordering
semantics. The IO version builds the list entirely in a recursive fashion
before returning it while the pure code builds it lazily. I wrote very
simple versions to keep things simpler:
>
> Pure version:
>
> f [] = []
> f (x : xs) = x : f xs
>
>
> time                11.08 ms   (10.86 ms .. 11.34 ms)
> Measured for a million elements in the list
>
>      104,041,264 bytes allocated in the heap
>           16,728 bytes copied during GC
>           35,992 bytes maximum residency (1 sample(s))
>           21,352 bytes maximum slop
>                1 MB total memory in use (0 MB lost due to fragmentation)
>
>
> IO version:
> f [] = return []
> f (x : xs) = do
>     rest <- f xs
>     return $ x : rest
>
> time                 79.66 ms   (75.49 ms .. 82.55 ms)
>
>      208,654,560 bytes allocated in the heap
>      121,045,336 bytes copied during GC
>       27,679,344 bytes maximum residency (8 sample(s))
>          383,376 bytes maximum slop
>               66 MB total memory in use (0 MB lost due to fragmentation)
>
> Even though this is a small program not doing much and therefore
enhancing even small differences to a great degree, I am not sure if I can
completely explain the difference in slowness of the order of 7.5x by just
the recursive vs lazy building of the list. I am wondering if there is
anything that is worth further investigating and improving here.
>
> -harendra
>
> On 12 May 2016 at 05:41, Dan Doel <dan.doel at gmail.com> wrote:
> >
> > On Tue, May 10, 2016 at 4:45 AM, Harendra Kumar
> > <harendra.kumar at gmail.com> wrote:
> > > Thanks Dan, that helped. I did notice and suspect the update frame
and the
> > > unboxed tuple but given my limited knowledge about ghc/core/stg/cmm I
was
> > > not sure what is going on. In fact I thought that the intermediate
tuple
> > > should get optimized out since it is required only because of the
realworld
> > > token which is not real. But it might be difficult to see that at this
> > > level?
> >
> > The token exists as far as the STG level is concerned, I think,
> > because that is the only thing ensuring that things happen in the
> > right order. And the closure must be built to have properly formed
> > STG. So optimizing away the closure building would have to happen at a
> > level lower than STG, and I guess there is no such optimization. I'm
> > not sure how easy it would be to do.
> >
> > > What you are saying may be true for the current implementation but in
theory
> > > can we eliminate the intermediate closure?
> >
> > I don't know. I'm a bit skeptical that building this one closure is
> > the only thing causing your code to be a factor of 5 slower. For
> > instance, another difference in the core is that the recursive call
> > corresponding to the result s2 happens before allocating the
> > additional closure. That is the case statement that unpacks the
> > unboxed tuple. And the whole loop happens this way, so it is actually
> > building a structure corresponding to the entire output list in memory
> > rather eagerly.
> >
> > By contrast, your pure function is able to act in a streaming fashion,
> > if consumed properly, where only enough of the result is built to keep
> > driving the rest of the program. It probably runs in constant space,
> > while your IO-based loop has a footprint linear in the size of the
> > input list (in addition to having slightly more overhead per character
> > because of the one extra thunk), because it is a more eager program.
> >
> > And having an asymptotically larger memory footprint is more likely to
> > explain a 5x slowdown than allocating one extra thunk for each list
> > concatenation, I think. (Of course, it could also be some other
> > factor, as well.)
> >
> > You should probably run with +RTS -s (compiling with -rtsopts), and
> > see if the IO version has a much larger maximum residency.
> >
> > Anyhow, this is fundamental to writing the algorithm using IO. It's an
> > algorithm that's a sequence of steps that happen in order, the number
> > of steps is proportional to the input list, and part of those steps is
> > putting stuff in memory for the results.
> >
> > > So why is that? Why can't we generate (++) inline similar to (:)? How
do we
> > > make this decision? Is there a theoretical reason for this or this is
just
> > > an implementation artifact?
> >
> > The difference between these two is that (++) is a function call, and
> > (:) is a constructor. Constructors are a special case, and don't need
> > to have all the provisions that functions in general do. The best way
> > to learn what the differences are is probably to read the paper about
> > the STG machine.
> >
> > Hope this is a more fruitful lead, but it may be that there's not a
> > lot that can be done, without doing some baroque things to your
> > algorithm, because of the necessity of its using IO.
> >
> > -- Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160515/64f3cf73/attachment.html>

From jan.stolarek at p.lodz.pl  Sat May 14 18:55:57 2016
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Sat, 14 May 2016 20:55:57 +0200
Subject: [ANNOUNCE] GHC 8.0.1 source tarball available
In-Reply-To: <871t552bvs.fsf@smart-cactus.org>
References: <877ffpu3ax.fsf@smart-cactus.org>
 <201605141143.59133.jan.stolarek@p.lodz.pl> <871t552bvs.fsf@smart-cactus.org>
Message-ID: <201605142055.57650.jan.stolarek@p.lodz.pl>

I did `pip install alabaster` but keep getting the same error. Unless I need to rebuild everything 
from scratch (in which case I'll probably disable the docs).

Janek

Dnia sobota, 14 maja 2016, Ben Gamari napisa?:
> Jan Stolarek <jan.stolarek at p.lodz.pl> writes:
> > I am getting a build error under openSUSE 11.4:
> >
> > make -C utils/haddock/doc html SPHINX_BUILD=/usr/bin/sphinx-build
> > /usr/bin/sphinx-build -b html . .build-html
> > Running Sphinx v1.2.3
> > loading translations [en]... done
> > loading pickled environment... not yet created
> >
> > Theme error:
> > no theme named 'alabaster' found (missing theme.conf?)
> > make[2]: *** [html] Error 1
> > make[1]: *** [html_utils/haddock/doc] Error 2
> > make: *** [all] Error 2
> >
> > Any suggestions how to fix it?
>
> Yes, it seems that the theme that haddock requests was first introduced
> to Sphinx in version 1.3. I have encountered this issue myself as well
> and yesterday pushed a patch vendorizing the alabaster repository to
> ensure that we can build with earlier Sphinx versions. Without this
> patch the workaround is to `pip install alabaster` or disable building
> of Sphinx documentation.
>
> So, be we yet again have the question of how to deal with this change. I
> really don't know what I want to let Haddock's documentation hold up the
> GHC release any more than it already has. As I indicated earlier, the
> prospect of releasing binaries which weren't derived from the official
> source
> release isn't terribly attractive but may be the best we can do here.
> The alternative would be do release 8.0.1 as-is with some notes in the
> release notes and immediately start preparing an 8.0.2 after its is
> released.
>
> Thoughts?
>
> Cheers,
>
> - Ben

 

--- 
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 david.feuer at gmail.com  Sat May 14 20:05:29 2016
From: david.feuer at gmail.com (David Feuer)
Date: Sat, 14 May 2016 16:05:29 -0400
Subject: suboptimal ghc code generation in IO vs equivalent pure code case
In-Reply-To: <CAPW+kkbfKu1KuhS=-EipnHOjwrY7_WKncN+4+7=Xmv_zaSg6ZA@mail.gmail.com>
References: <CAPW+kkbszGf8_UfVc6sE7b3A6UHMfB04N03DBj_UZ9W02ofS=Q@mail.gmail.com>
 <CAHEA9tObezBkM7MZtczO+r6cUK=r2eYruNFmw1CbejZfQzYyDA@mail.gmail.com>
 <CAPW+kkaUwUcDK-CROAYLTqjh42WehPEiU1iygCMWYWLgYAz7TQ@mail.gmail.com>
 <CAHEA9tP_YT=u+DukGtU3VRM4HxsLQdh_DCk0CzaDp7h7dd-JOQ@mail.gmail.com>
 <CAPW+kkbAo7w0TiVEuphJ3FcCqp-z3tG2nWB7iyu0RpAi4dox_A@mail.gmail.com>
 <CAPW+kkbfKu1KuhS=-EipnHOjwrY7_WKncN+4+7=Xmv_zaSg6ZA@mail.gmail.com>
Message-ID: <CAMgWh9soCLaRWAPsHpmeWg26v+wi+i=ZiUndZLowJ0zr077oSg@mail.gmail.com>

Well, a few weeks ago Bertram Felgenhauer came up with a version of IO that
acts more like lazy ST. That could be just the thing. He placed it in the
public domain/CC0 and told me I could put it up on Hackage if I want. I'll
try to do that this week, but no promises. I could forward his email if you
just want to try it out.
On May 14, 2016 2:31 PM, "Harendra Kumar" <harendra.kumar at gmail.com> wrote:

> The difference seems to be entirely due to memory pressure. At list size
> 1000 both pure version and IO version perform equally. But as the size of
> the list increases the pure version scales linearly while the IO version
> degrades exponentially. Here are the execution times per list element in ns
> as the list size increases:
>
> Size of list  Pure       IO
> 1000           8.7          8.3
> 10000         8.7          18
> 100000       8.8          63
> 1000000     9.3          786
>
> This seems to be due to increased GC activity in the IO case. The GC stats
> for list size 1 million are:
>
> IO case:       %GC     time      66.1%  (61.1% elapsed)
> Pure case:   %GC     time       2.6%  (3.3% elapsed)
>
> Not sure if there is a way to write this code in IO monad which can reduce
> this overhead.
>
> -harendra
>
>
> On 14 May 2016 at 17:10, Harendra Kumar <harendra.kumar at gmail.com> wrote:
> >
> > You are right about the way IO code is generated because of the ordering
> semantics. The IO version builds the list entirely in a recursive fashion
> before returning it while the pure code builds it lazily. I wrote very
> simple versions to keep things simpler:
> >
> > Pure version:
> >
> > f [] = []
> > f (x : xs) = x : f xs
> >
> >
> > time                11.08 ms   (10.86 ms .. 11.34 ms)
> > Measured for a million elements in the list
> >
> >      104,041,264 bytes allocated in the heap
> >           16,728 bytes copied during GC
> >           35,992 bytes maximum residency (1 sample(s))
> >           21,352 bytes maximum slop
> >                1 MB total memory in use (0 MB lost due to fragmentation)
> >
> >
> > IO version:
> > f [] = return []
> > f (x : xs) = do
> >     rest <- f xs
> >     return $ x : rest
> >
> > time                 79.66 ms   (75.49 ms .. 82.55 ms)
> >
> >      208,654,560 bytes allocated in the heap
> >      121,045,336 bytes copied during GC
> >       27,679,344 bytes maximum residency (8 sample(s))
> >          383,376 bytes maximum slop
> >               66 MB total memory in use (0 MB lost due to fragmentation)
> >
> > Even though this is a small program not doing much and therefore
> enhancing even small differences to a great degree, I am not sure if I can
> completely explain the difference in slowness of the order of 7.5x by just
> the recursive vs lazy building of the list. I am wondering if there is
> anything that is worth further investigating and improving here.
> >
> > -harendra
> >
> > On 12 May 2016 at 05:41, Dan Doel <dan.doel at gmail.com> wrote:
> > >
> > > On Tue, May 10, 2016 at 4:45 AM, Harendra Kumar
> > > <harendra.kumar at gmail.com> wrote:
> > > > Thanks Dan, that helped. I did notice and suspect the update frame
> and the
> > > > unboxed tuple but given my limited knowledge about ghc/core/stg/cmm
> I was
> > > > not sure what is going on. In fact I thought that the intermediate
> tuple
> > > > should get optimized out since it is required only because of the
> realworld
> > > > token which is not real. But it might be difficult to see that at
> this
> > > > level?
> > >
> > > The token exists as far as the STG level is concerned, I think,
> > > because that is the only thing ensuring that things happen in the
> > > right order. And the closure must be built to have properly formed
> > > STG. So optimizing away the closure building would have to happen at a
> > > level lower than STG, and I guess there is no such optimization. I'm
> > > not sure how easy it would be to do.
> > >
> > > > What you are saying may be true for the current implementation but
> in theory
> > > > can we eliminate the intermediate closure?
> > >
> > > I don't know. I'm a bit skeptical that building this one closure is
> > > the only thing causing your code to be a factor of 5 slower. For
> > > instance, another difference in the core is that the recursive call
> > > corresponding to the result s2 happens before allocating the
> > > additional closure. That is the case statement that unpacks the
> > > unboxed tuple. And the whole loop happens this way, so it is actually
> > > building a structure corresponding to the entire output list in memory
> > > rather eagerly.
> > >
> > > By contrast, your pure function is able to act in a streaming fashion,
> > > if consumed properly, where only enough of the result is built to keep
> > > driving the rest of the program. It probably runs in constant space,
> > > while your IO-based loop has a footprint linear in the size of the
> > > input list (in addition to having slightly more overhead per character
> > > because of the one extra thunk), because it is a more eager program.
> > >
> > > And having an asymptotically larger memory footprint is more likely to
> > > explain a 5x slowdown than allocating one extra thunk for each list
> > > concatenation, I think. (Of course, it could also be some other
> > > factor, as well.)
> > >
> > > You should probably run with +RTS -s (compiling with -rtsopts), and
> > > see if the IO version has a much larger maximum residency.
> > >
> > > Anyhow, this is fundamental to writing the algorithm using IO. It's an
> > > algorithm that's a sequence of steps that happen in order, the number
> > > of steps is proportional to the input list, and part of those steps is
> > > putting stuff in memory for the results.
> > >
> > > > So why is that? Why can't we generate (++) inline similar to (:)?
> How do we
> > > > make this decision? Is there a theoretical reason for this or this
> is just
> > > > an implementation artifact?
> > >
> > > The difference between these two is that (++) is a function call, and
> > > (:) is a constructor. Constructors are a special case, and don't need
> > > to have all the provisions that functions in general do. The best way
> > > to learn what the differences are is probably to read the paper about
> > > the STG machine.
> > >
> > > Hope this is a more fruitful lead, but it may be that there's not a
> > > lot that can be done, without doing some baroque things to your
> > > algorithm, because of the necessity of its using IO.
> > >
> > > -- Dan
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160514/f9cd3814/attachment-0001.html>

From harendra.kumar at gmail.com  Sat May 14 20:15:27 2016
From: harendra.kumar at gmail.com (Harendra Kumar)
Date: Sun, 15 May 2016 01:45:27 +0530
Subject: suboptimal ghc code generation in IO vs equivalent pure code case
In-Reply-To: <CAMgWh9soCLaRWAPsHpmeWg26v+wi+i=ZiUndZLowJ0zr077oSg@mail.gmail.com>
References: <CAPW+kkbszGf8_UfVc6sE7b3A6UHMfB04N03DBj_UZ9W02ofS=Q@mail.gmail.com>
 <CAHEA9tObezBkM7MZtczO+r6cUK=r2eYruNFmw1CbejZfQzYyDA@mail.gmail.com>
 <CAPW+kkaUwUcDK-CROAYLTqjh42WehPEiU1iygCMWYWLgYAz7TQ@mail.gmail.com>
 <CAHEA9tP_YT=u+DukGtU3VRM4HxsLQdh_DCk0CzaDp7h7dd-JOQ@mail.gmail.com>
 <CAPW+kkbAo7w0TiVEuphJ3FcCqp-z3tG2nWB7iyu0RpAi4dox_A@mail.gmail.com>
 <CAPW+kkbfKu1KuhS=-EipnHOjwrY7_WKncN+4+7=Xmv_zaSg6ZA@mail.gmail.com>
 <CAMgWh9soCLaRWAPsHpmeWg26v+wi+i=ZiUndZLowJ0zr077oSg@mail.gmail.com>
Message-ID: <CAPW+kkZ6NYOPv+_DzbPvKet0bdaeaCnK41O=EHdFSk+M0anVmw@mail.gmail.com>

On 15 May 2016 at 01:35, David Feuer <david.feuer at gmail.com> wrote:

> Well, a few weeks ago Bertram Felgenhauer came up with a version of IO
> that acts more like lazy ST. That could be just the thing. He placed it in
> the public domain/CC0 and told me I could put it up on Hackage if I want.
> I'll try to do that this week, but no promises. I could forward his email
> if you just want to try it out.
>
That's exactly what I was thinking about. Can you please forward it to me,
I will try it out.

Thanks,
Harendra


> On May 14, 2016 2:31 PM, "Harendra Kumar" <harendra.kumar at gmail.com>
> wrote:
>
>> The difference seems to be entirely due to memory pressure. At list size
>> 1000 both pure version and IO version perform equally. But as the size of
>> the list increases the pure version scales linearly while the IO version
>> degrades exponentially. Here are the execution times per list element in ns
>> as the list size increases:
>>
>> Size of list  Pure       IO
>> 1000           8.7          8.3
>> 10000         8.7          18
>> 100000       8.8          63
>> 1000000     9.3          786
>>
>> This seems to be due to increased GC activity in the IO case. The GC
>> stats for list size 1 million are:
>>
>> IO case:       %GC     time      66.1%  (61.1% elapsed)
>> Pure case:   %GC     time       2.6%  (3.3% elapsed)
>>
>> Not sure if there is a way to write this code in IO monad which can
>> reduce this overhead.
>>
>> -harendra
>>
>>
>> On 14 May 2016 at 17:10, Harendra Kumar <harendra.kumar at gmail.com> wrote:
>> >
>> > You are right about the way IO code is generated because of the
>> ordering semantics. The IO version builds the list entirely in a recursive
>> fashion before returning it while the pure code builds it lazily. I wrote
>> very simple versions to keep things simpler:
>> >
>> > Pure version:
>> >
>> > f [] = []
>> > f (x : xs) = x : f xs
>> >
>> >
>> > time                11.08 ms   (10.86 ms .. 11.34 ms)
>> > Measured for a million elements in the list
>> >
>> >      104,041,264 bytes allocated in the heap
>> >           16,728 bytes copied during GC
>> >           35,992 bytes maximum residency (1 sample(s))
>> >           21,352 bytes maximum slop
>> >                1 MB total memory in use (0 MB lost due to fragmentation)
>> >
>> >
>> > IO version:
>> > f [] = return []
>> > f (x : xs) = do
>> >     rest <- f xs
>> >     return $ x : rest
>> >
>> > time                 79.66 ms   (75.49 ms .. 82.55 ms)
>> >
>> >      208,654,560 bytes allocated in the heap
>> >      121,045,336 bytes copied during GC
>> >       27,679,344 bytes maximum residency (8 sample(s))
>> >          383,376 bytes maximum slop
>> >               66 MB total memory in use (0 MB lost due to fragmentation)
>> >
>> > Even though this is a small program not doing much and therefore
>> enhancing even small differences to a great degree, I am not sure if I can
>> completely explain the difference in slowness of the order of 7.5x by just
>> the recursive vs lazy building of the list. I am wondering if there is
>> anything that is worth further investigating and improving here.
>> >
>> > -harendra
>> >
>> > On 12 May 2016 at 05:41, Dan Doel <dan.doel at gmail.com> wrote:
>> > >
>> > > On Tue, May 10, 2016 at 4:45 AM, Harendra Kumar
>> > > <harendra.kumar at gmail.com> wrote:
>> > > > Thanks Dan, that helped. I did notice and suspect the update frame
>> and the
>> > > > unboxed tuple but given my limited knowledge about ghc/core/stg/cmm
>> I was
>> > > > not sure what is going on. In fact I thought that the intermediate
>> tuple
>> > > > should get optimized out since it is required only because of the
>> realworld
>> > > > token which is not real. But it might be difficult to see that at
>> this
>> > > > level?
>> > >
>> > > The token exists as far as the STG level is concerned, I think,
>> > > because that is the only thing ensuring that things happen in the
>> > > right order. And the closure must be built to have properly formed
>> > > STG. So optimizing away the closure building would have to happen at a
>> > > level lower than STG, and I guess there is no such optimization. I'm
>> > > not sure how easy it would be to do.
>> > >
>> > > > What you are saying may be true for the current implementation but
>> in theory
>> > > > can we eliminate the intermediate closure?
>> > >
>> > > I don't know. I'm a bit skeptical that building this one closure is
>> > > the only thing causing your code to be a factor of 5 slower. For
>> > > instance, another difference in the core is that the recursive call
>> > > corresponding to the result s2 happens before allocating the
>> > > additional closure. That is the case statement that unpacks the
>> > > unboxed tuple. And the whole loop happens this way, so it is actually
>> > > building a structure corresponding to the entire output list in memory
>> > > rather eagerly.
>> > >
>> > > By contrast, your pure function is able to act in a streaming fashion,
>> > > if consumed properly, where only enough of the result is built to keep
>> > > driving the rest of the program. It probably runs in constant space,
>> > > while your IO-based loop has a footprint linear in the size of the
>> > > input list (in addition to having slightly more overhead per character
>> > > because of the one extra thunk), because it is a more eager program.
>> > >
>> > > And having an asymptotically larger memory footprint is more likely to
>> > > explain a 5x slowdown than allocating one extra thunk for each list
>> > > concatenation, I think. (Of course, it could also be some other
>> > > factor, as well.)
>> > >
>> > > You should probably run with +RTS -s (compiling with -rtsopts), and
>> > > see if the IO version has a much larger maximum residency.
>> > >
>> > > Anyhow, this is fundamental to writing the algorithm using IO. It's an
>> > > algorithm that's a sequence of steps that happen in order, the number
>> > > of steps is proportional to the input list, and part of those steps is
>> > > putting stuff in memory for the results.
>> > >
>> > > > So why is that? Why can't we generate (++) inline similar to (:)?
>> How do we
>> > > > make this decision? Is there a theoretical reason for this or this
>> is just
>> > > > an implementation artifact?
>> > >
>> > > The difference between these two is that (++) is a function call, and
>> > > (:) is a constructor. Constructors are a special case, and don't need
>> > > to have all the provisions that functions in general do. The best way
>> > > to learn what the differences are is probably to read the paper about
>> > > the STG machine.
>> > >
>> > > Hope this is a more fruitful lead, but it may be that there's not a
>> > > lot that can be done, without doing some baroque things to your
>> > > algorithm, because of the necessity of its using IO.
>> > >
>> > > -- Dan
>>
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160515/4a34d80e/attachment.html>

From pali.gabor at gmail.com  Sat May 14 20:18:26 2016
From: pali.gabor at gmail.com (=?UTF-8?B?UMOhbGkgR8OhYm9yIErDoW5vcw==?=)
Date: Sat, 14 May 2016 22:18:26 +0200
Subject: [ANNOUNCE] GHC 8.0.1 source tarball available
In-Reply-To: <573706A7.9030408@centrum.cz>
References: <877ffpu3ax.fsf@smart-cactus.org> <8737po6240.fsf@smart-cactus.org>
 <87y47f3652.fsf@smart-cactus.org>
 <CAHnG2CyGG8du==yXO1Wy_Jz43wsTnhbAcVNaFoHHrJa3=vDYRQ@mail.gmail.com>
 <CAHnG2CyCA13Yvxc9ce2OgogEcP04MUy7_4YiyKcbAFRmBEaSSA@mail.gmail.com>
 <CAHnG2CzK=c7+s+iVvmKW+WovO184B7UJmSKXN8okxUzCeL-Uxw@mail.gmail.com>
 <874ma12dkc.fsf@smart-cactus.org> <573706A7.9030408@centrum.cz>
Message-ID: <CAHnG2CzKUrZZSvY0CBPpwJv+JQcwn2rWyazw_0JB+Wt58zKu9w@mail.gmail.com>

2016-05-14 13:06 GMT+02:00 Karel Gardas <karel.gardas at centrum.cz>:
> On 05/14/16 11:28 AM, Ben Gamari wrote:
>> The pragmatist in me wants to answer 1) yes, 2) no, although I do
>> dislike the idea of distributing binaries that weren't derived from the
>> associated source tarball.
>
> I guess all other Linuxes naturally use gnu
> make as `make' and Windows in msys too so only non-GNU/non-Linux
> systems should be affected and from those only FreeBSD has caught this.

Yes, that is possible.  I do not know either Solaris or OpenBSD well
enough, but I suspect they might have GNU make(1) installed in their
paths as `make` or their default make(1) can understand GNU-style
Makefiles.  FreeBSD has BSD make(1), which is the default, and this
cannot comprehend the GNU-style files at all.

Anyhow, in my humble opinion, it is a bad practice the hardwire the
name of the make tool in the sources.

> If this is
> true, then I would recommend "no" to both points and leave the fix in 8.0
> branch for 8.0.2...

Well, in theory, FreeBSD is still a Tier-1 platform, so every release
should just build fine without any further efforts.  I am also aware
of the fact I am considered a minority here, and that this is just a
minor technical problem that could wait for some undetermined time.
However, personally, I would be quite disappointed if this promise was
broken.

I am sorry and apologize that I found this bug after the release was
tagged, but I did not have the chance to test it before it was
considered a final release.  I tracked the 8.0.1 Release Candidates
and provided binary tarballs for them, they all went fine, but
apparently that was not enough.

From karel.gardas at centrum.cz  Sat May 14 20:33:08 2016
From: karel.gardas at centrum.cz (Karel Gardas)
Date: Sat, 14 May 2016 22:33:08 +0200
Subject: [ANNOUNCE] GHC 8.0.1 source tarball available
In-Reply-To: <CAHnG2CzKUrZZSvY0CBPpwJv+JQcwn2rWyazw_0JB+Wt58zKu9w@mail.gmail.com>
References: <877ffpu3ax.fsf@smart-cactus.org>
 <8737po6240.fsf@smart-cactus.org> <87y47f3652.fsf@smart-cactus.org>
 <CAHnG2CyGG8du==yXO1Wy_Jz43wsTnhbAcVNaFoHHrJa3=vDYRQ@mail.gmail.com>
 <CAHnG2CyCA13Yvxc9ce2OgogEcP04MUy7_4YiyKcbAFRmBEaSSA@mail.gmail.com>
 <CAHnG2CzK=c7+s+iVvmKW+WovO184B7UJmSKXN8okxUzCeL-Uxw@mail.gmail.com>
 <874ma12dkc.fsf@smart-cactus.org> <573706A7.9030408@centrum.cz>
 <CAHnG2CzKUrZZSvY0CBPpwJv+JQcwn2rWyazw_0JB+Wt58zKu9w@mail.gmail.com>
Message-ID: <57378B84.8030601@centrum.cz>

On 05/14/16 10:18 PM, P?li G?bor J?nos wrote:
> 2016-05-14 13:06 GMT+02:00 Karel Gardas <karel.gardas at centrum.cz>:
>> On 05/14/16 11:28 AM, Ben Gamari wrote:
>>> The pragmatist in me wants to answer 1) yes, 2) no, although I do
>>> dislike the idea of distributing binaries that weren't derived from the
>>> associated source tarball.
>>
>> I guess all other Linuxes naturally use gnu
>> make as `make' and Windows in msys too so only non-GNU/non-Linux
>> systems should be affected and from those only FreeBSD has caught this.
>
> Yes, that is possible.  I do not know either Solaris or OpenBSD well
> enough, but I suspect they might have GNU make(1) installed in their
> paths as `make` or their default make(1) can understand GNU-style

No, on Solaris `make` is some Sun/Oracle make:

$ make --version
make: Warning: Ignoring DistributedMake -v option
make: Warning: Ignoring DistributedMake -o option
make: Fatal error: No dmake output dir argument after -o flag

and GNU make is correctly installed as `gmake`:

$ gmake --version
GNU Make 3.82
Built for i386-pc-solaris2.11
Copyright (C) 2010  Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.


and on OpenBSD this is the same, except that `make` is BSD make:

$ make --version
make: unknown option -- -
usage: make [-BeiknpqrSst] [-C directory] [-D variable] [-d flags] [-f mk]
             [-I directory] [-j max_processes] [-m directory] [-V variable]
             [NAME=value] [target ...]


$ gmake --version
GNU Make 4.1
Built for x86_64-unknown-openbsd5.9
Copyright (C) 1988-2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.


> Anyhow, in my humble opinion, it is a bad practice the hardwire the
> name of the make tool in the sources.

Completely agree with you on this.

>> If this is
>> true, then I would recommend "no" to both points and leave the fix in 8.0
>> branch for 8.0.2...
>
> Well, in theory, FreeBSD is still a Tier-1 platform, so every release
> should just build fine without any further efforts.  I am also aware
> of the fact I am considered a minority here, and that this is just a
> minor technical problem that could wait for some undetermined time.
> However, personally, I would be quite disappointed if this promise was
> broken.

Hmm, indeed, FreeBSD is tier-1. I'm sorry, but I completely forgotten this.

> I am sorry and apologize that I found this bug after the release was
> tagged, but I did not have the chance to test it before it was
> considered a final release.  I tracked the 8.0.1 Release Candidates
> and provided binary tarballs for them, they all went fine, but
> apparently that was not enough.

Apparently this slipped from HEAD to 8.0 branch and it should not, 
especially considering this was already on RC4. But well such mistakes 
happen. OK! I've thought to save the energy on building another set of 
dists, but you have my word on this, to have FBSD folks happy I'm ready 
to rebuild again if Ben submits `c' version of 8.0.1 release source 
code. :-)

Cheers,
Karel



From ben at smart-cactus.org  Sun May 15 19:14:09 2016
From: ben at smart-cactus.org (Ben Gamari)
Date: Sun, 15 May 2016 21:14:09 +0200
Subject: [ANNOUNCE] GHC 8.0.1 source tarball available
In-Reply-To: <201605142055.57650.jan.stolarek@p.lodz.pl>
References: <877ffpu3ax.fsf@smart-cactus.org>
 <201605141143.59133.jan.stolarek@p.lodz.pl> <871t552bvs.fsf@smart-cactus.org>
 <201605142055.57650.jan.stolarek@p.lodz.pl>
Message-ID: <87r3d316da.fsf@smart-cactus.org>

Jan Stolarek <jan.stolarek at p.lodz.pl> writes:

> I did `pip install alabaster` but keep getting the same error. Unless I need to rebuild everything 
> from scratch (in which case I'll probably disable the docs).
>
Hmm, interesting. Indeed I suspect it is best to just disable the docs
in this case. Given the various issues that have been encountered with
this release I suspect we'll be doing a 8.0.2 quite shortly.

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/20160515/ee77280d/attachment.sig>

From ben at well-typed.com  Mon May 16 10:27:57 2016
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 16 May 2016 12:27:57 +0200
Subject: [ANNOUNCE] GHC 8.0.1 source tarball available
In-Reply-To: <CAHnG2CzKUrZZSvY0CBPpwJv+JQcwn2rWyazw_0JB+Wt58zKu9w@mail.gmail.com>
References: <877ffpu3ax.fsf@smart-cactus.org>
 <8737po6240.fsf@smart-cactus.org> <87y47f3652.fsf@smart-cactus.org>
 <CAHnG2CyGG8du==yXO1Wy_Jz43wsTnhbAcVNaFoHHrJa3=vDYRQ@mail.gmail.com>
 <CAHnG2CyCA13Yvxc9ce2OgogEcP04MUy7_4YiyKcbAFRmBEaSSA@mail.gmail.com>
 <CAHnG2CzK=c7+s+iVvmKW+WovO184B7UJmSKXN8okxUzCeL-Uxw@mail.gmail.com>
 <874ma12dkc.fsf@smart-cactus.org> <573706A7.9030408@centrum.cz>
 <CAHnG2CzKUrZZSvY0CBPpwJv+JQcwn2rWyazw_0JB+Wt58zKu9w@mail.gmail.com>
Message-ID: <87oa861emq.fsf@smart-cactus.org>

P?li G?bor J?nos <pali.gabor at gmail.com> writes:

> 2016-05-14 13:06 GMT+02:00 Karel Gardas <karel.gardas at centrum.cz>:
>> On 05/14/16 11:28 AM, Ben Gamari wrote:
>>> The pragmatist in me wants to answer 1) yes, 2) no, although I do
>>> dislike the idea of distributing binaries that weren't derived from the
>>> associated source tarball.
>>
>> I guess all other Linuxes naturally use gnu
>> make as `make' and Windows in msys too so only non-GNU/non-Linux
>> systems should be affected and from those only FreeBSD has caught this.
>
> Yes, that is possible.  I do not know either Solaris or OpenBSD well
> enough, but I suspect they might have GNU make(1) installed in their
> paths as `make` or their default make(1) can understand GNU-style
> Makefiles.  FreeBSD has BSD make(1), which is the default, and this
> cannot comprehend the GNU-style files at all.
>
> Anyhow, in my humble opinion, it is a bad practice the hardwire the
> name of the make tool in the sources.
>
Indeed, this was my mistake. I'll try to be more careful of this in the
future.

>> If this is
>> true, then I would recommend "no" to both points and leave the fix in 8.0
>> branch for 8.0.2...
>
> Well, in theory, FreeBSD is still a Tier-1 platform, so every release
> should just build fine without any further efforts.  I am also aware
> of the fact I am considered a minority here, and that this is just a
> minor technical problem that could wait for some undetermined time.
> However, personally, I would be quite disappointed if this promise was
> broken.
>
Yes, you are right. FreeBSD is tier-1 and we have committed to ensure
these work out-of-the-box. I had neglected to consider this in my
previous assessment of the situation.

In light of this I think we have little choice but to throw out these
binaries and re-spin. Thankfully I have held off on pushing the tag until
the last possible moment.

I think at the moment we should include the following in the new release,

 * the haddock $(MAKE) fix
 * the patch vendorising the alabaster theme for haddock's documentation
 * the patch fixing the clean rule for haddock's documentation
 * the patch ensuring haddock documentation is built for ghc's `all`
   target
 * D2224, which splits ghc-boot to avoid unnecessary transitive
   dependencies in template-haskell (which otherwise would have
   necessitated a prompt 8.0.2 release)
 * A small fix for PPC which fixes crashes in threaded programs

In the interest of risk minimization I think that is all we should merge.

> I am sorry and apologize that I found this bug after the release was
> tagged, but I did not have the chance to test it before it was
> considered a final release.

No need to apologize; I'm glad you brought up the issue. The release
will go out when it's ready.

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/20160516/6bad4066/attachment.sig>

From juhpetersen at gmail.com  Mon May 16 10:49:16 2016
From: juhpetersen at gmail.com (Jens Petersen)
Date: Mon, 16 May 2016 19:49:16 +0900
Subject: [ANNOUNCE] GHC 8.0.1 source tarball available
In-Reply-To: <87oa861emq.fsf@smart-cactus.org>
References: <877ffpu3ax.fsf@smart-cactus.org> <8737po6240.fsf@smart-cactus.org>
 <87y47f3652.fsf@smart-cactus.org>
 <CAHnG2CyGG8du==yXO1Wy_Jz43wsTnhbAcVNaFoHHrJa3=vDYRQ@mail.gmail.com>
 <CAHnG2CyCA13Yvxc9ce2OgogEcP04MUy7_4YiyKcbAFRmBEaSSA@mail.gmail.com>
 <CAHnG2CzK=c7+s+iVvmKW+WovO184B7UJmSKXN8okxUzCeL-Uxw@mail.gmail.com>
 <874ma12dkc.fsf@smart-cactus.org> <573706A7.9030408@centrum.cz>
 <CAHnG2CzKUrZZSvY0CBPpwJv+JQcwn2rWyazw_0JB+Wt58zKu9w@mail.gmail.com>
 <87oa861emq.fsf@smart-cactus.org>
Message-ID: <CAEDGBq+HJtbpGvf0swdMLqFMZ4Was3VX0TVMr2WyYzsapk9Bcg@mail.gmail.com>

On 16 May 2016 at 19:27, Ben Gamari <ben at well-typed.com> wrote:
:
>  * the patch vendorising the alabaster theme for haddock's documentation

Thanks this also affects the build for RHEL7, so it will help me.

Jens

From trp at bluewin.ch  Mon May 16 11:38:17 2016
From: trp at bluewin.ch (Peter Trommler)
Date: Mon, 16 May 2016 13:38:17 +0200
Subject: [ANNOUNCE] GHC 8.0.1 source tarball available
In-Reply-To: <87oa861emq.fsf@smart-cactus.org>
References: <877ffpu3ax.fsf@smart-cactus.org>
 <8737po6240.fsf@smart-cactus.org> <87y47f3652.fsf@smart-cactus.org>
 <CAHnG2CyGG8du==yXO1Wy_Jz43wsTnhbAcVNaFoHHrJa3=vDYRQ@mail.gmail.com>
 <CAHnG2CyCA13Yvxc9ce2OgogEcP04MUy7_4YiyKcbAFRmBEaSSA@mail.gmail.com>
 <CAHnG2CzK=c7+s+iVvmKW+WovO184B7UJmSKXN8okxUzCeL-Uxw@mail.gmail.com>
 <874ma12dkc.fsf@smart-cactus.org> <573706A7.9030408@centrum.cz>
 <CAHnG2CzKUrZZSvY0CBPpwJv+JQcwn2rWyazw_0JB+Wt58zKu9w@mail.gmail.com>
 <87oa861emq.fsf@smart-cactus.org>
Message-ID: <8F900412-9B66-4457-9AC9-131E361D1CFF@bluewin.ch>


> On 16.05.2016, at 12:27, Ben Gamari <ben at well-typed.com> wrote:
> [...]
> I think at the moment we should include the following in the new release,
> 
> * A small fix for PPC which fixes crashes in threaded programs
Is this #12070?

I just uploaded D2225 to Phab.

> 
> In the interest of risk minimization I think that is all we should merge.
> 
D2225 changes all architectures to use compiler built-ins for
the SMP primitives. To minimize risk I could prepare the patch so it only
applies to PowerPC and we do the rest for 8.0.2. Please let me know if you would
like me to prepare the less risky patch.

Cheers, Peter

From ben at well-typed.com  Mon May 16 16:09:42 2016
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 16 May 2016 18:09:42 +0200
Subject: Added submodule to haddock
Message-ID: <87k2iugf21.fsf@smart-cactus.org>

Hello everyone,

Note that a submodule has been added to Haddock in a recent merge. You
may need to check it out with (in the root of the GHC source tree),

    git submodule update --init --recursive

to ensure it's available.

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/20160516/0229c9f6/attachment.sig>

From ezyang at mit.edu  Tue May 17 00:02:15 2016
From: ezyang at mit.edu (Edward Z. Yang)
Date: Mon, 16 May 2016 17:02:15 -0700
Subject: Phabricator not sending emails
Message-ID: <1463443285-sup-1591@sabre>

As far as I can tell, Phabricator is not sending emails.
I noticed when some of my diffs updated but I didn't get
any emails, and doublechecked by asking for a password
reset email.

Edward

From mle+hs at mega-nerd.com  Tue May 17 01:42:29 2016
From: mle+hs at mega-nerd.com (Erik de Castro Lopo)
Date: Tue, 17 May 2016 11:42:29 +1000
Subject: Phabricator not sending emails
In-Reply-To: <1463443285-sup-1591@sabre>
References: <1463443285-sup-1591@sabre>
Message-ID: <20160517114229.96c326bf52d8084c37f19346@mega-nerd.com>

Edward Z. Yang wrote:

> As far as I can tell, Phabricator is not sending emails.
> I noticed when some of my diffs updated but I didn't get
> any emails, and doublechecked by asking for a password
> reset email.

I'm getting Phab emails for my reviews.

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

From ezyang at mit.edu  Tue May 17 06:56:15 2016
From: ezyang at mit.edu (Edward Z. Yang)
Date: Mon, 16 May 2016 23:56:15 -0700
Subject: New wiki page about tying the knot in GHC
Message-ID: <1463468144-sup-1722@sabre>

Hello all,

I've written a new wiki page about how knot tying works in
GHC:

    https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/TyingTheKnot

Please let me know if anything is unclear and I'll try to
revise it for more clarity.

Edward

From ben at smart-cactus.org  Tue May 17 07:16:55 2016
From: ben at smart-cactus.org (Ben Gamari)
Date: Tue, 17 May 2016 09:16:55 +0200
Subject: New wiki page about tying the knot in GHC
In-Reply-To: <1463468144-sup-1722@sabre>
References: <1463468144-sup-1722@sabre>
Message-ID: <87h9dx17dk.fsf@smart-cactus.org>

"Edward Z. Yang" <ezyang at mit.edu> writes:

> Hello all,
>
> I've written a new wiki page about how knot tying works in
> GHC:
>
>     https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/TyingTheKnot
>
This is quite useful! Thanks for writing it down. A few points:

It might be nice if it defined HPT and EPS a bit more concretely (at
least expand the acronyms, ideally including a bit of text defining
their roles in the compiler and why there is two of them).

You say "we produce TyCons and another type checking entities for them".
Should this read "other type checking entities for them"?

Otherwise it looks good to me.

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/20160517/cc429f9e/attachment.sig>

From ben at well-typed.com  Tue May 17 12:38:49 2016
From: ben at well-typed.com (Ben Gamari)
Date: Tue, 17 May 2016 14:38:49 +0200
Subject: 8.0.1 source tarballs available (yet again)
Message-ID: <87zirozwo6.fsf@smart-cactus.org>

tl;dr: We are giving this release another attempt. Cross your fingers
       and try building again.

Hello GHC packagers,

Thanks for your help in the last few days working through what were
hopefully the last issues in the release. I've uploaded a new set of
source tarballs at,

    http://downloads.haskell.org/~ghc/8.0.1/

These tarballs are derived from,

    787900138b94790ddd13d76c2853d789d3335a5d

This commit differs from the previous tarball in a number of ways,

 * a variety of packaging issues surrounding haddock's documentation
   have been fixed

 * the ghc-boot library has been split up. It was pointed out quite late
   that the previous structure of ghc-boot greatly increased the
   dependency footprint of the template-haskell package, which would
   have made it nearly impossible to upgrade the bytestring and binary
   packages.

 * a pair of fixes for crashes on PowerPC have been merged

 * a patch addressing a serious performance issue in parallel garbage
   collection has been merged

 * the bytestring module has been bumped to 0.8.10.1, fixing a rather
   serious correctness issue on big-endian systems

We'll have the usual one-week build window for binary distributions.
As always, let either Austin or I know if you have any trouble building
your distribution. I have yet to push the ghc-8.0.1 tag in case we
encounter unexpected issues but all of my builds with this tarball
thusfar have gone quite well (then again, so did those of the previous
tarball).

Good luck and thanks for all of your work!

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/20160517/37ef85c0/attachment.sig>

From asr at eafit.edu.co  Tue May 17 13:02:23 2016
From: asr at eafit.edu.co (=?UTF-8?B?QW5kcsOpcyBTaWNhcmQtUmFtw61yZXo=?=)
Date: Tue, 17 May 2016 08:02:23 -0500
Subject: 8.0.1 source tarballs available (yet again)
In-Reply-To: <87zirozwo6.fsf@smart-cactus.org>
References: <87zirozwo6.fsf@smart-cactus.org>
Message-ID: <CAOUWSGCHbuAYDKBCQ0gKNK0buBr+bUknz8CFhg-qCW39hTKW5Q@mail.gmail.com>

On 17 May 2016 at 07:38, Ben Gamari <ben at well-typed.com> wrote:
> tl;dr: We are giving this release another attempt. Cross your fingers
>        and try building again.
>
> Hello GHC packagers,
>
> Thanks for your help in the last few days working through what were
> hopefully the last issues in the release. I've uploaded a new set of
> source tarballs at,
>
>     http://downloads.haskell.org/~ghc/8.0.1/

I got the following error (on Linux):

$ make
/usr/bin/ld: cannot find -lHSghc-boot-th-8.0.1
collect2: ld returned 1 exit status
make[1]: *** [utils/ghc-pkg/dist/build/tmp/ghc-pkg] Error 1


I had no this problem with the previous source tarballs.

Best,

--
Andr?s

"La informaci?n contenida en este correo electr?nico est? dirigida ?nicamente a su destinatario y puede contener informaci?n confidencial, material privilegiado o informaci?n protegida por derecho de autor. Est? prohibida cualquier copia, utilizaci?n, indebida retenci?n, modificaci?n, difusi?n, distribuci?n o reproducci?n total o parcial. Si usted recibe este mensaje por error, por favor contacte al remitente y elim?nelo. La informaci?n aqu? contenida es responsabilidad exclusiva de su remitente por lo tanto la Universidad EAFIT no se hace responsable de lo que el mensaje contenga."

"The information contained in this email is addressed to its recipient only and may contain confidential information, privileged material or information protected by copyright. Its prohibited any copy, use, improper retention, modification, dissemination, distribution or total or partial reproduction. If you receive this message by error, please contact the sender and delete it. The information contained herein is the sole responsibility of the sender therefore Universidad EAFIT is not responsible for what the message contains."

From karel.gardas at centrum.cz  Tue May 17 13:10:16 2016
From: karel.gardas at centrum.cz (Karel Gardas)
Date: Tue, 17 May 2016 15:10:16 +0200
Subject: 8.0.1 source tarballs available (yet again)
In-Reply-To: <CAOUWSGCHbuAYDKBCQ0gKNK0buBr+bUknz8CFhg-qCW39hTKW5Q@mail.gmail.com>
References: <87zirozwo6.fsf@smart-cactus.org>
 <CAOUWSGCHbuAYDKBCQ0gKNK0buBr+bUknz8CFhg-qCW39hTKW5Q@mail.gmail.com>
Message-ID: <573B1838.204@centrum.cz>

On 05/17/16 03:02 PM, Andr?s Sicard-Ram?rez wrote:
> On 17 May 2016 at 07:38, Ben Gamari <ben at well-typed.com> wrote:
>> tl;dr: We are giving this release another attempt. Cross your fingers
>>         and try building again.
>>
>> Hello GHC packagers,
>>
>> Thanks for your help in the last few days working through what were
>> hopefully the last issues in the release. I've uploaded a new set of
>> source tarballs at,
>>
>>      http://downloads.haskell.org/~ghc/8.0.1/
>
> I got the following error (on Linux):
>
> $ make
> /usr/bin/ld: cannot find -lHSghc-boot-th-8.0.1
> collect2: ld returned 1 exit status
> make[1]: *** [utils/ghc-pkg/dist/build/tmp/ghc-pkg] Error 1

That's exactly the issue which should be fixed in this round. Ben cited 
this as an issue affecting Solaris and FreeBSD and you are lucky to be 
able to duplicate this on Linux.

Anyway, please verify that your -src.tar.xz does have following sha256 sum:

b677e215cdfa22fba534b9bf7b530a056113c1f01002eae5b576e92ced9193ba

I guess you are using older sources from previous round as website is 
notoriously known for excessive caching...

Karel


From ben at well-typed.com  Tue May 17 13:15:48 2016
From: ben at well-typed.com (Ben Gamari)
Date: Tue, 17 May 2016 15:15:48 +0200
Subject: 8.0.1 source tarballs available (yet again)
In-Reply-To: <CAOUWSGCHbuAYDKBCQ0gKNK0buBr+bUknz8CFhg-qCW39hTKW5Q@mail.gmail.com>
References: <87zirozwo6.fsf@smart-cactus.org>
 <CAOUWSGCHbuAYDKBCQ0gKNK0buBr+bUknz8CFhg-qCW39hTKW5Q@mail.gmail.com>
Message-ID: <87wpmszuyj.fsf@smart-cactus.org>

Andr?s Sicard-Ram?rez <asr at eafit.edu.co> writes:

> On 17 May 2016 at 07:38, Ben Gamari <ben at well-typed.com> wrote:
>> tl;dr: We are giving this release another attempt. Cross your fingers
>>        and try building again.
>>
>> Hello GHC packagers,
>>
>> Thanks for your help in the last few days working through what were
>> hopefully the last issues in the release. I've uploaded a new set of
>> source tarballs at,
>>
>>     http://downloads.haskell.org/~ghc/8.0.1/
>
> I got the following error (on Linux):
>
> $ make
> /usr/bin/ld: cannot find -lHSghc-boot-th-8.0.1
> collect2: ld returned 1 exit status
> make[1]: *** [utils/ghc-pkg/dist/build/tmp/ghc-pkg] Error 1
>
Can you confirm that the sha1sum of the tarball you downloaded is,

      $ sha1sum  ghc-8.0.1-src.tar.xz
      a3ff4c7b54c440d5a6e25f534a9b3ea93c1ee029  ghc-8.0.1-src.tar.xz

I've noticed in the past that the invalidation of the CDN can take a
while to propagate.

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/20160517/092da068/attachment.sig>

From asr at eafit.edu.co  Tue May 17 13:18:34 2016
From: asr at eafit.edu.co (=?UTF-8?B?QW5kcsOpcyBTaWNhcmQtUmFtw61yZXo=?=)
Date: Tue, 17 May 2016 08:18:34 -0500
Subject: 8.0.1 source tarballs available (yet again)
In-Reply-To: <87wpmszuyj.fsf@smart-cactus.org>
References: <87zirozwo6.fsf@smart-cactus.org>
 <CAOUWSGCHbuAYDKBCQ0gKNK0buBr+bUknz8CFhg-qCW39hTKW5Q@mail.gmail.com>
 <87wpmszuyj.fsf@smart-cactus.org>
Message-ID: <CAOUWSGBR6mKzstfCdrp4XFNjLa=yNmC6NK-JJu93B6BqvF-5fA@mail.gmail.com>

2016-05-17 8:15 GMT-05:00 Ben Gamari <ben at well-typed.com>:
>> I got the following error (on Linux):
>>
>> $ make
>> /usr/bin/ld: cannot find -lHSghc-boot-th-8.0.1
>> collect2: ld returned 1 exit status
>> make[1]: *** [utils/ghc-pkg/dist/build/tmp/ghc-pkg] Error 1
>>
> Can you confirm that the sha1sum of the tarball you downloaded is,
>
>       $ sha1sum  ghc-8.0.1-src.tar.xz
>       a3ff4c7b54c440d5a6e25f534a9b3ea93c1ee029  ghc-8.0.1-src.tar.xz

Yes, I can confirm it:

  $ sha1sum ghc-8.0.1-src.tar.xz
  a3ff4c7b54c440d5a6e25f534a9b3ea93c1ee029  ghc-8.0.1-src.tar.xz



--
Andr?s

"La informaci?n contenida en este correo electr?nico est? dirigida ?nicamente a su destinatario y puede contener informaci?n confidencial, material privilegiado o informaci?n protegida por derecho de autor. Est? prohibida cualquier copia, utilizaci?n, indebida retenci?n, modificaci?n, difusi?n, distribuci?n o reproducci?n total o parcial. Si usted recibe este mensaje por error, por favor contacte al remitente y elim?nelo. La informaci?n aqu? contenida es responsabilidad exclusiva de su remitente por lo tanto la Universidad EAFIT no se hace responsable de lo que el mensaje contenga."

"The information contained in this email is addressed to its recipient only and may contain confidential information, privileged material or information protected by copyright. Its prohibited any copy, use, improper retention, modification, dissemination, distribution or total or partial reproduction. If you receive this message by error, please contact the sender and delete it. The information contained herein is the sole responsibility of the sender therefore Universidad EAFIT is not responsible for what the message contains."

From ben at well-typed.com  Tue May 17 13:21:05 2016
From: ben at well-typed.com (Ben Gamari)
Date: Tue, 17 May 2016 15:21:05 +0200
Subject: 8.0.1 source tarballs available (yet again)
In-Reply-To: <CAOUWSGCHbuAYDKBCQ0gKNK0buBr+bUknz8CFhg-qCW39hTKW5Q@mail.gmail.com>
References: <87zirozwo6.fsf@smart-cactus.org>
 <CAOUWSGCHbuAYDKBCQ0gKNK0buBr+bUknz8CFhg-qCW39hTKW5Q@mail.gmail.com>
Message-ID: <87shxgzupq.fsf@smart-cactus.org>

Andr?s Sicard-Ram?rez <asr at eafit.edu.co> writes:

> On 17 May 2016 at 07:38, Ben Gamari <ben at well-typed.com> wrote:
>> tl;dr: We are giving this release another attempt. Cross your fingers
>>        and try building again.
>>
>> Hello GHC packagers,
>>
>> Thanks for your help in the last few days working through what were
>> hopefully the last issues in the release. I've uploaded a new set of
>> source tarballs at,
>>
>>     http://downloads.haskell.org/~ghc/8.0.1/
>
> I got the following error (on Linux):
>
> $ make
> /usr/bin/ld: cannot find -lHSghc-boot-th-8.0.1
> collect2: ld returned 1 exit status
> make[1]: *** [utils/ghc-pkg/dist/build/tmp/ghc-pkg] Error 1
>
Very interesting. This must be quite a intermittent issue since I have
not once been able to reproduce it and Karel claimed the patch I merged
fixed it. Yet, Herbert noticed that the patch is actually subtly wrong.

Does the attached patch fix the issue?

Cheers,

- Ben


From e365d1379ffcf81b8b28863db9acc4970d39359b Mon Sep 17 00:00:00 2001
From: Ben Gamari <ben at smart-cactus.org>
Date: Tue, 17 May 2016 15:18:37 +0200
Subject: [PATCH] rules: Fix name of ghc-boot-th library

There was a missing `#`. Hadrian couldn't come soon enough.
---
 rules/foreachLibrary.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rules/foreachLibrary.mk b/rules/foreachLibrary.mk
index d65533e..be79fcc 100644
--- a/rules/foreachLibrary.mk
+++ b/rules/foreachLibrary.mk
@@ -38,7 +38,7 @@
 define foreachLibrary
 # $1 = function to call for each library
 # We will give it the package path and the tag as arguments
-$$(foreach hashline,libraries/ghc-boot-th-#no-remote-repo#no-vcs            \
+$$(foreach hashline,libraries/ghc-boot-th#-#no-remote-repo#no-vcs           \
                     libraries/ghc-boot#-#no-remote-repo#no-vcs              \
                     libraries/ghci#-#no-remote-repo#no-vcs                  \
                     libraries/base#-#no-remote-repo#no-vcs                  \
-- 
2.8.0.rc3

-------------- 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/20160517/4f84be39/attachment.sig>

From asr at eafit.edu.co  Tue May 17 13:50:39 2016
From: asr at eafit.edu.co (=?UTF-8?B?QW5kcsOpcyBTaWNhcmQtUmFtw61yZXo=?=)
Date: Tue, 17 May 2016 08:50:39 -0500
Subject: 8.0.1 source tarballs available (yet again)
In-Reply-To: <87shxgzupq.fsf@smart-cactus.org>
References: <87zirozwo6.fsf@smart-cactus.org>
 <CAOUWSGCHbuAYDKBCQ0gKNK0buBr+bUknz8CFhg-qCW39hTKW5Q@mail.gmail.com>
 <87shxgzupq.fsf@smart-cactus.org>
Message-ID: <CAOUWSGB-Ba11oEEn60oz3RhPNdJGGNEFC3ZHJkXNKCwxqoX7dA@mail.gmail.com>

2016-05-17 8:21 GMT-05:00 Ben Gamari <ben at well-typed.com>:
>> I got the following error (on Linux):
>>
>> $ make
>> /usr/bin/ld: cannot find -lHSghc-boot-th-8.0.1
>> collect2: ld returned 1 exit status
>> make[1]: *** [utils/ghc-pkg/dist/build/tmp/ghc-pkg] Error 1
>>
> Very interesting. This must be quite a intermittent issue since I have
> not once been able to reproduce it and Karel claimed the patch I merged
> fixed it. Yet, Herbert noticed that the patch is actually subtly wrong.
>
> Does the attached patch fix the issue?

No, the patch didn't fix the issue.


--
Andr?s

"La informaci?n contenida en este correo electr?nico est? dirigida ?nicamente a su destinatario y puede contener informaci?n confidencial, material privilegiado o informaci?n protegida por derecho de autor. Est? prohibida cualquier copia, utilizaci?n, indebida retenci?n, modificaci?n, difusi?n, distribuci?n o reproducci?n total o parcial. Si usted recibe este mensaje por error, por favor contacte al remitente y elim?nelo. La informaci?n aqu? contenida es responsabilidad exclusiva de su remitente por lo tanto la Universidad EAFIT no se hace responsable de lo que el mensaje contenga."

"The information contained in this email is addressed to its recipient only and may contain confidential information, privileged material or information protected by copyright. Its prohibited any copy, use, improper retention, modification, dissemination, distribution or total or partial reproduction. If you receive this message by error, please contact the sender and delete it. The information contained herein is the sole responsibility of the sender therefore Universidad EAFIT is not responsible for what the message contains."

From carter.schonwald at gmail.com  Tue May 17 14:27:13 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Tue, 17 May 2016 10:27:13 -0400
Subject: 8.0.1 source tarballs available (yet again)
In-Reply-To: <CAOUWSGB-Ba11oEEn60oz3RhPNdJGGNEFC3ZHJkXNKCwxqoX7dA@mail.gmail.com>
References: <87zirozwo6.fsf@smart-cactus.org>
 <CAOUWSGCHbuAYDKBCQ0gKNK0buBr+bUknz8CFhg-qCW39hTKW5Q@mail.gmail.com>
 <87shxgzupq.fsf@smart-cactus.org>
 <CAOUWSGB-Ba11oEEn60oz3RhPNdJGGNEFC3ZHJkXNKCwxqoX7dA@mail.gmail.com>
Message-ID: <CAHYVw0yLwP8-hBP-Ra8i7B_47X9_Ph=adrsgNFYHzOM8weob7w@mail.gmail.com>

$ shasum -a512 ghc-8.0.1-x86_64-apple-darwin-built-with-gcc5-take3.tar.xz
db20daf51bdd634fcd613738baa47dd01fbeccfe0cc6ffddf35d1a25af5929199d227b8db07c8d5ce1f4b9d843875e38fd2e4c87716cb8d2cb06012f177dc30a
 ghc-8.0.1-x86_64-apple-darwin-built-with-gcc5-take3.tar.xz
~/l/ghc-8.0.1 $


link at

https://wellposed-carter-files.s3.amazonaws.com/opensource/ghc/releasebuild-unofficial/ghc-8.0.1-x86_64-apple-darwin-built-with-gcc5-take3.tar.xz


On Tue, May 17, 2016 at 9:50 AM, Andr?s Sicard-Ram?rez <asr at eafit.edu.co>
wrote:

> 2016-05-17 8:21 GMT-05:00 Ben Gamari <ben at well-typed.com>:
> >> I got the following error (on Linux):
> >>
> >> $ make
> >> /usr/bin/ld: cannot find -lHSghc-boot-th-8.0.1
> >> collect2: ld returned 1 exit status
> >> make[1]: *** [utils/ghc-pkg/dist/build/tmp/ghc-pkg] Error 1
> >>
> > Very interesting. This must be quite a intermittent issue since I have
> > not once been able to reproduce it and Karel claimed the patch I merged
> > fixed it. Yet, Herbert noticed that the patch is actually subtly wrong.
> >
> > Does the attached patch fix the issue?
>
> No, the patch didn't fix the issue.
>
>
> --
> Andr?s
>
> "La informaci?n contenida en este correo electr?nico est? dirigida
> ?nicamente a su destinatario y puede contener informaci?n confidencial,
> material privilegiado o informaci?n protegida por derecho de autor. Est?
> prohibida cualquier copia, utilizaci?n, indebida retenci?n, modificaci?n,
> difusi?n, distribuci?n o reproducci?n total o parcial. Si usted recibe este
> mensaje por error, por favor contacte al remitente y elim?nelo. La
> informaci?n aqu? contenida es responsabilidad exclusiva de su remitente por
> lo tanto la Universidad EAFIT no se hace responsable de lo que el mensaje
> contenga."
>
> "The information contained in this email is addressed to its recipient
> only and may contain confidential information, privileged material or
> information protected by copyright. Its prohibited any copy, use, improper
> retention, modification, dissemination, distribution or total or partial
> reproduction. If you receive this message by error, please contact the
> sender and delete it. The information contained herein is the sole
> responsibility of the sender therefore Universidad EAFIT is not responsible
> for what the message contains."
> _______________________________________________
> 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/20160517/5ae7aa4f/attachment.html>

From ben at well-typed.com  Tue May 17 14:47:13 2016
From: ben at well-typed.com (Ben Gamari)
Date: Tue, 17 May 2016 16:47:13 +0200
Subject: 8.0.1 source tarballs available (yet again)
In-Reply-To: <CAOUWSGB-Ba11oEEn60oz3RhPNdJGGNEFC3ZHJkXNKCwxqoX7dA@mail.gmail.com>
References: <87zirozwo6.fsf@smart-cactus.org>
 <CAOUWSGCHbuAYDKBCQ0gKNK0buBr+bUknz8CFhg-qCW39hTKW5Q@mail.gmail.com>
 <87shxgzupq.fsf@smart-cactus.org>
 <CAOUWSGB-Ba11oEEn60oz3RhPNdJGGNEFC3ZHJkXNKCwxqoX7dA@mail.gmail.com>
Message-ID: <87k2iszqq6.fsf@smart-cactus.org>

Andr?s Sicard-Ram?rez <asr at eafit.edu.co> writes:

> 2016-05-17 8:21 GMT-05:00 Ben Gamari <ben at well-typed.com>:
>>> I got the following error (on Linux):
>>>
>>> $ make
>>> /usr/bin/ld: cannot find -lHSghc-boot-th-8.0.1
>>> collect2: ld returned 1 exit status
>>> make[1]: *** [utils/ghc-pkg/dist/build/tmp/ghc-pkg] Error 1
>>>
>> Very interesting. This must be quite a intermittent issue since I have
>> not once been able to reproduce it and Karel claimed the patch I merged
>> fixed it. Yet, Herbert noticed that the patch is actually subtly wrong.
>>
>> Does the attached patch fix the issue?
>
> No, the patch didn't fix the issue.
>
Alright, thanks for the update. We're looking into the issue.

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/20160517/6e175924/attachment.sig>

From thomasmiedema at gmail.com  Tue May 17 16:11:53 2016
From: thomasmiedema at gmail.com (Thomas Miedema)
Date: Tue, 17 May 2016 18:11:53 +0200
Subject: HEADS UP: running tests in /tmp and the `extra_files` setup function
Message-ID: <CAD3WKggCFnve_drTFQkO4eiFoqWNqcCXX7Vm9eJLXKMKgbGe4g@mail.gmail.com>

Hello GHC developers,

the testsuite driver now runs each test in a temporary directory in /tmp,
after first linking/copying all files that the test requires to that
directory.

When adding a new test:

** if your test requires source files that don't start with the name of
your test, then you *have to* specify those files using the `extra_files`
setup function. [1]*

* you no longer have to specify files to cleanup (`clean_files` and
`clean_cmd` are deprecated)

* you no longer have to add generated files to `testsuite/.gitignore`

* you no longer have to worry about two tests possibly overwriting each
others intermediate (.o, .hi) files, and you no longer have to
specify `-outputdir` if you want to let multiple tests use the same source
files.

Example:

*BEFORE:*
    test('driver011',
         extra_clean(['A011.hi', 'A011.o']),
         run_command,
         ['$MAKE -s --no-print-directory test011'])

*AFTER:*
    test('driver011',
         extra_files(['A011.hs']),
         run_command,
         ['$MAKE -s --no-print-directory test011'])

See https://ghc.haskell.org/trac/ghc/ticket/11980 and
https://ghc.haskell.org/trac/ghc/wiki/Building/RunningTests/Adding for more
information.

Cheers,
Thomas

[1] Extra files for existing tests are currently listed in
`testsuite/driver/extra_files.py`.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160517/176e43af/attachment-0001.html>

From ben at well-typed.com  Tue May 17 16:54:44 2016
From: ben at well-typed.com (Ben Gamari)
Date: Tue, 17 May 2016 18:54:44 +0200
Subject: 8.0.1 source tarballs available (yet again)
In-Reply-To: <87zirozwo6.fsf@smart-cactus.org>
References: <87zirozwo6.fsf@smart-cactus.org>
Message-ID: <87h9dwzktn.fsf@smart-cactus.org>

tl;dr: We are giving this release yet another attempt. Cross your
       fingers and try building again.

So after many attempts I was able to reproduce the issue seen by 
Andr?s and Karel and believe I have merged a fix. The issue is
documented as Trac #12078. Thanks to everyone who helped pin down
the issue.

I've uploaded a new set of source tarballs to the usual location,

    http://downloads.haskell.org/~ghc/8.0.1/

These tarballs are derived from,

    4986837f8168cacf95c24fecc84d7b36c47f3c11

For reference, the SHA1 sum of the new source tarballs is,

    585a2d34a17ce2452273147f2e3cef1a2efe1aa5  ./ghc-8.0.1-src.tar.xz

Let me know how your builds go. I don't anticipate any further issues,
but one rarely does.

Finally: thank you all so much for your patience while we worked through
these issues. I hope it's a long time until we see such a drawn out and
problematic release.

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/20160517/3b3c2d53/attachment.sig>

From ezyang at mit.edu  Tue May 17 18:25:52 2016
From: ezyang at mit.edu (Edward Z. Yang)
Date: Tue, 17 May 2016 11:25:52 -0700
Subject: New wiki page about tying the knot in GHC
In-Reply-To: <87h9dx17dk.fsf@smart-cactus.org>
References: <1463468144-sup-1722@sabre> <87h9dx17dk.fsf@smart-cactus.org>
Message-ID: <1463509544-sup-1045@sabre>

Yep, updated, thanks.

Edward

Excerpts from Ben Gamari's message of 2016-05-17 00:16:55 -0700:
> "Edward Z. Yang" <ezyang at mit.edu> writes:
> 
> > Hello all,
> >
> > I've written a new wiki page about how knot tying works in
> > GHC:
> >
> >     https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/TyingTheKnot
> >
> This is quite useful! Thanks for writing it down. A few points:
> 
> It might be nice if it defined HPT and EPS a bit more concretely (at
> least expand the acronyms, ideally including a bit of text defining
> their roles in the compiler and why there is two of them).
> 
> You say "we produce TyCons and another type checking entities for them".
> Should this read "other type checking entities for them"?
> 
> Otherwise it looks good to me.
> 
> Cheers,
> 
> - Ben

From ben at smart-cactus.org  Tue May 17 19:02:15 2016
From: ben at smart-cactus.org (Ben Gamari)
Date: Tue, 17 May 2016 21:02:15 +0200
Subject: HEADS UP: running tests in /tmp and the `extra_files` setup
 function
In-Reply-To: <CAD3WKggCFnve_drTFQkO4eiFoqWNqcCXX7Vm9eJLXKMKgbGe4g@mail.gmail.com>
References: <CAD3WKggCFnve_drTFQkO4eiFoqWNqcCXX7Vm9eJLXKMKgbGe4g@mail.gmail.com>
Message-ID: <87bn44zex4.fsf@smart-cactus.org>

Thomas Miedema <thomasmiedema at gmail.com> writes:

> Hello GHC developers,
>
> the testsuite driver now runs each test in a temporary directory in /tmp,
> after first linking/copying all files that the test requires to that
> directory.
>
Hmm, it looks like the new paths rather clutter the testsuite summary
produced at the end of the run,


   /tmp/ghctest/jvZ6KB/1/2/3/./indexed-types/should_fail/T3330a  T3330a [stderr mismatch] (normal)
   /tmp/ghctest/jvZ6KB/1/2/3/./indexed-types/should_fail/T4174   T4174 [stderr mismatch] (normal)
   /tmp/ghctest/jvZ6KB/1/2/3/./indexed-types/should_fail/T4179   T4179 [stderr mismatch] (normal)

Perhaps we should strip off the root path from the test names?

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/20160517/015fe6bc/attachment.sig>

From ezyang at mit.edu  Tue May 17 19:25:12 2016
From: ezyang at mit.edu (Edward Z. Yang)
Date: Tue, 17 May 2016 12:25:12 -0700
Subject: HEADS UP: running tests in /tmp and the `extra_files` setup
 function
In-Reply-To: <CAD3WKggCFnve_drTFQkO4eiFoqWNqcCXX7Vm9eJLXKMKgbGe4g@mail.gmail.com>
References: <CAD3WKggCFnve_drTFQkO4eiFoqWNqcCXX7Vm9eJLXKMKgbGe4g@mail.gmail.com>
Message-ID: <1463513064-sup-7998@sabre>

Hello Thomas,

Is there a way to change where the temporary directory is made?  The
test suite can take a lot of disk space and some of us would prefer
to store the test output on a different partition.

Thanks,
Edward

Excerpts from Thomas Miedema's message of 2016-05-17 09:11:53 -0700:
> Hello GHC developers,
> 
> the testsuite driver now runs each test in a temporary directory in /tmp,
> after first linking/copying all files that the test requires to that
> directory.
> 
> When adding a new test:
> 
> ** if your test requires source files that don't start with the name of
> your test, then you *have to* specify those files using the `extra_files`
> setup function. [1]*
> 
> * you no longer have to specify files to cleanup (`clean_files` and
> `clean_cmd` are deprecated)
> 
> * you no longer have to add generated files to `testsuite/.gitignore`
> 
> * you no longer have to worry about two tests possibly overwriting each
> others intermediate (.o, .hi) files, and you no longer have to
> specify `-outputdir` if you want to let multiple tests use the same source
> files.
> 
> Example:
> 
> *BEFORE:*
>     test('driver011',
>          extra_clean(['A011.hi', 'A011.o']),
>          run_command,
>          ['$MAKE -s --no-print-directory test011'])
> 
> *AFTER:*
>     test('driver011',
>          extra_files(['A011.hs']),
>          run_command,
>          ['$MAKE -s --no-print-directory test011'])
> 
> See https://ghc.haskell.org/trac/ghc/ticket/11980 and
> https://ghc.haskell.org/trac/ghc/wiki/Building/RunningTests/Adding for more
> information.
> 
> Cheers,
> Thomas
> 
> [1] Extra files for existing tests are currently listed in
> `testsuite/driver/extra_files.py`.

From thomasmiedema at gmail.com  Tue May 17 19:35:01 2016
From: thomasmiedema at gmail.com (Thomas Miedema)
Date: Tue, 17 May 2016 21:35:01 +0200
Subject: HEADS UP: running tests in /tmp and the `extra_files` setup
 function
In-Reply-To: <1463513064-sup-7998@sabre>
References: <CAD3WKggCFnve_drTFQkO4eiFoqWNqcCXX7Vm9eJLXKMKgbGe4g@mail.gmail.com>
 <1463513064-sup-7998@sabre>
Message-ID: <CAD3WKgh7W+oUt7C=E+LsZBbTYhhD074rGTuesyT0qA8j54YojA@mail.gmail.com>

Is there a way to change where the temporary directory is made?


There is not.

But it shouldn't be necessary, since during a complete test run, (most)
generated files are deleted after each individual test has finished.

This behavior recently changed (#9758), see my previous email about this:
https://mail.haskell.org/pipermail/ghc-devs/2016-April/011976.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160517/5d94db85/attachment.html>

From pali.gabor at gmail.com  Tue May 17 22:17:26 2016
From: pali.gabor at gmail.com (=?UTF-8?B?UMOhbGkgR8OhYm9yIErDoW5vcw==?=)
Date: Wed, 18 May 2016 00:17:26 +0200
Subject: 8.0.1 source tarballs available (yet again)
In-Reply-To: <87h9dwzktn.fsf@smart-cactus.org>
References: <87zirozwo6.fsf@smart-cactus.org> <87h9dwzktn.fsf@smart-cactus.org>
Message-ID: <CAHnG2CySEdOH+fQF4YDLvZOJpVtpme3xSL4Le8zOeeEJLFgaZQ@mail.gmail.com>

2016-05-17 18:54 GMT+02:00 Ben Gamari <ben at well-typed.com>:
> Let me know how your builds go. I don't anticipate any further issues,
> but one rarely does.

The FreeBSD builds are now done and available here:

http://haskell.inf.elte.hu/ghc/8.0.1/

From carter.schonwald at gmail.com  Wed May 18 00:45:59 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Tue, 17 May 2016 20:45:59 -0400
Subject: 8.0.1 source tarballs available (yet again)
In-Reply-To: <87k2iszqq6.fsf@smart-cactus.org>
References: <87zirozwo6.fsf@smart-cactus.org>
 <CAOUWSGCHbuAYDKBCQ0gKNK0buBr+bUknz8CFhg-qCW39hTKW5Q@mail.gmail.com>
 <87shxgzupq.fsf@smart-cactus.org>
 <CAOUWSGB-Ba11oEEn60oz3RhPNdJGGNEFC3ZHJkXNKCwxqoX7dA@mail.gmail.com>
 <87k2iszqq6.fsf@smart-cactus.org>
Message-ID: <CAHYVw0zgH_3qtHydJU-fYk3X4KD5x7-hiUNuz-+TnFXTRXskpA@mail.gmail.com>

heres the build for $ shasum ghc-8.0.1-src.tar.xz
585a2d34a17ce2452273147f2e3cef1a2efe1aa5  ghc-8.0.1-src.tar.xz
source ball

https://wellposed-carter-files.s3.amazonaws.com/opensource/ghc/releasebuild-unofficial/ghc-8.0.1-x86_64-apple-darwin-built-with-gcc5-take4.tar.xz
which has the following hash
$ shasum -a512 ghc-8.0.1-x86_64-apple-darwin-built-with-gcc5-take4.tar.xz
b38c3c85381758eddc16394c2818319ecd9069e98a5d37cf5af9f56d0ad3a7f03eb93b3abe8238167c73ec07f419de453c5ff3eb93802442da14eb35325c6a91
 ghc-8.0.1-x86_64-apple-darwin-built-with-gcc5-take4.tar.xz



On Tue, May 17, 2016 at 10:47 AM, Ben Gamari <ben at well-typed.com> wrote:

> Andr?s Sicard-Ram?rez <asr at eafit.edu.co> writes:
>
> > 2016-05-17 8:21 GMT-05:00 Ben Gamari <ben at well-typed.com>:
> >>> I got the following error (on Linux):
> >>>
> >>> $ make
> >>> /usr/bin/ld: cannot find -lHSghc-boot-th-8.0.1
> >>> collect2: ld returned 1 exit status
> >>> make[1]: *** [utils/ghc-pkg/dist/build/tmp/ghc-pkg] Error 1
> >>>
> >> Very interesting. This must be quite a intermittent issue since I have
> >> not once been able to reproduce it and Karel claimed the patch I merged
> >> fixed it. Yet, Herbert noticed that the patch is actually subtly wrong.
> >>
> >> Does the attached patch fix the issue?
> >
> > No, the patch didn't fix the issue.
> >
> Alright, thanks for the update. We're looking into the issue.
>
> 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/20160517/cb40dbc6/attachment-0001.html>

From asr at eafit.edu.co  Wed May 18 02:40:34 2016
From: asr at eafit.edu.co (=?UTF-8?B?QW5kcsOpcyBTaWNhcmQtUmFtw61yZXo=?=)
Date: Tue, 17 May 2016 21:40:34 -0500
Subject: 8.0.1 source tarballs available (yet again)
In-Reply-To: <87h9dwzktn.fsf@smart-cactus.org>
References: <87zirozwo6.fsf@smart-cactus.org> <87h9dwzktn.fsf@smart-cactus.org>
Message-ID: <CAOUWSGB=h7Y97gpBmJmU0do-E4cGXD=ZxZRtzxMEHA-C1bB_sA@mail.gmail.com>

On 17 May 2016 at 11:54, Ben Gamari <ben at well-typed.com> wrote:
> So after many attempts I was able to reproduce the issue seen by
> Andr?s and Karel and believe I have merged a fix.
>
> Let me know how your builds go

I couldn't reproduce the issue using the latest source tarballs. Thanks!

--
Andr?s

"La informaci?n contenida en este correo electr?nico est? dirigida ?nicamente a su destinatario y puede contener informaci?n confidencial, material privilegiado o informaci?n protegida por derecho de autor. Est? prohibida cualquier copia, utilizaci?n, indebida retenci?n, modificaci?n, difusi?n, distribuci?n o reproducci?n total o parcial. Si usted recibe este mensaje por error, por favor contacte al remitente y elim?nelo. La informaci?n aqu? contenida es responsabilidad exclusiva de su remitente por lo tanto la Universidad EAFIT no se hace responsable de lo que el mensaje contenga."

"The information contained in this email is addressed to its recipient only and may contain confidential information, privileged material or information protected by copyright. Its prohibited any copy, use, improper retention, modification, dissemination, distribution or total or partial reproduction. If you receive this message by error, please contact the sender and delete it. The information contained herein is the sole responsibility of the sender therefore Universidad EAFIT is not responsible for what the message contains."

From alan.zimm at gmail.com  Wed May 18 11:52:01 2016
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Wed, 18 May 2016 13:52:01 +0200
Subject: [GHC] #11140: add command-line option to GHC to dump raw parse
 trees of Haskell programs
In-Reply-To: <059.7d0d12334312eb0bd19dc2e0404d8e90@haskell.org>
References: <044.9ca7a94e52e643694da7336bc4c35d24@haskell.org>
 <059.7d0d12334312eb0bd19dc2e0404d8e90@haskell.org>
Message-ID: <CANma=H_BgEwpMhVKT6T_b9p20=i25ha3hgm8sPuRnuWRb4Dj1Q@mail.gmail.com>

I'm with mpickering on this one. Each stage has a debug format that makes
sense for the stage.  For parsing it is the exact ast

Alan

On 18 May 2016 12:43 PM, "GHC" <ghc-devs at haskell.org> wrote:

> #11140: add command-line option to GHC to dump raw parse trees of Haskell
> programs
> -------------------------------------+-------------------------------------
>         Reporter:  bollu             |                Owner:
>             Type:  feature request   |               Status:  new
>         Priority:  low               |            Milestone:
>        Component:  Compiler          |              Version:  7.10.2
>       Resolution:                    |             Keywords:
> Operating System:  Unknown/Multiple  |         Architecture:
>                                      |  Unknown/Multiple
>  Type of failure:  None/Unknown      |            Test Case:
>       Blocked By:                    |             Blocking:
>  Related Tickets:                    |  Differential Rev(s):
>        Wiki Page:                    |
> -------------------------------------+-------------------------------------
>
> Comment (by mpickering):
>
>  That is true but by them stages in the compilation pipeline you don't care
>  about what the raw format looks like. When modifying the parser  you need
>  to know the precise structure of the AST rather than some pretty printed
>  version produced by `Outputtable`.
>
> --
> Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11140#comment:6>
> GHC <http://www.haskell.org/ghc/>
> The Glasgow Haskell Compiler
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160518/930b0d8d/attachment.html>

From jan.stolarek at p.lodz.pl  Wed May 18 14:12:28 2016
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Wed, 18 May 2016 16:12:28 +0200
Subject: 8.0.1 source tarballs available (yet again)
In-Reply-To: <87zirozwo6.fsf@smart-cactus.org>
References: <87zirozwo6.fsf@smart-cactus.org>
Message-ID: <201605181612.28388.jan.stolarek@p.lodz.pl>

This time my build went through without problems on openSUSE 11.4.

Janek

Dnia wtorek, 17 maja 2016, Ben Gamari napisa?:
> tl;dr: We are giving this release another attempt. Cross your fingers
>        and try building again.
>
> Hello GHC packagers,
>
> Thanks for your help in the last few days working through what were
> hopefully the last issues in the release. I've uploaded a new set of
> source tarballs at,
>
>     http://downloads.haskell.org/~ghc/8.0.1/
>
> These tarballs are derived from,
>
>     787900138b94790ddd13d76c2853d789d3335a5d
>
> This commit differs from the previous tarball in a number of ways,
>
>  * a variety of packaging issues surrounding haddock's documentation
>    have been fixed
>
>  * the ghc-boot library has been split up. It was pointed out quite late
>    that the previous structure of ghc-boot greatly increased the
>    dependency footprint of the template-haskell package, which would
>    have made it nearly impossible to upgrade the bytestring and binary
>    packages.
>
>  * a pair of fixes for crashes on PowerPC have been merged
>
>  * a patch addressing a serious performance issue in parallel garbage
>    collection has been merged
>
>  * the bytestring module has been bumped to 0.8.10.1, fixing a rather
>    serious correctness issue on big-endian systems
>
> We'll have the usual one-week build window for binary distributions.
> As always, let either Austin or I know if you have any trouble building
> your distribution. I have yet to push the ghc-8.0.1 tag in case we
> encounter unexpected issues but all of my builds with this tarball
> thusfar have gone quite well (then again, so did those of the previous
> tarball).
>
> Good luck and thanks for all of your work!
>
> Cheers,
>
> - Ben

 

--- 
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 simonpj at microsoft.com  Thu May 19 11:20:34 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 19 May 2016 11:20:34 +0000
Subject: HEAD failing
Message-ID: <c60f173f29274d0eb7bb57d0bc0dfcac@DB4PR30MB030.064d.mgd.msft.net>

Devs,
I?m getting this on a clean build of HEAD on Linux

Unexpected failures:

   /tmp/ghctest/0MzM7D/1/2/3/./rts/T11108       T11108 [bad stdout] (normal)

   /tmp/ghctest/0MzM7D/1/2/3/./rts/T8308/T8308  T8308 [bad stdout] (normal)
Two things

?         would it be possible to remove the long /tmp/blah prefix?

?         What?s wrong with these two rts tests?  I see that #11108 already reports the failure, and I?ve re-opened #8308
Simon



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

From ben at well-typed.com  Thu May 19 12:15:44 2016
From: ben at well-typed.com (Ben Gamari)
Date: Thu, 19 May 2016 14:15:44 +0200
Subject: HEAD failing
In-Reply-To: <c60f173f29274d0eb7bb57d0bc0dfcac@DB4PR30MB030.064d.mgd.msft.net>
References: <c60f173f29274d0eb7bb57d0bc0dfcac@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <871t4yz1jj.fsf@smart-cactus.org>

Simon Peyton Jones <simonpj at microsoft.com> writes:

> Devs,
> I?m getting this on a clean build of HEAD on Linux
>
> Unexpected failures:
>
>    /tmp/ghctest/0MzM7D/1/2/3/./rts/T11108       T11108 [bad stdout] (normal)
>
>    /tmp/ghctest/0MzM7D/1/2/3/./rts/T8308/T8308  T8308 [bad stdout] (normal)
> Two things
>
> ?         would it be possible to remove the long /tmp/blah prefix?
>
Thomas argued that it is convenient to be able to cut-and-paste the path
to a failing testcase. That being said, on balance I agree that it is a
bit too noisy to be worth the convenience.

> ?         What?s wrong with these two rts tests?  I see that #11108 already reports the failure, and I?ve re-opened #8308

Oh dear, it looks like I neglected to add the T11108.stdout to the
repository before push. Sorry about that.

T8308 on the other hand I am quite perplexed by. This test passes for
me. Can you provide the output of,

    make test TEST=T8308

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/20160519/4092db55/attachment.sig>

From simonpj at microsoft.com  Thu May 19 12:17:07 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 19 May 2016 12:17:07 +0000
Subject: HEAD failing
In-Reply-To: <871t4yz1jj.fsf@smart-cactus.org>
References: <c60f173f29274d0eb7bb57d0bc0dfcac@DB4PR30MB030.064d.mgd.msft.net>
 <871t4yz1jj.fsf@smart-cactus.org>
Message-ID: <1909900a1340417fb910cde849e61ea4@AM3PR30MB019.064d.mgd.msft.net>

=====> T8308(normal) 1 of 1 [0, 0, 0] 
cd /tmp/ghctest/kZl5Ju/1/2/3/./rts/T8308/T8308 && $MAKE -s --no-print-directory T8308    </dev/null > T8308.run.stdout 2> T8308.run.stderr
Actual stdout output differs from expected:
--- /tmp/ghctest/kZl5Ju/1/2/3/./rts/T8308/T8308/T8308.stdout.normalised	2016-05-19 13:16:54.915694378 +0100
+++ /tmp/ghctest/kZl5Ju/1/2/3/./rts/T8308/T8308/T8308.run.stdout.normalised	2016-05-19 13:16:54.915694378 +0100
@@ -1 +1 @@
-1
+8
*** unexpected failure for T8308(normal)

Unexpected results from:
TEST="T8308"

OVERALL SUMMARY for test run started at Thu May 19 13:16:53 2016 BST
 0:00:02 spent to go through
       1 total tests, which gave rise to
       1 test cases, of which
       0 were skipped

       0 had missing libraries
       0 expected passes
       0 expected failures

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

Unexpected failures:
   /tmp/ghctest/kZl5Ju/1/2/3/./rts/T8308/T8308  T8308 [bad stdout] (normal)

simonpj at cam-05-unx:~/5builds/HEAD-4/testsuite/tests$

|  -----Original Message-----
|  From: Ben Gamari [mailto:ben at well-typed.com]
|  Sent: 19 May 2016 13:16
|  To: Simon Peyton Jones <simonpj at microsoft.com>; ghc-devs <ghc-
|  devs at haskell.org>
|  Subject: Re: HEAD failing
|  
|  Simon Peyton Jones <simonpj at microsoft.com> writes:
|  
|  > Devs,
|  > I?m getting this on a clean build of HEAD on Linux
|  >
|  > Unexpected failures:
|  >
|  >    /tmp/ghctest/0MzM7D/1/2/3/./rts/T11108       T11108 [bad stdout]
|  (normal)
|  >
|  >    /tmp/ghctest/0MzM7D/1/2/3/./rts/T8308/T8308  T8308 [bad stdout]
|  > (normal) Two things
|  >
|  > ?         would it be possible to remove the long /tmp/blah prefix?
|  >
|  Thomas argued that it is convenient to be able to cut-and-paste the
|  path to a failing testcase. That being said, on balance I agree that
|  it is a bit too noisy to be worth the convenience.
|  
|  > ?         What?s wrong with these two rts tests?  I see that #11108
|  already reports the failure, and I?ve re-opened #8308
|  
|  Oh dear, it looks like I neglected to add the T11108.stdout to the
|  repository before push. Sorry about that.
|  
|  T8308 on the other hand I am quite perplexed by. This test passes for
|  me. Can you provide the output of,
|  
|      make test TEST=T8308
|  
|  Cheers,
|  
|  - Ben


From ben at well-typed.com  Thu May 19 12:32:51 2016
From: ben at well-typed.com (Ben Gamari)
Date: Thu, 19 May 2016 14:32:51 +0200
Subject: HEAD failing
In-Reply-To: <1909900a1340417fb910cde849e61ea4@AM3PR30MB019.064d.mgd.msft.net>
References: <c60f173f29274d0eb7bb57d0bc0dfcac@DB4PR30MB030.064d.mgd.msft.net>
 <871t4yz1jj.fsf@smart-cactus.org>
 <1909900a1340417fb910cde849e61ea4@AM3PR30MB019.064d.mgd.msft.net>
Message-ID: <87y476xm6k.fsf@smart-cactus.org>

Simon Peyton Jones <simonpj at microsoft.com> writes:

> =====> T8308(normal) 1 of 1 [0, 0, 0] 
> cd /tmp/ghctest/kZl5Ju/1/2/3/./rts/T8308/T8308 && $MAKE -s --no-print-directory T8308    </dev/null > T8308.run.stdout 2> T8308.run.stderr
> Actual stdout output differs from expected:
> --- /tmp/ghctest/kZl5Ju/1/2/3/./rts/T8308/T8308/T8308.stdout.normalised	2016-05-19 13:16:54.915694378 +0100
> +++ /tmp/ghctest/kZl5Ju/1/2/3/./rts/T8308/T8308/T8308.run.stdout.normalised	2016-05-19 13:16:54.915694378 +0100
> @@ -1 +1 @@
> -1
> +8

I left a comment on the ticket. In short, this is expected behavior
given you have built your libraries with ticky.

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/20160519/1f271fbb/attachment.sig>

From david.feuer at gmail.com  Thu May 19 14:30:54 2016
From: david.feuer at gmail.com (David Feuer)
Date: Thu, 19 May 2016 10:30:54 -0400
Subject: Unpacking single-field,
 single-strict-constructor GADTs and existentials
In-Reply-To: <CAMgWh9tffEs-3PHWzxhQc2UkL+jyv+wp1=dF4mFEEo2m_m2e2w@mail.gmail.com>
References: <CAMgWh9uqPCqEqwzp6TvyprN0NGvSJ74SkreyVJEK4YEy+EpGfA@mail.gmail.com>
 <CAMgWh9u=vpNvkwyYtND7brF94EOEEkctdKva5GYtaCLpLbjEvA@mail.gmail.com>
 <CAMgWh9sMsaPA9g2f-2J9FKFHDf+Juf_HDHQy9oZc34nNF=QCJQ@mail.gmail.com>
 <CAMgWh9vZfdo_fKxWWw_s0PTmnGVKqEMQWfaruGkBJB38Lojbtw@mail.gmail.com>
 <CAMgWh9vutqciKs2-U62JLnQUaT7M0uz23inw0ju_xFi+ew92VA@mail.gmail.com>
 <CAMgWh9tr2wG3HT-SY9xtmauHHovVrsCLTo-pBp2+T-9VrhC-ig@mail.gmail.com>
 <CAMgWh9tLi3Gu=8RGWXH9OQLJ6DB=UdM+1MzOvMB_QTFhnQanYg@mail.gmail.com>
 <CAMgWh9veyXkZKSHVKPh6n4-5hy7mhd7n2v53O7h8XYCa7-Q-dQ@mail.gmail.com>
 <CAMgWh9uFVR9kypsEw0oLYmEaQnC8Y1ory7KT18FMRS-fnmE=oQ@mail.gmail.com>
 <CAMgWh9uneS8k1xEM1dYJCmR8cuf8V5s_Ssci21v=PONVJ_t21A@mail.gmail.com>
 <CAMgWh9vsPZbunmEY37rQgvtLjbbspwsrUzNFQYYxco2eyR2J=Q@mail.gmail.com>
 <CAMgWh9u5Jtz30fOrKdd1vXWvOWVkTCaRSahN2R_mMxuxhhc7yA@mail.gmail.com>
 <CAMgWh9uFmuNpNXAXPcj25gOQz66Fud9StT0m8gYrN-tj3Gy4dw@mail.gmail.com>
 <CAMgWh9uYcrNZ17R1H=J8dR=BdqWH7xekt349wFjcTADim3=RVg@mail.gmail.com>
 <CAMgWh9v7MWQB3H-p=YTg78eOX37OhcBtE=PX-7r0yUAZX6c0GQ@mail.gmail.com>
 <CAMgWh9u2h-r_7VpKrNwhLDVYvR3mO-0yzSED-7rPDuQ5h+1Emw@mail.gmail.com>
 <CAMgWh9tffEs-3PHWzxhQc2UkL+jyv+wp1=dF4mFEEo2m_m2e2w@mail.gmail.com>
Message-ID: <CAMgWh9snErv1oEFyv5UhG_JSUfVT3FO1HHA9N2x9AOU7eSW6tA@mail.gmail.com>

Data.IntMap could be cleaned up some if single-field, single strict
constructor GADTs/existentials could be unpacked even when wrapping a sum
type. We could then have

data Status = E | NE
data IntMap' (s :: Status) a where
  Bin :: ... -> ... -> !(IntMap' NE a) -> !(IntMap' NE a) -> IntMap' NE a
  Tip :: ... -> a -> IntMap' NE a
  Nil :: IntMap' E a
data IntMap a =
  forall s . IM {-# UNPACK #-} !(IntMap' s a)

The representation would be the same as that of a newtype, but the pattern
matching semantics would be strict. In the GADT case, this would
essentially allow any fixed concrete datatype to serve directly as a
witness for an arbitrary set of type equalities demanded on construction.

Is there any hope something like this could happen?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160519/62f90ce7/attachment.html>

From ben at well-typed.com  Sat May 21 15:18:35 2016
From: ben at well-typed.com (Ben Gamari)
Date: Sat, 21 May 2016 17:18:35 +0200
Subject: [ANNOUNCE] GHC 8.0.1 is available!
Message-ID: <8737pbxwvo.fsf@smart-cactus.org>


           ===============================================
            The Glasgow Haskell Compiler -- version 8.0.1
           ===============================================

The GHC developers are very pleased to announce the release of the first
new super-major version of our Haskell compiler in six years, GHC 8.0.1.

This release features dozens of exciting developments including,

 * A more refined interface for implicit call-stacks, allowing libraries to
   provide more helpful runtime error messages to users

 * The introduction of the DuplicateRecordFields language extension, allowing
   multiple record types to declare fields of the same name

 * Significant improvements in error message readability and content, including
   facilities for libraries to provide custom error messages, more aggressive
   warnings for fragile rewrite rules, and more helpful errors for missing
   imports

 * A rewritten and substantially more thorough pattern match checker, providing
   more precise exhaustiveness checking in GADT pattern matches

 * More reliable debugging information including experimental backtrace support,
   allowing better integration with traditional debugging tools

 * Support for desugaring do-notation to use Applicative combinators, allowing
   the intuitive do notation to be used in settings which previously required
   the direct use of Applicative combinators

 * The introduction of Strict and StrictData language extensions, allowing
   modules to be compiled with strict-by-default evaluation of bindings

 * Great improvements in portability, including more reliable linking on
   Windows, a new PPC64 code generator, support for the AIX operating system,
   unregisterised m68k support, and significant stabilization on ARM targets

 * A greatly improved user's guide, with beautiful and modern PDF and HTML
   output

 * Introduction of type application syntax, reducing the need for proxies

 * More complete support for pattern synonyms, including record pattern synonyms
   and the ability to export patterns "bundled" with a type, as you would a data
   constructor

 * Support for injective type families and recursive superclass relationships

 * An improved generics representation leveraging GHC's support for type-level
   literals

 * The TypeInType extension, which unifies types and kinds, allowing GHC to
   reason about kind equality and enabling promotion of more constructs to the
   type level

 * ...and more!

A more thorough list of the changes included in this release can be found in the
release notes,

    https://downloads.haskell.org/~ghc/8.0.1/docs/html/users_guide/8.0.1-notes.html

As always, we have collected various points of interest for users of previous
GHC releases on the GHC 8.0 migration page,

    https://ghc.haskell.org/trac/ghc/wiki/Migration/8.0

Please let us know if you encounter anything missing or unclear on this page.

This release is the culmination of nearly eighteen months of effort by over one
hundred contributors. We'd like to thank everyone who has contributed code, bug
reports, and feedback over the past year. It's only because of their efforts
that GHC continues to evolve.


How to get it
~~~~~~~~~~~~~

Both the source tarball and binary distributions for a wide variety of platforms
are available at,

    http://www.haskell.org/ghc/


Background
~~~~~~~~~~

Haskell is a standardized lazy functional programming language.

The Glasgow Haskell Compiler (GHC) is a state-of-the-art programming suite for
Haskell. Included is an optimising compiler generating efficient code for a
variety of platforms, together with an interactive system for convenient, quick
development. The distribution includes space and time profiling facilities, a
large collection of libraries, and support for various language extensions,
including concurrency, exceptions, and foreign language interfaces. GHC is
distributed under a BSD-style open source license.


Supported Platforms
~~~~~~~~~~~~~~~~~~~

The list of platforms we support, and the people responsible for them, can be
found on the GHC wiki

    http://ghc.haskell.org/trac/ghc/wiki/Platforms

Ports to other platforms are possible with varying degrees of difficulty. The
Building Guide describes how to go about porting to a new platform:

    http://ghc.haskell.org/trac/ghc/wiki/Building


Developers
~~~~~~~~~~

We welcome new contributors. Instructions on getting started with hacking on GHC
are available from GHC's developer site,

    http://ghc.haskell.org/trac/ghc/


Community Resources
~~~~~~~~~~~~~~~~~~~

There are mailing lists for GHC users, develpoers, and monitoring bug tracker
activity; to subscribe, use the web interfaces at

    http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
    http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
    http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets

There are several other Haskell and GHC-related mailing lists on
www.haskell.org; for the full list, see

    https://mail.haskell.org/cgi-bin/mailman/listinfo

Some GHC developers hang out on the #ghc and #haskell of the Freenode IRC
network, too:

    http://www.haskell.org/haskellwiki/IRC_channel

Please report bugs using our bug tracking system. Instructions on reporting bugs
can be found here:

    http://www.haskell.org/ghc/reportabug
-------------- 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/20160521/f3112892/attachment.sig>

From ben at smart-cactus.org  Sat May 21 17:07:53 2016
From: ben at smart-cactus.org (Ben Gamari)
Date: Sat, 21 May 2016 19:07:53 +0200
Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.0.1 is available!
In-Reply-To: <CAMLKXynvkY-2xS_UkFmsHopQweTi4aTzYxseMhEbt456MF0C0Q@mail.gmail.com>
References: <8737pbxwvo.fsf@smart-cactus.org>
 <41BA6C56-793E-4862-A3C0-B2782A22622F@gmail.com>
 <CAMLKXynvkY-2xS_UkFmsHopQweTi4aTzYxseMhEbt456MF0C0Q@mail.gmail.com>
Message-ID: <87vb27wd92.fsf@smart-cactus.org>

KC <kc1956 at gmail.com> writes:

> Hopefully this makes it into the Haskell Platform soon
>
I believe a Haskell Platform release is imminent, not sure about
Stackage.

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/20160521/f0ed46dc/attachment.sig>

From simonpj at microsoft.com  Mon May 23 11:20:02 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 23 May 2016 11:20:02 +0000
Subject: Build fails
Message-ID: <074f317d3b484c7a8ffaf7ae8531a6a6@DB4PR30MB030.064d.mgd.msft.net>

Binary.readBinMem: decompression failed
What?s going on?  This is a clean validate on Linux.  I have done git pull, git submodule update ?recursive ?init
Simon


cd libraries && sh gen_contents_index --intree

grep: ../bin-package-db/bin-package-db.cabal: No such file or directory

grep: ../integer-gmp2/integer-gmp.cabal: No such file or directory

haddock: internal error: Binary.readBinMem: decompression failed

CallStack (from HasCallStack):

  error, called at compiler/utils/Binary.hs:192:16 in ghc:Binary

make[1]: *** [libraries/dist-haddock/index.html] Error 1

make: *** [all] Error 2
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160523/e45a54a3/attachment.html>

From simonpj at microsoft.com  Mon May 23 11:28:56 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 23 May 2016 11:28:56 +0000
Subject: Build fails
In-Reply-To: <074f317d3b484c7a8ffaf7ae8531a6a6@DB4PR30MB030.064d.mgd.msft.net>
References: <074f317d3b484c7a8ffaf7ae8531a6a6@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <afc2ae350c09463c9ce8ebf8ed261cd7@DB4PR30MB030.064d.mgd.msft.net>

Also lots of tests give

ghc-stage2: panic! (the 'impossible' happened)

  (GHC version 8.1.20160523 for x86_64-unknown-linux):

       Binary.readBinMem: decompression failed

CallStack (from HasCallStack):

  error, called at compiler/utils/Binary.hs:192:16 in ghc:Binary

Should I revert some hi-file compression patch?
S

From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Simon Peyton Jones
Sent: 23 May 2016 12:20
To: ghc-devs <ghc-devs at haskell.org>
Subject: Build fails


Binary.readBinMem: decompression failed
What?s going on?  This is a clean validate on Linux.  I have done git pull, git submodule update ?recursive ?init
Simon


cd libraries && sh gen_contents_index --intree

grep: ../bin-package-db/bin-package-db.cabal: No such file or directory

grep: ../integer-gmp2/integer-gmp.cabal: No such file or directory

haddock: internal error: Binary.readBinMem: decompression failed

CallStack (from HasCallStack):

  error, called at compiler/utils/Binary.hs:192:16 in ghc:Binary

make[1]: *** [libraries/dist-haddock/index.html] Error 1

make: *** [all] Error 2
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160523/9903fe31/attachment-0001.html>

From ben at smart-cactus.org  Mon May 23 12:59:06 2016
From: ben at smart-cactus.org (Ben Gamari)
Date: Mon, 23 May 2016 14:59:06 +0200
Subject: Build fails
In-Reply-To: <afc2ae350c09463c9ce8ebf8ed261cd7@DB4PR30MB030.064d.mgd.msft.net>
References: <074f317d3b484c7a8ffaf7ae8531a6a6@DB4PR30MB030.064d.mgd.msft.net>
 <afc2ae350c09463c9ce8ebf8ed261cd7@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <87bn3xvskl.fsf@smart-cactus.org>

Simon Peyton Jones <simonpj at microsoft.com> writes:

> Also lots of tests give
>
> ghc-stage2: panic! (the 'impossible' happened)
>
>   (GHC version 8.1.20160523 for x86_64-unknown-linux):
>
>        Binary.readBinMem: decompression failed
>
> CallStack (from HasCallStack):
>
>   error, called at compiler/utils/Binary.hs:192:16 in ghc:Binary
>
> Should I revert some hi-file compression patch?

I currently have a local build running to confirm the issue. That being
said, Harbormaster doesn't seem to be seeing this particular issue
(although it fails for other reasons).

I wonder if you have some some old interface files hanging around. Does this
help,

    git clean -fxd
    git submodule foreach git clean -fxd

If that helps it would be nice if you could take note of which interface
files it removes so we can update the build system to clean them.

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/20160523/0dcf3e4b/attachment.sig>

From ben at smart-cactus.org  Mon May 23 13:33:49 2016
From: ben at smart-cactus.org (Ben Gamari)
Date: Mon, 23 May 2016 15:33:49 +0200
Subject: Build fails
In-Reply-To: <87bn3xvskl.fsf@smart-cactus.org>
References: <074f317d3b484c7a8ffaf7ae8531a6a6@DB4PR30MB030.064d.mgd.msft.net>
 <afc2ae350c09463c9ce8ebf8ed261cd7@DB4PR30MB030.064d.mgd.msft.net>
 <87bn3xvskl.fsf@smart-cactus.org>
Message-ID: <8737p8x5j6.fsf@smart-cactus.org>

Ben Gamari <ben at smart-cactus.org> writes:

> [ Unknown signature status ]
> Simon Peyton Jones <simonpj at microsoft.com> writes:
>
>> Also lots of tests give
>>
>> ghc-stage2: panic! (the 'impossible' happened)
>>
>>   (GHC version 8.1.20160523 for x86_64-unknown-linux):
>>
>>        Binary.readBinMem: decompression failed
>>
>> CallStack (from HasCallStack):
>>
>>   error, called at compiler/utils/Binary.hs:192:16 in ghc:Binary
>>
>> Should I revert some hi-file compression patch?
>
> I currently have a local build running to confirm the issue. That being
> said, Harbormaster doesn't seem to be seeing this particular issue
> (although it fails for other reasons).

Indeed I'm also seeing this. I will revert the compression patch.

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/20160523/e08115fd/attachment.sig>

From simonpj at microsoft.com  Mon May 23 15:15:25 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 23 May 2016 15:15:25 +0000
Subject: Build fails
In-Reply-To: <8737p8x5j6.fsf@smart-cactus.org>
References: <074f317d3b484c7a8ffaf7ae8531a6a6@DB4PR30MB030.064d.mgd.msft.net>
 <afc2ae350c09463c9ce8ebf8ed261cd7@DB4PR30MB030.064d.mgd.msft.net>
 <87bn3xvskl.fsf@smart-cactus.org> <8737p8x5j6.fsf@smart-cactus.org>
Message-ID: <3dd55ce633ef45f995d827bdf2dfbc5a@DB4PR30MB030.064d.mgd.msft.net>

|  Indeed I'm also seeing this. I will revert the compression patch.

OK.  When do you plan to do that?

Simon

|  -----Original Message-----
|  From: Ben Gamari [mailto:ben at smart-cactus.org]
|  Sent: 23 May 2016 14:34
|  To: Simon Peyton Jones <simonpj at microsoft.com>; Simon Peyton Jones
|  <simonpj at microsoft.com>; ghc-devs <ghc-devs at haskell.org>
|  Subject: RE: Build fails
|  
|  Ben Gamari <ben at smart-cactus.org> writes:
|  
|  > [ Unknown signature status ]
|  > Simon Peyton Jones <simonpj at microsoft.com> writes:
|  >
|  >> Also lots of tests give
|  >>
|  >> ghc-stage2: panic! (the 'impossible' happened)
|  >>
|  >>   (GHC version 8.1.20160523 for x86_64-unknown-linux):
|  >>
|  >>        Binary.readBinMem: decompression failed
|  >>
|  >> CallStack (from HasCallStack):
|  >>
|  >>   error, called at compiler/utils/Binary.hs:192:16 in ghc:Binary
|  >>
|  >> Should I revert some hi-file compression patch?
|  >
|  > I currently have a local build running to confirm the issue. That
|  > being said, Harbormaster doesn't seem to be seeing this particular
|  > issue (although it fails for other reasons).
|  
|  Indeed I'm also seeing this. I will revert the compression patch.
|  
|  Cheers,
|  
|  - Ben

From ben at smart-cactus.org  Mon May 23 15:24:31 2016
From: ben at smart-cactus.org (Ben Gamari)
Date: Mon, 23 May 2016 17:24:31 +0200
Subject: Build fails
In-Reply-To: <3dd55ce633ef45f995d827bdf2dfbc5a@DB4PR30MB030.064d.mgd.msft.net>
References: <074f317d3b484c7a8ffaf7ae8531a6a6@DB4PR30MB030.064d.mgd.msft.net>
 <afc2ae350c09463c9ce8ebf8ed261cd7@DB4PR30MB030.064d.mgd.msft.net>
 <87bn3xvskl.fsf@smart-cactus.org> <8737p8x5j6.fsf@smart-cactus.org>
 <3dd55ce633ef45f995d827bdf2dfbc5a@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <87y470vlu8.fsf@smart-cactus.org>

Simon Peyton Jones <simonpj at microsoft.com> writes:

> |  Indeed I'm also seeing this. I will revert the compression patch.
>
> OK.  When do you plan to do that?
>
Oh dear, I thought I had already done so but it seems the push failed.
Done now. Sorry for the delay!

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/20160523/d671adfb/attachment.sig>

From ben at well-typed.com  Tue May 24 08:16:48 2016
From: ben at well-typed.com (Ben Gamari)
Date: Tue, 24 May 2016 10:16:48 +0200
Subject: Unpacking single-field,
 single-strict-constructor GADTs and existentials
In-Reply-To: <CAMgWh9snErv1oEFyv5UhG_JSUfVT3FO1HHA9N2x9AOU7eSW6tA@mail.gmail.com>
References: <CAMgWh9uqPCqEqwzp6TvyprN0NGvSJ74SkreyVJEK4YEy+EpGfA@mail.gmail.com>
 <CAMgWh9u=vpNvkwyYtND7brF94EOEEkctdKva5GYtaCLpLbjEvA@mail.gmail.com>
 <CAMgWh9sMsaPA9g2f-2J9FKFHDf+Juf_HDHQy9oZc34nNF=QCJQ@mail.gmail.com>
 <CAMgWh9vZfdo_fKxWWw_s0PTmnGVKqEMQWfaruGkBJB38Lojbtw@mail.gmail.com>
 <CAMgWh9vutqciKs2-U62JLnQUaT7M0uz23inw0ju_xFi+ew92VA@mail.gmail.com>
 <CAMgWh9tr2wG3HT-SY9xtmauHHovVrsCLTo-pBp2+T-9VrhC-ig@mail.gmail.com>
 <CAMgWh9tLi3Gu=8RGWXH9OQLJ6DB=UdM+1MzOvMB_QTFhnQanYg@mail.gmail.com>
 <CAMgWh9veyXkZKSHVKPh6n4-5hy7mhd7n2v53O7h8XYCa7-Q-dQ@mail.gmail.com>
 <CAMgWh9uFVR9kypsEw0oLYmEaQnC8Y1ory7KT18FMRS-fnmE=oQ@mail.gmail.com>
 <CAMgWh9uneS8k1xEM1dYJCmR8cuf8V5s_Ssci21v=PONVJ_t21A@mail.gmail.com>
 <CAMgWh9vsPZbunmEY37rQgvtLjbbspwsrUzNFQYYxco2eyR2J=Q@mail.gmail.com>
 <CAMgWh9u5Jtz30fOrKdd1vXWvOWVkTCaRSahN2R_mMxuxhhc7yA@mail.gmail.com>
 <CAMgWh9uFmuNpNXAXPcj25gOQz66Fud9StT0m8gYrN-tj3Gy4dw@mail.gmail.com>
 <CAMgWh9uYcrNZ17R1H=J8dR=BdqWH7xekt349wFjcTADim3=RVg@mail.gmail.com>
 <CAMgWh9v7MWQB3H-p=Y
 Tg78eOX37OhcBtE=PX-7r0yUAZX6c0GQ@mail.gmail.com>
 <CAMgWh9u2h-r_7VpKrNwhLDVYvR3mO-0yzSED-7rPDuQ5h+1Emw@mail.gmail.com>
 <CAMgWh9tffEs-3PHWzxhQc2UkL+jyv+wp1=dF4mFEEo2m_m2e2w@mail.gmail.com>
 <CAMgWh9snErv1oEFyv5UhG_JSUfVT3FO1HHA9N2x9AOU7eSW6tA@mail.gmail.com>
Message-ID: <87vb23vpjj.fsf@smart-cactus.org>

David Feuer <david.feuer at gmail.com> writes:

> Data.IntMap could be cleaned up some if single-field, single strict
> constructor GADTs/existentials could be unpacked even when wrapping a sum
> type. We could then have
>
> data Status = E | NE
> data IntMap' (s :: Status) a where
>   Bin :: ... -> ... -> !(IntMap' NE a) -> !(IntMap' NE a) -> IntMap' NE a
>   Tip :: ... -> a -> IntMap' NE a
>   Nil :: IntMap' E a
> data IntMap a =
>   forall s . IM {-# UNPACK #-} !(IntMap' s a)
>
I'm not sure I understand how the existential helps you unpack this sum.
Surely I'm missing something.

> The representation would be the same as that of a newtype, but the pattern
> matching semantics would be strict. In the GADT case, this would
> essentially allow any fixed concrete datatype to serve directly as a
> witness for an arbitrary set of type equalities demanded on construction.
>
> Is there any hope something like this could happen?

Ignoring the sum issue for a moment:

My understanding is that it ought to be possible to unpack at least
single-constructor types in an existentially quantified datacon,
although someone needs to step up to do it. A closely related issue
(existentials in newtypes) was discussed by dons in a Stack Overflow
question [1] quite some time ago.

As far as I understand as long as the existentially-quantified argument
is unconstrained (therefore there is no need to carry a dictionary) and
of kind * (therefore has a uniform representation) there is no reason
why unpacking shouldn't be possible.

The case that you cite looks to be even easier since the existential is
a phantom so there is no need to represent it at all. It seems to me
like it might not be so difficult to treat this case in particular.
It's possible all that is necessary would be to adjust the unpackability
criteria in MkId.

It actually looks like there's a rather closely related ticket already
open, #10016.

Cheers,

- Ben


[1] http://stackoverflow.com/questions/5890094/is-there-a-way-to-define-an-existentially-quantified-newtype-in-ghc-haskell
-------------- 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/20160524/981399d4/attachment.sig>

From ben at well-typed.com  Tue May 24 08:22:20 2016
From: ben at well-typed.com (Ben Gamari)
Date: Tue, 24 May 2016 10:22:20 +0200
Subject: Unpacking single-field,
 single-strict-constructor GADTs and existentials
In-Reply-To: <87vb23vpjj.fsf@smart-cactus.org>
References: <CAMgWh9uqPCqEqwzp6TvyprN0NGvSJ74SkreyVJEK4YEy+EpGfA@mail.gmail.com>
 <CAMgWh9u=vpNvkwyYtND7brF94EOEEkctdKva5GYtaCLpLbjEvA@mail.gmail.com>
 <CAMgWh9sMsaPA9g2f-2J9FKFHDf+Juf_HDHQy9oZc34nNF=QCJQ@mail.gmail.com>
 <CAMgWh9vZfdo_fKxWWw_s0PTmnGVKqEMQWfaruGkBJB38Lojbtw@mail.gmail.com>
 <CAMgWh9vutqciKs2-U62JLnQUaT7M0uz23inw0ju_xFi+ew92VA@mail.gmail.com>
 <CAMgWh9tr2wG3HT-SY9xtmauHHovVrsCLTo-pBp2+T-9VrhC-ig@mail.gmail.com>
 <CAMgWh9tLi3Gu=8RGWXH9OQLJ6DB=UdM+1MzOvMB_QTFhnQanYg@mail.gmail.com>
 <CAMgWh9veyXkZKSHVKPh6n4-5hy7mhd7n2v53O7h8XYCa7-Q-dQ@mail.gmail.com>
 <CAMgWh9uFVR9kypsEw0oLYmEaQnC8Y1ory7KT18FMRS-fnmE=oQ@mail.gmail.com>
 <CAMgWh9uneS8k1xEM1dYJCmR8cuf8V5s_Ssci21v=PONVJ_t21A@mail.gmail.com>
 <CAMgWh9vsPZbunmEY37rQgvtLjbbspwsrUzNFQYYxco2eyR2J=Q@mail.gmail.com>
 <CAMgWh9u5Jtz30fOrKdd1vXWvOWVkTCaRSahN2R_mMxuxhhc7yA@mail.gmail.com>
 <CAMgWh9uFmuNpNXAXPcj25gOQz66Fud9StT0m8gYrN-tj3Gy4dw@mail.gmail.com>
 <CAMgWh9uYcrNZ17R1H=J8dR=BdqWH7xekt349wFjcTADim3=RVg@mail.gmail.com>
 <CAMgWh9u2h-r_7VpKrN
 whLDVYvR3mO-0yzSED-7rPDuQ5h+1Emw@mail.gmail.com>
 <CAMgWh9tffEs-3PHWzxhQc2UkL+jyv+wp1=dF4mFEEo2m_m2e2w@mail.gmail.com>
 <CAMgWh9snErv1oEFyv5UhG_JSUfVT3FO1HHA9N2x9AOU7eSW6tA@mail.gmail.com>
 <87vb23vpjj.fsf@smart-cactus.org>
Message-ID: <87r3crvpab.fsf@smart-cactus.org>

Ben Gamari <ben at well-typed.com> writes:

snip

> As far as I understand as long as the existentially-quantified argument
> is unconstrained (therefore there is no need to carry a dictionary) and
> of kind * (therefore has a uniform representation) there is no reason
> why unpacking shouldn't be possible.
>
To clarify, as pointed out in #10016 it should also be possible to
unpack in the constrained case. You merely need to retain a spot in the
datacon's representation to place the dictionary.

I hope this helps.

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/20160524/9e902c3f/attachment-0001.sig>

From david.feuer at gmail.com  Tue May 24 14:02:30 2016
From: david.feuer at gmail.com (David Feuer)
Date: Tue, 24 May 2016 10:02:30 -0400
Subject: Unpacking single-field,
 single-strict-constructor GADTs and existentials
In-Reply-To: <87vb23vpjj.fsf@smart-cactus.org>
References: <CAMgWh9uqPCqEqwzp6TvyprN0NGvSJ74SkreyVJEK4YEy+EpGfA@mail.gmail.com>
 <CAMgWh9u=vpNvkwyYtND7brF94EOEEkctdKva5GYtaCLpLbjEvA@mail.gmail.com>
 <CAMgWh9sMsaPA9g2f-2J9FKFHDf+Juf_HDHQy9oZc34nNF=QCJQ@mail.gmail.com>
 <CAMgWh9vZfdo_fKxWWw_s0PTmnGVKqEMQWfaruGkBJB38Lojbtw@mail.gmail.com>
 <CAMgWh9vutqciKs2-U62JLnQUaT7M0uz23inw0ju_xFi+ew92VA@mail.gmail.com>
 <CAMgWh9tr2wG3HT-SY9xtmauHHovVrsCLTo-pBp2+T-9VrhC-ig@mail.gmail.com>
 <CAMgWh9tLi3Gu=8RGWXH9OQLJ6DB=UdM+1MzOvMB_QTFhnQanYg@mail.gmail.com>
 <CAMgWh9veyXkZKSHVKPh6n4-5hy7mhd7n2v53O7h8XYCa7-Q-dQ@mail.gmail.com>
 <CAMgWh9uFVR9kypsEw0oLYmEaQnC8Y1ory7KT18FMRS-fnmE=oQ@mail.gmail.com>
 <CAMgWh9uneS8k1xEM1dYJCmR8cuf8V5s_Ssci21v=PONVJ_t21A@mail.gmail.com>
 <CAMgWh9vsPZbunmEY37rQgvtLjbbspwsrUzNFQYYxco2eyR2J=Q@mail.gmail.com>
 <CAMgWh9u5Jtz30fOrKdd1vXWvOWVkTCaRSahN2R_mMxuxhhc7yA@mail.gmail.com>
 <CAMgWh9uFmuNpNXAXPcj25gOQz66Fud9StT0m8gYrN-tj3Gy4dw@mail.gmail.com>
 <CAMgWh9uYcrNZ17R1H=J8dR=BdqWH7xekt349wFjcTADim3=RVg@mail.gmail.com>
 <CAMgWh9u2h-r_7VpKrNwhLDVYvR3mO-0yzSED-7rPDuQ5h+1Emw@mail.gmail.com>
 <CAMgWh9tffEs-3PHWzxhQc2UkL+jyv+wp1=dF4mFEEo2m_m2e2w@mail.gmail.com>
 <CAMgWh9snErv1oEFyv5UhG_JSUfVT3FO1HHA9N2x9AOU7eSW6tA@mail.gmail.com>
 <87vb23vpjj.fsf@smart-cactus.org>
Message-ID: <CAMgWh9vt89=-qiXntY_fbY9dxCDrgVAwXXhd=UGbymaUA6ogMA@mail.gmail.com>

Given

data Big a = B1 !(Small1 a) | B2 !(Small2 a) | B3 !(Small3 a), where the
Small types are (possibly recursive) sums, it's generally possible to
express that as something like

data Selector = One | Two | Three
data Big a = forall (x :: Selector) .
   Big !(BigG x a)
data BigG x a where
  GB1a :: some -> fields -> BigG 'One a
  GB1b :: fields -> BigG 'One a
  GB2a :: whatever -> BigG 'Two a
  GB3a :: yeah -> BigG 'Three a

Making one big GADT from all the constructors of the "small" types, and
then wrapping it up in an existential. That's what I meant about
"unpacking". But for efficiency purposes, that wrapper needs the newtype
optimization.
On May 24, 2016 4:16 AM, "Ben Gamari" <ben at well-typed.com> wrote:

> David Feuer <david.feuer at gmail.com> writes:
>
> > Data.IntMap could be cleaned up some if single-field, single strict
> > constructor GADTs/existentials could be unpacked even when wrapping a sum
> > type. We could then have
> >
> > data Status = E | NE
> > data IntMap' (s :: Status) a where
> >   Bin :: ... -> ... -> !(IntMap' NE a) -> !(IntMap' NE a) -> IntMap' NE a
> >   Tip :: ... -> a -> IntMap' NE a
> >   Nil :: IntMap' E a
> > data IntMap a =
> >   forall s . IM {-# UNPACK #-} !(IntMap' s a)
> >
> I'm not sure I understand how the existential helps you unpack this sum.
> Surely I'm missing something.
>
> > The representation would be the same as that of a newtype, but the
> pattern
> > matching semantics would be strict. In the GADT case, this would
> > essentially allow any fixed concrete datatype to serve directly as a
> > witness for an arbitrary set of type equalities demanded on construction.
> >
> > Is there any hope something like this could happen?
>
> Ignoring the sum issue for a moment:
>
> My understanding is that it ought to be possible to unpack at least
> single-constructor types in an existentially quantified datacon,
> although someone needs to step up to do it. A closely related issue
> (existentials in newtypes) was discussed by dons in a Stack Overflow
> question [1] quite some time ago.
>
> As far as I understand as long as the existentially-quantified argument
> is unconstrained (therefore there is no need to carry a dictionary) and
> of kind * (therefore has a uniform representation) there is no reason
> why unpacking shouldn't be possible.
>
> The case that you cite looks to be even easier since the existential is
> a phantom so there is no need to represent it at all. It seems to me
> like it might not be so difficult to treat this case in particular.
> It's possible all that is necessary would be to adjust the unpackability
> criteria in MkId.
>
> It actually looks like there's a rather closely related ticket already
> open, #10016.
>
> Cheers,
>
> - Ben
>
>
> [1]
> http://stackoverflow.com/questions/5890094/is-there-a-way-to-define-an-existentially-quantified-newtype-in-ghc-haskell
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160524/dcc1e329/attachment.html>

From carter.schonwald at gmail.com  Tue May 24 16:33:08 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Tue, 24 May 2016 12:33:08 -0400
Subject: Unpacking single-field,
 single-strict-constructor GADTs and existentials
In-Reply-To: <CAMgWh9vt89=-qiXntY_fbY9dxCDrgVAwXXhd=UGbymaUA6ogMA@mail.gmail.com>
References: <CAMgWh9uqPCqEqwzp6TvyprN0NGvSJ74SkreyVJEK4YEy+EpGfA@mail.gmail.com>
 <CAMgWh9u=vpNvkwyYtND7brF94EOEEkctdKva5GYtaCLpLbjEvA@mail.gmail.com>
 <CAMgWh9sMsaPA9g2f-2J9FKFHDf+Juf_HDHQy9oZc34nNF=QCJQ@mail.gmail.com>
 <CAMgWh9vZfdo_fKxWWw_s0PTmnGVKqEMQWfaruGkBJB38Lojbtw@mail.gmail.com>
 <CAMgWh9vutqciKs2-U62JLnQUaT7M0uz23inw0ju_xFi+ew92VA@mail.gmail.com>
 <CAMgWh9tr2wG3HT-SY9xtmauHHovVrsCLTo-pBp2+T-9VrhC-ig@mail.gmail.com>
 <CAMgWh9tLi3Gu=8RGWXH9OQLJ6DB=UdM+1MzOvMB_QTFhnQanYg@mail.gmail.com>
 <CAMgWh9veyXkZKSHVKPh6n4-5hy7mhd7n2v53O7h8XYCa7-Q-dQ@mail.gmail.com>
 <CAMgWh9uFVR9kypsEw0oLYmEaQnC8Y1ory7KT18FMRS-fnmE=oQ@mail.gmail.com>
 <CAMgWh9uneS8k1xEM1dYJCmR8cuf8V5s_Ssci21v=PONVJ_t21A@mail.gmail.com>
 <CAMgWh9vsPZbunmEY37rQgvtLjbbspwsrUzNFQYYxco2eyR2J=Q@mail.gmail.com>
 <CAMgWh9u5Jtz30fOrKdd1vXWvOWVkTCaRSahN2R_mMxuxhhc7yA@mail.gmail.com>
 <CAMgWh9uFmuNpNXAXPcj25gOQz66Fud9StT0m8gYrN-tj3Gy4dw@mail.gmail.com>
 <CAMgWh9uYcrNZ17R1H=J8dR=BdqWH7xekt349wFjcTADim3=RVg@mail.gmail.com>
 <CAMgWh9u2h-r_7VpKrNwhLDVYvR3mO-0yzSED-7rPDuQ5h+1Emw@mail.gmail.com>
 <CAMgWh9tffEs-3PHWzxhQc2UkL+jyv+wp1=dF4mFEEo2m_m2e2w@mail.gmail.com>
 <CAMgWh9snErv1oEFyv5UhG_JSUfVT3FO1HHA9N2x9AOU7eSW6tA@mail.gmail.com>
 <87vb23vpjj.fsf@smart-cactus.org>
 <CAMgWh9vt89=-qiXntY_fbY9dxCDrgVAwXXhd=UGbymaUA6ogMA@mail.gmail.com>
Message-ID: <CAHYVw0zkrU1GDrtWP91WmbPczDKnf=39+Afyx-8OhNxOiZfQ3w@mail.gmail.com>

This sounds to me like what we're trying to describe here smells like an
unboxed existential , which is a hairs breadth out of reach of ghcs type
system

@david have you tried out eds structures package? It may provide the right
tooling to simulate this or something close to what you want.

On Tuesday, May 24, 2016, David Feuer <david.feuer at gmail.com> wrote:

> Given
>
> data Big a = B1 !(Small1 a) | B2 !(Small2 a) | B3 !(Small3 a), where the
> Small types are (possibly recursive) sums, it's generally possible to
> express that as something like
>
> data Selector = One | Two | Three
> data Big a = forall (x :: Selector) .
>    Big !(BigG x a)
> data BigG x a where
>   GB1a :: some -> fields -> BigG 'One a
>   GB1b :: fields -> BigG 'One a
>   GB2a :: whatever -> BigG 'Two a
>   GB3a :: yeah -> BigG 'Three a
>
> Making one big GADT from all the constructors of the "small" types, and
> then wrapping it up in an existential. That's what I meant about
> "unpacking". But for efficiency purposes, that wrapper needs the newtype
> optimization.
> On May 24, 2016 4:16 AM, "Ben Gamari" <ben at well-typed.com
> <javascript:_e(%7B%7D,'cvml','ben at well-typed.com');>> wrote:
>
>> David Feuer <david.feuer at gmail.com
>> <javascript:_e(%7B%7D,'cvml','david.feuer at gmail.com');>> writes:
>>
>> > Data.IntMap could be cleaned up some if single-field, single strict
>> > constructor GADTs/existentials could be unpacked even when wrapping a
>> sum
>> > type. We could then have
>> >
>> > data Status = E | NE
>> > data IntMap' (s :: Status) a where
>> >   Bin :: ... -> ... -> !(IntMap' NE a) -> !(IntMap' NE a) -> IntMap' NE
>> a
>> >   Tip :: ... -> a -> IntMap' NE a
>> >   Nil :: IntMap' E a
>> > data IntMap a =
>> >   forall s . IM {-# UNPACK #-} !(IntMap' s a)
>> >
>> I'm not sure I understand how the existential helps you unpack this sum.
>> Surely I'm missing something.
>>
>> > The representation would be the same as that of a newtype, but the
>> pattern
>> > matching semantics would be strict. In the GADT case, this would
>> > essentially allow any fixed concrete datatype to serve directly as a
>> > witness for an arbitrary set of type equalities demanded on
>> construction.
>> >
>> > Is there any hope something like this could happen?
>>
>> Ignoring the sum issue for a moment:
>>
>> My understanding is that it ought to be possible to unpack at least
>> single-constructor types in an existentially quantified datacon,
>> although someone needs to step up to do it. A closely related issue
>> (existentials in newtypes) was discussed by dons in a Stack Overflow
>> question [1] quite some time ago.
>>
>> As far as I understand as long as the existentially-quantified argument
>> is unconstrained (therefore there is no need to carry a dictionary) and
>> of kind * (therefore has a uniform representation) there is no reason
>> why unpacking shouldn't be possible.
>>
>> The case that you cite looks to be even easier since the existential is
>> a phantom so there is no need to represent it at all. It seems to me
>> like it might not be so difficult to treat this case in particular.
>> It's possible all that is necessary would be to adjust the unpackability
>> criteria in MkId.
>>
>> It actually looks like there's a rather closely related ticket already
>> open, #10016.
>>
>> Cheers,
>>
>> - Ben
>>
>>
>> [1]
>> http://stackoverflow.com/questions/5890094/is-there-a-way-to-define-an-existentially-quantified-newtype-in-ghc-haskell
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160524/74440294/attachment.html>

From ben at well-typed.com  Tue May 24 16:43:02 2016
From: ben at well-typed.com (Ben Gamari)
Date: Tue, 24 May 2016 18:43:02 +0200
Subject: Unpacking single-field,
 single-strict-constructor GADTs and existentials
In-Reply-To: <CAMgWh9vt89=-qiXntY_fbY9dxCDrgVAwXXhd=UGbymaUA6ogMA@mail.gmail.com>
References: <CAMgWh9uqPCqEqwzp6TvyprN0NGvSJ74SkreyVJEK4YEy+EpGfA@mail.gmail.com>
 <CAMgWh9u=vpNvkwyYtND7brF94EOEEkctdKva5GYtaCLpLbjEvA@mail.gmail.com>
 <CAMgWh9sMsaPA9g2f-2J9FKFHDf+Juf_HDHQy9oZc34nNF=QCJQ@mail.gmail.com>
 <CAMgWh9vZfdo_fKxWWw_s0PTmnGVKqEMQWfaruGkBJB38Lojbtw@mail.gmail.com>
 <CAMgWh9vutqciKs2-U62JLnQUaT7M0uz23inw0ju_xFi+ew92VA@mail.gmail.com>
 <CAMgWh9tr2wG3HT-SY9xtmauHHovVrsCLTo-pBp2+T-9VrhC-ig@mail.gmail.com>
 <CAMgWh9tLi3Gu=8RGWXH9OQLJ6DB=UdM+1MzOvMB_QTFhnQanYg@mail.gmail.com>
 <CAMgWh9veyXkZKSHVKPh6n4-5hy7mhd7n2v53O7h8XYCa7-Q-dQ@mail.gmail.com>
 <CAMgWh9uFVR9kypsEw0oLYmEaQnC8Y1ory7KT18FMRS-fnmE=oQ@mail.gmail.com>
 <CAMgWh9uneS8k1xEM1dYJCmR8cuf8V5s_Ssci21v=PONVJ_t21A@mail.gmail.com>
 <CAMgWh9vsPZbunmEY37rQgvtLjbbspwsrUzNFQYYxco2eyR2J=Q@mail.gmail.com>
 <CAMgWh9u5Jtz30fOrKdd1vXWvOWVkTCaRSahN2R_mMxuxhhc7yA@mail.gmail.com>
 <CAMgWh9uFmuNpNXAXPcj25gOQz66Fud9StT0m8gYrN-tj3Gy4dw@mail.gmail.com>
 <CAMgWh9uYcrNZ17R1H=J8dR=BdqWH7xekt349wFjcTADim3=RVg@mail.gmail.com>
 <CAMgWh9u2h-r_7VpKrN
 whLDVYvR3mO-0yzSED-7rPDuQ5h+1Emw@mail.gmail.com>
 <CAMgWh9tffEs-3PHWzxhQc2UkL+jyv+wp1=dF4mFEEo2m_m2e2w@mail.gmail.com>
 <CAMgWh9snErv1oEFyv5UhG_JSUfVT3FO1HHA9N2x9AOU7eSW6tA@mail.gmail.com>
 <87vb23vpjj.fsf@smart-cactus.org>
 <CAMgWh9vt89=-qiXntY_fbY9dxCDrgVAwXXhd=UGbymaUA6ogMA@mail.gmail.com>
Message-ID: <87h9dnv23t.fsf@smart-cactus.org>

David Feuer <david.feuer at gmail.com> writes:

> Given
>
> data Big a = B1 !(Small1 a) | B2 !(Small2 a) | B3 !(Small3 a), where the
> Small types are (possibly recursive) sums, it's generally possible to
> express that as something like
>
> data Selector = One | Two | Three
> data Big a = forall (x :: Selector) .
>    Big !(BigG x a)
> data BigG x a where
>   GB1a :: some -> fields -> BigG 'One a
>   GB1b :: fields -> BigG 'One a
>   GB2a :: whatever -> BigG 'Two a
>   GB3a :: yeah -> BigG 'Three a
>
> Making one big GADT from all the constructors of the "small" types, and
> then wrapping it up in an existential. That's what I meant about
> "unpacking". But for efficiency purposes, that wrapper needs the newtype
> optimization.

Yes, but you'd need to unbox a sum in this case, no? I think this is the
first issue that you need to solve before you can talk about dealing
with the polymorphism issue (although hopefully ?mer will make progress
on this for 8.2).

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/20160524/1f22cc95/attachment.sig>

From david.feuer at gmail.com  Tue May 24 17:46:37 2016
From: david.feuer at gmail.com (David Feuer)
Date: Tue, 24 May 2016 13:46:37 -0400
Subject: Unpacking single-field,
 single-strict-constructor GADTs and existentials
In-Reply-To: <87h9dnv23t.fsf@smart-cactus.org>
References: <CAMgWh9uqPCqEqwzp6TvyprN0NGvSJ74SkreyVJEK4YEy+EpGfA@mail.gmail.com>
 <CAMgWh9u=vpNvkwyYtND7brF94EOEEkctdKva5GYtaCLpLbjEvA@mail.gmail.com>
 <CAMgWh9sMsaPA9g2f-2J9FKFHDf+Juf_HDHQy9oZc34nNF=QCJQ@mail.gmail.com>
 <CAMgWh9vZfdo_fKxWWw_s0PTmnGVKqEMQWfaruGkBJB38Lojbtw@mail.gmail.com>
 <CAMgWh9vutqciKs2-U62JLnQUaT7M0uz23inw0ju_xFi+ew92VA@mail.gmail.com>
 <CAMgWh9tr2wG3HT-SY9xtmauHHovVrsCLTo-pBp2+T-9VrhC-ig@mail.gmail.com>
 <CAMgWh9tLi3Gu=8RGWXH9OQLJ6DB=UdM+1MzOvMB_QTFhnQanYg@mail.gmail.com>
 <CAMgWh9veyXkZKSHVKPh6n4-5hy7mhd7n2v53O7h8XYCa7-Q-dQ@mail.gmail.com>
 <CAMgWh9uFVR9kypsEw0oLYmEaQnC8Y1ory7KT18FMRS-fnmE=oQ@mail.gmail.com>
 <CAMgWh9uneS8k1xEM1dYJCmR8cuf8V5s_Ssci21v=PONVJ_t21A@mail.gmail.com>
 <CAMgWh9vsPZbunmEY37rQgvtLjbbspwsrUzNFQYYxco2eyR2J=Q@mail.gmail.com>
 <CAMgWh9u5Jtz30fOrKdd1vXWvOWVkTCaRSahN2R_mMxuxhhc7yA@mail.gmail.com>
 <CAMgWh9uFmuNpNXAXPcj25gOQz66Fud9StT0m8gYrN-tj3Gy4dw@mail.gmail.com>
 <CAMgWh9uYcrNZ17R1H=J8dR=BdqWH7xekt349wFjcTADim3=RVg@mail.gmail.com>
 <CAMgWh9tffEs-3PHWzxhQc2UkL+jyv+wp1=dF4mFEEo2m_m2e2w@mail.gmail.com>
 <CAMgWh9snErv1oEFyv5UhG_JSUfVT3FO1HHA9N2x9AOU7eSW6tA@mail.gmail.com>
 <87vb23vpjj.fsf@smart-cactus.org>
 <CAMgWh9vt89=-qiXntY_fbY9dxCDrgVAwXXhd=UGbymaUA6ogMA@mail.gmail.com>
 <87h9dnv23t.fsf@smart-cactus.org>
Message-ID: <CAMgWh9ss=Z1n29jBuaZKdV+H4xOCavR+uoPiM=T9SuZz8K-uiA@mail.gmail.com>

Not really. It's really just the newtype optimization, although it's not a
newtype.
On May 24, 2016 12:43 PM, "Ben Gamari" <ben at well-typed.com> wrote:

> David Feuer <david.feuer at gmail.com> writes:
>
> > Given
> >
> > data Big a = B1 !(Small1 a) | B2 !(Small2 a) | B3 !(Small3 a), where the
> > Small types are (possibly recursive) sums, it's generally possible to
> > express that as something like
> >
> > data Selector = One | Two | Three
> > data Big a = forall (x :: Selector) .
> >    Big !(BigG x a)
> > data BigG x a where
> >   GB1a :: some -> fields -> BigG 'One a
> >   GB1b :: fields -> BigG 'One a
> >   GB2a :: whatever -> BigG 'Two a
> >   GB3a :: yeah -> BigG 'Three a
> >
> > Making one big GADT from all the constructors of the "small" types, and
> > then wrapping it up in an existential. That's what I meant about
> > "unpacking". But for efficiency purposes, that wrapper needs the newtype
> > optimization.
>
> Yes, but you'd need to unbox a sum in this case, no? I think this is the
> first issue that you need to solve before you can talk about dealing
> with the polymorphism issue (although hopefully ?mer will make progress
> on this for 8.2).
>
> Cheers,
>
> - Ben
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160524/6d060312/attachment-0001.html>

From ben at well-typed.com  Tue May 24 20:18:49 2016
From: ben at well-typed.com (Ben Gamari)
Date: Tue, 24 May 2016 22:18:49 +0200
Subject: Unpacking single-field,
 single-strict-constructor GADTs and existentials
In-Reply-To: <CAMgWh9ss=Z1n29jBuaZKdV+H4xOCavR+uoPiM=T9SuZz8K-uiA@mail.gmail.com>
References: <CAMgWh9uqPCqEqwzp6TvyprN0NGvSJ74SkreyVJEK4YEy+EpGfA@mail.gmail.com>
 <CAMgWh9u=vpNvkwyYtND7brF94EOEEkctdKva5GYtaCLpLbjEvA@mail.gmail.com>
 <CAMgWh9sMsaPA9g2f-2J9FKFHDf+Juf_HDHQy9oZc34nNF=QCJQ@mail.gmail.com>
 <CAMgWh9vZfdo_fKxWWw_s0PTmnGVKqEMQWfaruGkBJB38Lojbtw@mail.gmail.com>
 <CAMgWh9vutqciKs2-U62JLnQUaT7M0uz23inw0ju_xFi+ew92VA@mail.gmail.com>
 <CAMgWh9tr2wG3HT-SY9xtmauHHovVrsCLTo-pBp2+T-9VrhC-ig@mail.gmail.com>
 <CAMgWh9tLi3Gu=8RGWXH9OQLJ6DB=UdM+1MzOvMB_QTFhnQanYg@mail.gmail.com>
 <CAMgWh9veyXkZKSHVKPh6n4-5hy7mhd7n2v53O7h8XYCa7-Q-dQ@mail.gmail.com>
 <CAMgWh9uFVR9kypsEw0oLYmEaQnC8Y1ory7KT18FMRS-fnmE=oQ@mail.gmail.com>
 <CAMgWh9uneS8k1xEM1dYJCmR8cuf8V5s_Ssci21v=PONVJ_t21A@mail.gmail.com>
 <CAMgWh9vsPZbunmEY37rQgvtLjbbspwsrUzNFQYYxco2eyR2J=Q@mail.gmail.com>
 <CAMgWh9u5Jtz30fOrKdd1vXWvOWVkTCaRSahN2R_mMxuxhhc7yA@mail.gmail.com>
 <CAMgWh9uFmuNpNXAXPcj25gOQz66Fud9StT0m8gYrN-tj3Gy4dw@mail.gmail.com>
 <CAMgWh9uYcrNZ17R1H=J8dR=BdqWH7xekt349wFjcTADim3=RVg@mail.gmail.com>
 <CAMgWh9tffEs-3PHWzx
 hQc2UkL+jyv+wp1=dF4mFEEo2m_m2e2w@mail.gmail.com>
 <CAMgWh9snErv1oEFyv5UhG_JSUfVT3FO1HHA9N2x9AOU7eSW6tA@mail.gmail.com>
 <87vb23vpjj.fsf@smart-cactus.org>
 <CAMgWh9vt89=-qiXntY_fbY9dxCDrgVAwXXhd=UGbymaUA6ogMA@mail.gmail.com>
 <87h9dnv23t.fsf@smart-cactus.org>
 <CAMgWh9ss=Z1n29jBuaZKdV+H4xOCavR+uoPiM=T9SuZz8K-uiA@mail.gmail.com>
Message-ID: <877fejus46.fsf@smart-cactus.org>

David Feuer <david.feuer at gmail.com> writes:

> Not really. It's really just the newtype optimization, although it's not a
> newtype.

Ahh, I see. Yes, you are right. I was being silly.

However, in this case wouldn't it make more sense to just call it a newtype?

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/20160524/44e5fab8/attachment.sig>

From david.feuer at gmail.com  Tue May 24 20:20:41 2016
From: david.feuer at gmail.com (David Feuer)
Date: Tue, 24 May 2016 16:20:41 -0400
Subject: Unpacking single-field,
 single-strict-constructor GADTs and existentials
In-Reply-To: <877fejus46.fsf@smart-cactus.org>
References: <CAMgWh9uqPCqEqwzp6TvyprN0NGvSJ74SkreyVJEK4YEy+EpGfA@mail.gmail.com>
 <CAMgWh9u=vpNvkwyYtND7brF94EOEEkctdKva5GYtaCLpLbjEvA@mail.gmail.com>
 <CAMgWh9sMsaPA9g2f-2J9FKFHDf+Juf_HDHQy9oZc34nNF=QCJQ@mail.gmail.com>
 <CAMgWh9vZfdo_fKxWWw_s0PTmnGVKqEMQWfaruGkBJB38Lojbtw@mail.gmail.com>
 <CAMgWh9vutqciKs2-U62JLnQUaT7M0uz23inw0ju_xFi+ew92VA@mail.gmail.com>
 <CAMgWh9tr2wG3HT-SY9xtmauHHovVrsCLTo-pBp2+T-9VrhC-ig@mail.gmail.com>
 <CAMgWh9tLi3Gu=8RGWXH9OQLJ6DB=UdM+1MzOvMB_QTFhnQanYg@mail.gmail.com>
 <CAMgWh9veyXkZKSHVKPh6n4-5hy7mhd7n2v53O7h8XYCa7-Q-dQ@mail.gmail.com>
 <CAMgWh9uFVR9kypsEw0oLYmEaQnC8Y1ory7KT18FMRS-fnmE=oQ@mail.gmail.com>
 <CAMgWh9uneS8k1xEM1dYJCmR8cuf8V5s_Ssci21v=PONVJ_t21A@mail.gmail.com>
 <CAMgWh9vsPZbunmEY37rQgvtLjbbspwsrUzNFQYYxco2eyR2J=Q@mail.gmail.com>
 <CAMgWh9u5Jtz30fOrKdd1vXWvOWVkTCaRSahN2R_mMxuxhhc7yA@mail.gmail.com>
 <CAMgWh9uFmuNpNXAXPcj25gOQz66Fud9StT0m8gYrN-tj3Gy4dw@mail.gmail.com>
 <CAMgWh9uYcrNZ17R1H=J8dR=BdqWH7xekt349wFjcTADim3=RVg@mail.gmail.com>
 <CAMgWh9snErv1oEFyv5UhG_JSUfVT3FO1HHA9N2x9AOU7eSW6tA@mail.gmail.com>
 <87vb23vpjj.fsf@smart-cactus.org>
 <CAMgWh9vt89=-qiXntY_fbY9dxCDrgVAwXXhd=UGbymaUA6ogMA@mail.gmail.com>
 <87h9dnv23t.fsf@smart-cactus.org>
 <CAMgWh9ss=Z1n29jBuaZKdV+H4xOCavR+uoPiM=T9SuZz8K-uiA@mail.gmail.com>
 <877fejus46.fsf@smart-cactus.org>
Message-ID: <CAMgWh9vjeaJskd8oc3krC_SOrSa23R8GDzTwbzpkFJkCwrka0A@mail.gmail.com>

No, because the pattern matching semantics are different. Matching on
the constructor *must* force the contents to maintain type safety.
It's really strict data with the newtype optimization, rather than a
bona fide newtype.

On Tue, May 24, 2016 at 4:18 PM, Ben Gamari <ben at well-typed.com> wrote:
> David Feuer <david.feuer at gmail.com> writes:
>
>> Not really. It's really just the newtype optimization, although it's not a
>> newtype.
>
> Ahh, I see. Yes, you are right. I was being silly.
>
> However, in this case wouldn't it make more sense to just call it a newtype?
>
> Cheers,
>
> - Ben

From david.feuer at gmail.com  Tue May 24 21:39:29 2016
From: david.feuer at gmail.com (David Feuer)
Date: Tue, 24 May 2016 17:39:29 -0400
Subject: Unpacking single-field,
 single-strict-constructor GADTs and existentials
In-Reply-To: <87h9dnv23t.fsf@smart-cactus.org>
References: <CAMgWh9uqPCqEqwzp6TvyprN0NGvSJ74SkreyVJEK4YEy+EpGfA@mail.gmail.com>
 <CAMgWh9u=vpNvkwyYtND7brF94EOEEkctdKva5GYtaCLpLbjEvA@mail.gmail.com>
 <CAMgWh9sMsaPA9g2f-2J9FKFHDf+Juf_HDHQy9oZc34nNF=QCJQ@mail.gmail.com>
 <CAMgWh9vZfdo_fKxWWw_s0PTmnGVKqEMQWfaruGkBJB38Lojbtw@mail.gmail.com>
 <CAMgWh9vutqciKs2-U62JLnQUaT7M0uz23inw0ju_xFi+ew92VA@mail.gmail.com>
 <CAMgWh9tr2wG3HT-SY9xtmauHHovVrsCLTo-pBp2+T-9VrhC-ig@mail.gmail.com>
 <CAMgWh9tLi3Gu=8RGWXH9OQLJ6DB=UdM+1MzOvMB_QTFhnQanYg@mail.gmail.com>
 <CAMgWh9veyXkZKSHVKPh6n4-5hy7mhd7n2v53O7h8XYCa7-Q-dQ@mail.gmail.com>
 <CAMgWh9uFVR9kypsEw0oLYmEaQnC8Y1ory7KT18FMRS-fnmE=oQ@mail.gmail.com>
 <CAMgWh9uneS8k1xEM1dYJCmR8cuf8V5s_Ssci21v=PONVJ_t21A@mail.gmail.com>
 <CAMgWh9vsPZbunmEY37rQgvtLjbbspwsrUzNFQYYxco2eyR2J=Q@mail.gmail.com>
 <CAMgWh9u5Jtz30fOrKdd1vXWvOWVkTCaRSahN2R_mMxuxhhc7yA@mail.gmail.com>
 <CAMgWh9uFmuNpNXAXPcj25gOQz66Fud9StT0m8gYrN-tj3Gy4dw@mail.gmail.com>
 <CAMgWh9uYcrNZ17R1H=J8dR=BdqWH7xekt349wFjcTADim3=RVg@mail.gmail.com>
 <CAMgWh9tffEs-3PHWzxhQc2UkL+jyv+wp1=dF4mFEEo2m_m2e2w@mail.gmail.com>
 <CAMgWh9snErv1oEFyv5UhG_JSUfVT3FO1HHA9N2x9AOU7eSW6tA@mail.gmail.com>
 <87vb23vpjj.fsf@smart-cactus.org>
 <CAMgWh9vt89=-qiXntY_fbY9dxCDrgVAwXXhd=UGbymaUA6ogMA@mail.gmail.com>
 <87h9dnv23t.fsf@smart-cactus.org>
Message-ID: <CAMgWh9s5qrFgkTfTtFtfTzDdEXXm5PJsmmUDfBf2nDKX8-Ky8g@mail.gmail.com>

I should mention that while this does not require UNPACKing sum types (or
any of the difficult trade-offs that involves), it lets programmers
accomplish such unpacking by hand under sufficiently general conditions to
be quite useful in practice. As long as the set of types involved is
closed, it'll do.
David Feuer <david.feuer at gmail.com> writes:

> Given
>
> data Big a = B1 !(Small1 a) | B2 !(Small2 a) | B3 !(Small3 a), where the
> Small types are (possibly recursive) sums, it's generally possible to
> express that as something like
>
> data Selector = One | Two | Three
> data Big a = forall (x :: Selector) .
>    Big !(BigG x a)
> data BigG x a where
>   GB1a :: some -> fields -> BigG 'One a
>   GB1b :: fields -> BigG 'One a
>   GB2a :: whatever -> BigG 'Two a
>   GB3a :: yeah -> BigG 'Three a
>
> Making one big GADT from all the constructors of the "small" types, and
> then wrapping it up in an existential. That's what I meant about
> "unpacking". But for efficiency purposes, that wrapper needs the newtype
> optimization.

Yes, but you'd need to unbox a sum in this case, no? I think this is the
first issue that you need to solve before you can talk about dealing
with the polymorphism issue (although hopefully ?mer will make progress
on this for 8.2).

Cheers,

- Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160524/2055d699/attachment.html>

From carter.schonwald at gmail.com  Tue May 24 22:03:49 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Tue, 24 May 2016 18:03:49 -0400
Subject: Unpacking single-field,
 single-strict-constructor GADTs and existentials
In-Reply-To: <CAMgWh9s5qrFgkTfTtFtfTzDdEXXm5PJsmmUDfBf2nDKX8-Ky8g@mail.gmail.com>
References: <CAMgWh9uqPCqEqwzp6TvyprN0NGvSJ74SkreyVJEK4YEy+EpGfA@mail.gmail.com>
 <CAMgWh9u=vpNvkwyYtND7brF94EOEEkctdKva5GYtaCLpLbjEvA@mail.gmail.com>
 <CAMgWh9sMsaPA9g2f-2J9FKFHDf+Juf_HDHQy9oZc34nNF=QCJQ@mail.gmail.com>
 <CAMgWh9vZfdo_fKxWWw_s0PTmnGVKqEMQWfaruGkBJB38Lojbtw@mail.gmail.com>
 <CAMgWh9vutqciKs2-U62JLnQUaT7M0uz23inw0ju_xFi+ew92VA@mail.gmail.com>
 <CAMgWh9tr2wG3HT-SY9xtmauHHovVrsCLTo-pBp2+T-9VrhC-ig@mail.gmail.com>
 <CAMgWh9tLi3Gu=8RGWXH9OQLJ6DB=UdM+1MzOvMB_QTFhnQanYg@mail.gmail.com>
 <CAMgWh9veyXkZKSHVKPh6n4-5hy7mhd7n2v53O7h8XYCa7-Q-dQ@mail.gmail.com>
 <CAMgWh9uFVR9kypsEw0oLYmEaQnC8Y1ory7KT18FMRS-fnmE=oQ@mail.gmail.com>
 <CAMgWh9uneS8k1xEM1dYJCmR8cuf8V5s_Ssci21v=PONVJ_t21A@mail.gmail.com>
 <CAMgWh9vsPZbunmEY37rQgvtLjbbspwsrUzNFQYYxco2eyR2J=Q@mail.gmail.com>
 <CAMgWh9u5Jtz30fOrKdd1vXWvOWVkTCaRSahN2R_mMxuxhhc7yA@mail.gmail.com>
 <CAMgWh9uFmuNpNXAXPcj25gOQz66Fud9StT0m8gYrN-tj3Gy4dw@mail.gmail.com>
 <CAMgWh9uYcrNZ17R1H=J8dR=BdqWH7xekt349wFjcTADim3=RVg@mail.gmail.com>
 <CAMgWh9tffEs-3PHWzxhQc2UkL+jyv+wp1=dF4mFEEo2m_m2e2w@mail.gmail.com>
 <CAMgWh9snErv1oEFyv5UhG_JSUfVT3FO1HHA9N2x9AOU7eSW6tA@mail.gmail.com>
 <87vb23vpjj.fsf@smart-cactus.org>
 <CAMgWh9vt89=-qiXntY_fbY9dxCDrgVAwXXhd=UGbymaUA6ogMA@mail.gmail.com>
 <87h9dnv23t.fsf@smart-cactus.org>
 <CAMgWh9s5qrFgkTfTtFtfTzDdEXXm5PJsmmUDfBf2nDKX8-Ky8g@mail.gmail.com>
Message-ID: <CAHYVw0zLUP5ObmHrGzh6_20n=H-abUkxpObHKz323s7b-SwZhQ@mail.gmail.com>

Phrased differently: there's a subclass of existential data types which
have a well behaved unboxed memory layout?

@ David : have you tried simulating this in userland using eds structs /
structures lib?

On Tuesday, May 24, 2016, David Feuer <david.feuer at gmail.com> wrote:

> I should mention that while this does not require UNPACKing sum types (or
> any of the difficult trade-offs that involves), it lets programmers
> accomplish such unpacking by hand under sufficiently general conditions to
> be quite useful in practice. As long as the set of types involved is
> closed, it'll do.
> David Feuer <david.feuer at gmail.com
> <javascript:_e(%7B%7D,'cvml','david.feuer at gmail.com');>> writes:
>
> > Given
> >
> > data Big a = B1 !(Small1 a) | B2 !(Small2 a) | B3 !(Small3 a), where the
> > Small types are (possibly recursive) sums, it's generally possible to
> > express that as something like
> >
> > data Selector = One | Two | Three
> > data Big a = forall (x :: Selector) .
> >    Big !(BigG x a)
> > data BigG x a where
> >   GB1a :: some -> fields -> BigG 'One a
> >   GB1b :: fields -> BigG 'One a
> >   GB2a :: whatever -> BigG 'Two a
> >   GB3a :: yeah -> BigG 'Three a
> >
> > Making one big GADT from all the constructors of the "small" types, and
> > then wrapping it up in an existential. That's what I meant about
> > "unpacking". But for efficiency purposes, that wrapper needs the newtype
> > optimization.
>
> Yes, but you'd need to unbox a sum in this case, no? I think this is the
> first issue that you need to solve before you can talk about dealing
> with the polymorphism issue (although hopefully ?mer will make progress
> on this for 8.2).
>
> Cheers,
>
> - Ben
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160524/d1957215/attachment.html>

From david.feuer at gmail.com  Tue May 24 22:13:54 2016
From: david.feuer at gmail.com (David Feuer)
Date: Tue, 24 May 2016 18:13:54 -0400
Subject: Unpacking single-field,
 single-strict-constructor GADTs and existentials
In-Reply-To: <CAHYVw0zLUP5ObmHrGzh6_20n=H-abUkxpObHKz323s7b-SwZhQ@mail.gmail.com>
References: <CAMgWh9uqPCqEqwzp6TvyprN0NGvSJ74SkreyVJEK4YEy+EpGfA@mail.gmail.com>
 <CAMgWh9u=vpNvkwyYtND7brF94EOEEkctdKva5GYtaCLpLbjEvA@mail.gmail.com>
 <CAMgWh9sMsaPA9g2f-2J9FKFHDf+Juf_HDHQy9oZc34nNF=QCJQ@mail.gmail.com>
 <CAMgWh9vZfdo_fKxWWw_s0PTmnGVKqEMQWfaruGkBJB38Lojbtw@mail.gmail.com>
 <CAMgWh9vutqciKs2-U62JLnQUaT7M0uz23inw0ju_xFi+ew92VA@mail.gmail.com>
 <CAMgWh9tr2wG3HT-SY9xtmauHHovVrsCLTo-pBp2+T-9VrhC-ig@mail.gmail.com>
 <CAMgWh9tLi3Gu=8RGWXH9OQLJ6DB=UdM+1MzOvMB_QTFhnQanYg@mail.gmail.com>
 <CAMgWh9veyXkZKSHVKPh6n4-5hy7mhd7n2v53O7h8XYCa7-Q-dQ@mail.gmail.com>
 <CAMgWh9uFVR9kypsEw0oLYmEaQnC8Y1ory7KT18FMRS-fnmE=oQ@mail.gmail.com>
 <CAMgWh9uneS8k1xEM1dYJCmR8cuf8V5s_Ssci21v=PONVJ_t21A@mail.gmail.com>
 <CAMgWh9vsPZbunmEY37rQgvtLjbbspwsrUzNFQYYxco2eyR2J=Q@mail.gmail.com>
 <CAMgWh9u5Jtz30fOrKdd1vXWvOWVkTCaRSahN2R_mMxuxhhc7yA@mail.gmail.com>
 <CAMgWh9uFmuNpNXAXPcj25gOQz66Fud9StT0m8gYrN-tj3Gy4dw@mail.gmail.com>
 <CAMgWh9uYcrNZ17R1H=J8dR=BdqWH7xekt349wFjcTADim3=RVg@mail.gmail.com>
 <CAMgWh9tffEs-3PHWzxhQc2UkL+jyv+wp1=dF4mFEEo2m_m2e2w@mail.gmail.com>
 <CAMgWh9snErv1oEFyv5UhG_JSUfVT3FO1HHA9N2x9AOU7eSW6tA@mail.gmail.com>
 <87vb23vpjj.fsf@smart-cactus.org>
 <CAMgWh9vt89=-qiXntY_fbY9dxCDrgVAwXXhd=UGbymaUA6ogMA@mail.gmail.com>
 <87h9dnv23t.fsf@smart-cactus.org>
 <CAMgWh9s5qrFgkTfTtFtfTzDdEXXm5PJsmmUDfBf2nDKX8-Ky8g@mail.gmail.com>
 <CAHYVw0zLUP5ObmHrGzh6_20n=H-abUkxpObHKz323s7b-SwZhQ@mail.gmail.com>
Message-ID: <CAMgWh9v5U=u2UtOPMomf+Rm-KM+j-mg3u++bEv1d+fzoGjrrEA@mail.gmail.com>

Unboxing, per se, is not required; only newtype optimization. I
believe Ed would probably have mentioned something when I discussed
the issue with him if he'd already had an idea for hacking around it.
Instead, he said he wanted the feature too.

On Tue, May 24, 2016 at 6:03 PM, Carter Schonwald
<carter.schonwald at gmail.com> wrote:
> Phrased differently: there's a subclass of existential data types which have
> a well behaved unboxed memory layout?
>
> @ David : have you tried simulating this in userland using eds structs /
> structures lib?
>
> On Tuesday, May 24, 2016, David Feuer <david.feuer at gmail.com> wrote:
>>
>> I should mention that while this does not require UNPACKing sum types (or
>> any of the difficult trade-offs that involves), it lets programmers
>> accomplish such unpacking by hand under sufficiently general conditions to
>> be quite useful in practice. As long as the set of types involved is closed,
>> it'll do.
>>
>> David Feuer <david.feuer at gmail.com> writes:
>>
>> > Given
>> >
>> > data Big a = B1 !(Small1 a) | B2 !(Small2 a) | B3 !(Small3 a), where the
>> > Small types are (possibly recursive) sums, it's generally possible to
>> > express that as something like
>> >
>> > data Selector = One | Two | Three
>> > data Big a = forall (x :: Selector) .
>> >    Big !(BigG x a)
>> > data BigG x a where
>> >   GB1a :: some -> fields -> BigG 'One a
>> >   GB1b :: fields -> BigG 'One a
>> >   GB2a :: whatever -> BigG 'Two a
>> >   GB3a :: yeah -> BigG 'Three a
>> >
>> > Making one big GADT from all the constructors of the "small" types, and
>> > then wrapping it up in an existential. That's what I meant about
>> > "unpacking". But for efficiency purposes, that wrapper needs the newtype
>> > optimization.
>>
>> Yes, but you'd need to unbox a sum in this case, no? I think this is the
>> first issue that you need to solve before you can talk about dealing
>> with the polymorphism issue (although hopefully ?mer will make progress
>> on this for 8.2).
>>
>> Cheers,
>>
>> - Ben

From simonpj at microsoft.com  Wed May 25 07:27:51 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 25 May 2016 07:27:51 +0000
Subject: Unpacking single-field, single-strict-constructor GADTs and
 existentials
In-Reply-To: <CAMgWh9v5U=u2UtOPMomf+Rm-KM+j-mg3u++bEv1d+fzoGjrrEA@mail.gmail.com>
References: <CAMgWh9uqPCqEqwzp6TvyprN0NGvSJ74SkreyVJEK4YEy+EpGfA@mail.gmail.com>
 <CAMgWh9u=vpNvkwyYtND7brF94EOEEkctdKva5GYtaCLpLbjEvA@mail.gmail.com>
 <CAMgWh9sMsaPA9g2f-2J9FKFHDf+Juf_HDHQy9oZc34nNF=QCJQ@mail.gmail.com>
 <CAMgWh9vZfdo_fKxWWw_s0PTmnGVKqEMQWfaruGkBJB38Lojbtw@mail.gmail.com>
 <CAMgWh9vutqciKs2-U62JLnQUaT7M0uz23inw0ju_xFi+ew92VA@mail.gmail.com>
 <CAMgWh9tr2wG3HT-SY9xtmauHHovVrsCLTo-pBp2+T-9VrhC-ig@mail.gmail.com>
 <CAMgWh9tLi3Gu=8RGWXH9OQLJ6DB=UdM+1MzOvMB_QTFhnQanYg@mail.gmail.com>
 <CAMgWh9veyXkZKSHVKPh6n4-5hy7mhd7n2v53O7h8XYCa7-Q-dQ@mail.gmail.com>
 <CAMgWh9uFVR9kypsEw0oLYmEaQnC8Y1ory7KT18FMRS-fnmE=oQ@mail.gmail.com>
 <CAMgWh9uneS8k1xEM1dYJCmR8cuf8V5s_Ssci21v=PONVJ_t21A@mail.gmail.com>
 <CAMgWh9vsPZbunmEY37rQgvtLjbbspwsrUzNFQYYxco2eyR2J=Q@mail.gmail.com>
 <CAMgWh9u5Jtz30fOrKdd1vXWvOWVkTCaRSahN2R_mMxuxhhc7yA@mail.gmail.com>
 <CAMgWh9uFmuNpNXAXPcj25gOQz66Fud9StT0m8gYrN-tj3Gy4dw@mail.gmail.com>
 <CAMgWh9uYcrNZ17R1H=J8dR=BdqWH7xekt349wFjcTADim3=RVg@mail.gmail.com>
 <CAMgWh9tffEs-3PHWzxhQc2UkL+jyv+wp1=dF4mFEEo2m_m2e2w@mail.gmail.com>
 <CAMgWh9snErv1oEFyv5UhG_JSUfVT3FO1HHA9N2x9AOU7eSW6tA@mail.gmail.com>
 <87vb23vpjj.fsf@smart-cactus.org>
 <CAMgWh9vt89=-qiXntY_fbY9dxCDrgVAwXXhd=UGbymaUA6ogMA@mail.gmail.com>
 <87h9dnv23t.fsf@smart-cactus.org>
 <CAMgWh9s5qrFgkTfTtFtfTzDdEXXm5PJsmmUDfBf2nDKX8-Ky8g@mail.gmail.com>
 <CAHYVw0zLUP5ObmHrGzh6_20n=H-abUkxpObHKz323s7b-SwZhQ@mail.gmail.com>
 <CAMgWh9v5U=u2UtOPMomf+Rm-KM+j-mg3u++bEv1d+fzoGjrrEA@mail.gmail.com>
Message-ID: <2e3117c3f21c452d867dc2919b7aac03@DB4PR30MB030.064d.mgd.msft.net>

I'm not following the details of this discussion.  Would it be possible to write a compact summary, with the key examples, in the appropriate ticket?

I think that https://ghc.haskell.org/trac/ghc/ticket/10016 is one such ticket, but I think there may be more than one issue at stake here.  For example, #10016 can be done in a strongly typed way in Core; but #1965 cannot (so far as I know).

It could also help to have a wiki page to summarise the cluster of issues, pointing to the appropriate tickets for individual cases.

An articulate summary will make it much more likely that progress is made! Thanks.

Simon

| -----Original Message-----
| From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of David Feuer
| Sent: 24 May 2016 23:14
| To: Carter Schonwald <carter.schonwald at gmail.com>
| Cc: ghc-devs <ghc-devs at haskell.org>
| Subject: Re: Unpacking single-field, single-strict-constructor GADTs and
| existentials
| 
| Unboxing, per se, is not required; only newtype optimization. I
| believe Ed would probably have mentioned something when I discussed
| the issue with him if he'd already had an idea for hacking around it.
| Instead, he said he wanted the feature too.
| 
| On Tue, May 24, 2016 at 6:03 PM, Carter Schonwald
| <carter.schonwald at gmail.com> wrote:
| > Phrased differently: there's a subclass of existential data types which
| have
| > a well behaved unboxed memory layout?
| >
| > @ David : have you tried simulating this in userland using eds structs /
| > structures lib?
| >
| > On Tuesday, May 24, 2016, David Feuer <david.feuer at gmail.com> wrote:
| >>
| >> I should mention that while this does not require UNPACKing sum types (or
| >> any of the difficult trade-offs that involves), it lets programmers
| >> accomplish such unpacking by hand under sufficiently general conditions to
| >> be quite useful in practice. As long as the set of types involved is
| closed,
| >> it'll do.
| >>
| >> David Feuer <david.feuer at gmail.com> writes:
| >>
| >> > Given
| >> >
| >> > data Big a = B1 !(Small1 a) | B2 !(Small2 a) | B3 !(Small3 a), where the
| >> > Small types are (possibly recursive) sums, it's generally possible to
| >> > express that as something like
| >> >
| >> > data Selector = One | Two | Three
| >> > data Big a = forall (x :: Selector) .
| >> >    Big !(BigG x a)
| >> > data BigG x a where
| >> >   GB1a :: some -> fields -> BigG 'One a
| >> >   GB1b :: fields -> BigG 'One a
| >> >   GB2a :: whatever -> BigG 'Two a
| >> >   GB3a :: yeah -> BigG 'Three a
| >> >
| >> > Making one big GADT from all the constructors of the "small" types, and
| >> > then wrapping it up in an existential. That's what I meant about
| >> > "unpacking". But for efficiency purposes, that wrapper needs the newtype
| >> > optimization.
| >>
| >> Yes, but you'd need to unbox a sum in this case, no? I think this is the
| >> first issue that you need to solve before you can talk about dealing
| >> with the polymorphism issue (although hopefully ?mer will make progress
| >> on this for 8.2).
| >>
| >> Cheers,
| >>
| >> - Ben
| _______________________________________________
| ghc-devs mailing list
| ghc-devs at haskell.org
| https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.
| org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
| devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7ce98f7b01dbeb47cc8d3908
| d38420b38b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=gFnWAB1of%2fp%2b0IXkD
| CgcBbyxHkS7%2b4BusMl%2fs0rUySM%3d

From david.feuer at gmail.com  Wed May 25 07:39:37 2016
From: david.feuer at gmail.com (David Feuer)
Date: Wed, 25 May 2016 03:39:37 -0400
Subject: Unpacking single-field,
 single-strict-constructor GADTs and existentials
In-Reply-To: <2e3117c3f21c452d867dc2919b7aac03@DB4PR30MB030.064d.mgd.msft.net>
References: <CAMgWh9uqPCqEqwzp6TvyprN0NGvSJ74SkreyVJEK4YEy+EpGfA@mail.gmail.com>
 <CAMgWh9u=vpNvkwyYtND7brF94EOEEkctdKva5GYtaCLpLbjEvA@mail.gmail.com>
 <CAMgWh9sMsaPA9g2f-2J9FKFHDf+Juf_HDHQy9oZc34nNF=QCJQ@mail.gmail.com>
 <CAMgWh9vZfdo_fKxWWw_s0PTmnGVKqEMQWfaruGkBJB38Lojbtw@mail.gmail.com>
 <CAMgWh9vutqciKs2-U62JLnQUaT7M0uz23inw0ju_xFi+ew92VA@mail.gmail.com>
 <CAMgWh9tr2wG3HT-SY9xtmauHHovVrsCLTo-pBp2+T-9VrhC-ig@mail.gmail.com>
 <CAMgWh9tLi3Gu=8RGWXH9OQLJ6DB=UdM+1MzOvMB_QTFhnQanYg@mail.gmail.com>
 <CAMgWh9veyXkZKSHVKPh6n4-5hy7mhd7n2v53O7h8XYCa7-Q-dQ@mail.gmail.com>
 <CAMgWh9uFVR9kypsEw0oLYmEaQnC8Y1ory7KT18FMRS-fnmE=oQ@mail.gmail.com>
 <CAMgWh9uneS8k1xEM1dYJCmR8cuf8V5s_Ssci21v=PONVJ_t21A@mail.gmail.com>
 <CAMgWh9vsPZbunmEY37rQgvtLjbbspwsrUzNFQYYxco2eyR2J=Q@mail.gmail.com>
 <CAMgWh9u5Jtz30fOrKdd1vXWvOWVkTCaRSahN2R_mMxuxhhc7yA@mail.gmail.com>
 <CAMgWh9uFmuNpNXAXPcj25gOQz66Fud9StT0m8gYrN-tj3Gy4dw@mail.gmail.com>
 <CAMgWh9uYcrNZ17R1H=J8dR=BdqWH7xekt349wFjcTADim3=RVg@mail.gmail.com>
 <CAMgWh9tffEs-3PHWzxhQc2UkL+jyv+wp1=dF4mFEEo2m_m2e2w@mail.gmail.com>
 <CAMgWh9snErv1oEFyv5UhG_JSUfVT3FO1HHA9N2x9AOU7eSW6tA@mail.gmail.com>
 <87vb23vpjj.fsf@smart-cactus.org>
 <CAMgWh9vt89=-qiXntY_fbY9dxCDrgVAwXXhd=UGbymaUA6ogMA@mail.gmail.com>
 <87h9dnv23t.fsf@smart-cactus.org>
 <CAMgWh9s5qrFgkTfTtFtfTzDdEXXm5PJsmmUDfBf2nDKX8-Ky8g@mail.gmail.com>
 <CAHYVw0zLUP5ObmHrGzh6_20n=H-abUkxpObHKz323s7b-SwZhQ@mail.gmail.com>
 <CAMgWh9v5U=u2UtOPMomf+Rm-KM+j-mg3u++bEv1d+fzoGjrrEA@mail.gmail.com>
 <2e3117c3f21c452d867dc2919b7aac03@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <CAMgWh9vZ8AAbOu_drU5-Kv7KKNmO_iKeYN9fDFJSmmSmkg3jvw@mail.gmail.com>

#1965 *as modified by comments #7 and #9* is pretty much what I'm hoping for.

On Wed, May 25, 2016 at 3:27 AM, Simon Peyton Jones
<simonpj at microsoft.com> wrote:
> I'm not following the details of this discussion.  Would it be possible to write a compact summary, with the key examples, in the appropriate ticket?
>
> I think that https://ghc.haskell.org/trac/ghc/ticket/10016 is one such ticket, but I think there may be more than one issue at stake here.  For example, #10016 can be done in a strongly typed way in Core; but #1965 cannot (so far as I know).
>
> It could also help to have a wiki page to summarise the cluster of issues, pointing to the appropriate tickets for individual cases.
>
> An articulate summary will make it much more likely that progress is made! Thanks.
>
> Simon
>
> | -----Original Message-----
> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of David Feuer
> | Sent: 24 May 2016 23:14
> | To: Carter Schonwald <carter.schonwald at gmail.com>
> | Cc: ghc-devs <ghc-devs at haskell.org>
> | Subject: Re: Unpacking single-field, single-strict-constructor GADTs and
> | existentials
> |
> | Unboxing, per se, is not required; only newtype optimization. I
> | believe Ed would probably have mentioned something when I discussed
> | the issue with him if he'd already had an idea for hacking around it.
> | Instead, he said he wanted the feature too.
> |
> | On Tue, May 24, 2016 at 6:03 PM, Carter Schonwald
> | <carter.schonwald at gmail.com> wrote:
> | > Phrased differently: there's a subclass of existential data types which
> | have
> | > a well behaved unboxed memory layout?
> | >
> | > @ David : have you tried simulating this in userland using eds structs /
> | > structures lib?
> | >
> | > On Tuesday, May 24, 2016, David Feuer <david.feuer at gmail.com> wrote:
> | >>
> | >> I should mention that while this does not require UNPACKing sum types (or
> | >> any of the difficult trade-offs that involves), it lets programmers
> | >> accomplish such unpacking by hand under sufficiently general conditions to
> | >> be quite useful in practice. As long as the set of types involved is
> | closed,
> | >> it'll do.
> | >>
> | >> David Feuer <david.feuer at gmail.com> writes:
> | >>
> | >> > Given
> | >> >
> | >> > data Big a = B1 !(Small1 a) | B2 !(Small2 a) | B3 !(Small3 a), where the
> | >> > Small types are (possibly recursive) sums, it's generally possible to
> | >> > express that as something like
> | >> >
> | >> > data Selector = One | Two | Three
> | >> > data Big a = forall (x :: Selector) .
> | >> >    Big !(BigG x a)
> | >> > data BigG x a where
> | >> >   GB1a :: some -> fields -> BigG 'One a
> | >> >   GB1b :: fields -> BigG 'One a
> | >> >   GB2a :: whatever -> BigG 'Two a
> | >> >   GB3a :: yeah -> BigG 'Three a
> | >> >
> | >> > Making one big GADT from all the constructors of the "small" types, and
> | >> > then wrapping it up in an existential. That's what I meant about
> | >> > "unpacking". But for efficiency purposes, that wrapper needs the newtype
> | >> > optimization.
> | >>
> | >> Yes, but you'd need to unbox a sum in this case, no? I think this is the
> | >> first issue that you need to solve before you can talk about dealing
> | >> with the polymorphism issue (although hopefully ?mer will make progress
> | >> on this for 8.2).
> | >>
> | >> Cheers,
> | >>
> | >> - Ben
> | _______________________________________________
> | ghc-devs mailing list
> | ghc-devs at haskell.org
> | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.
> | org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
> | devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7ce98f7b01dbeb47cc8d3908
> | d38420b38b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=gFnWAB1of%2fp%2b0IXkD
> | CgcBbyxHkS7%2b4BusMl%2fs0rUySM%3d

From david.feuer at gmail.com  Wed May 25 08:00:45 2016
From: david.feuer at gmail.com (David Feuer)
Date: Wed, 25 May 2016 04:00:45 -0400
Subject: Unpacking single-field,
 single-strict-constructor GADTs and existentials
In-Reply-To: <2e3117c3f21c452d867dc2919b7aac03@DB4PR30MB030.064d.mgd.msft.net>
References: <CAMgWh9uqPCqEqwzp6TvyprN0NGvSJ74SkreyVJEK4YEy+EpGfA@mail.gmail.com>
 <CAMgWh9u=vpNvkwyYtND7brF94EOEEkctdKva5GYtaCLpLbjEvA@mail.gmail.com>
 <CAMgWh9sMsaPA9g2f-2J9FKFHDf+Juf_HDHQy9oZc34nNF=QCJQ@mail.gmail.com>
 <CAMgWh9vZfdo_fKxWWw_s0PTmnGVKqEMQWfaruGkBJB38Lojbtw@mail.gmail.com>
 <CAMgWh9vutqciKs2-U62JLnQUaT7M0uz23inw0ju_xFi+ew92VA@mail.gmail.com>
 <CAMgWh9tr2wG3HT-SY9xtmauHHovVrsCLTo-pBp2+T-9VrhC-ig@mail.gmail.com>
 <CAMgWh9tLi3Gu=8RGWXH9OQLJ6DB=UdM+1MzOvMB_QTFhnQanYg@mail.gmail.com>
 <CAMgWh9veyXkZKSHVKPh6n4-5hy7mhd7n2v53O7h8XYCa7-Q-dQ@mail.gmail.com>
 <CAMgWh9uFVR9kypsEw0oLYmEaQnC8Y1ory7KT18FMRS-fnmE=oQ@mail.gmail.com>
 <CAMgWh9uneS8k1xEM1dYJCmR8cuf8V5s_Ssci21v=PONVJ_t21A@mail.gmail.com>
 <CAMgWh9vsPZbunmEY37rQgvtLjbbspwsrUzNFQYYxco2eyR2J=Q@mail.gmail.com>
 <CAMgWh9u5Jtz30fOrKdd1vXWvOWVkTCaRSahN2R_mMxuxhhc7yA@mail.gmail.com>
 <CAMgWh9uFmuNpNXAXPcj25gOQz66Fud9StT0m8gYrN-tj3Gy4dw@mail.gmail.com>
 <CAMgWh9uYcrNZ17R1H=J8dR=BdqWH7xekt349wFjcTADim3=RVg@mail.gmail.com>
 <CAMgWh9tffEs-3PHWzxhQc2UkL+jyv+wp1=dF4mFEEo2m_m2e2w@mail.gmail.com>
 <CAMgWh9snErv1oEFyv5UhG_JSUfVT3FO1HHA9N2x9AOU7eSW6tA@mail.gmail.com>
 <87vb23vpjj.fsf@smart-cactus.org>
 <CAMgWh9vt89=-qiXntY_fbY9dxCDrgVAwXXhd=UGbymaUA6ogMA@mail.gmail.com>
 <87h9dnv23t.fsf@smart-cactus.org>
 <CAMgWh9s5qrFgkTfTtFtfTzDdEXXm5PJsmmUDfBf2nDKX8-Ky8g@mail.gmail.com>
 <CAHYVw0zLUP5ObmHrGzh6_20n=H-abUkxpObHKz323s7b-SwZhQ@mail.gmail.com>
 <CAMgWh9v5U=u2UtOPMomf+Rm-KM+j-mg3u++bEv1d+fzoGjrrEA@mail.gmail.com>
 <2e3117c3f21c452d867dc2919b7aac03@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <CAMgWh9uaxtrmPLHJw7eErxfy9OZBkONR1zrzVhoN1gqVRdKiyw@mail.gmail.com>

I've started a wiki page at
https://ghc.haskell.org/trac/ghc/wiki/NewtypeOptimizationForGADTS

On Wed, May 25, 2016 at 3:27 AM, Simon Peyton Jones
<simonpj at microsoft.com> wrote:
> I'm not following the details of this discussion.  Would it be possible to write a compact summary, with the key examples, in the appropriate ticket?
>
> I think that https://ghc.haskell.org/trac/ghc/ticket/10016 is one such ticket, but I think there may be more than one issue at stake here.  For example, #10016 can be done in a strongly typed way in Core; but #1965 cannot (so far as I know).
>
> It could also help to have a wiki page to summarise the cluster of issues, pointing to the appropriate tickets for individual cases.
>
> An articulate summary will make it much more likely that progress is made! Thanks.
>
> Simon
>
> | -----Original Message-----
> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of David Feuer
> | Sent: 24 May 2016 23:14
> | To: Carter Schonwald <carter.schonwald at gmail.com>
> | Cc: ghc-devs <ghc-devs at haskell.org>
> | Subject: Re: Unpacking single-field, single-strict-constructor GADTs and
> | existentials
> |
> | Unboxing, per se, is not required; only newtype optimization. I
> | believe Ed would probably have mentioned something when I discussed
> | the issue with him if he'd already had an idea for hacking around it.
> | Instead, he said he wanted the feature too.
> |
> | On Tue, May 24, 2016 at 6:03 PM, Carter Schonwald
> | <carter.schonwald at gmail.com> wrote:
> | > Phrased differently: there's a subclass of existential data types which
> | have
> | > a well behaved unboxed memory layout?
> | >
> | > @ David : have you tried simulating this in userland using eds structs /
> | > structures lib?
> | >
> | > On Tuesday, May 24, 2016, David Feuer <david.feuer at gmail.com> wrote:
> | >>
> | >> I should mention that while this does not require UNPACKing sum types (or
> | >> any of the difficult trade-offs that involves), it lets programmers
> | >> accomplish such unpacking by hand under sufficiently general conditions to
> | >> be quite useful in practice. As long as the set of types involved is
> | closed,
> | >> it'll do.
> | >>
> | >> David Feuer <david.feuer at gmail.com> writes:
> | >>
> | >> > Given
> | >> >
> | >> > data Big a = B1 !(Small1 a) | B2 !(Small2 a) | B3 !(Small3 a), where the
> | >> > Small types are (possibly recursive) sums, it's generally possible to
> | >> > express that as something like
> | >> >
> | >> > data Selector = One | Two | Three
> | >> > data Big a = forall (x :: Selector) .
> | >> >    Big !(BigG x a)
> | >> > data BigG x a where
> | >> >   GB1a :: some -> fields -> BigG 'One a
> | >> >   GB1b :: fields -> BigG 'One a
> | >> >   GB2a :: whatever -> BigG 'Two a
> | >> >   GB3a :: yeah -> BigG 'Three a
> | >> >
> | >> > Making one big GADT from all the constructors of the "small" types, and
> | >> > then wrapping it up in an existential. That's what I meant about
> | >> > "unpacking". But for efficiency purposes, that wrapper needs the newtype
> | >> > optimization.
> | >>
> | >> Yes, but you'd need to unbox a sum in this case, no? I think this is the
> | >> first issue that you need to solve before you can talk about dealing
> | >> with the polymorphism issue (although hopefully ?mer will make progress
> | >> on this for 8.2).
> | >>
> | >> Cheers,
> | >>
> | >> - Ben
> | _______________________________________________
> | ghc-devs mailing list
> | ghc-devs at haskell.org
> | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.
> | org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
> | devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7ce98f7b01dbeb47cc8d3908
> | d38420b38b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=gFnWAB1of%2fp%2b0IXkD
> | CgcBbyxHkS7%2b4BusMl%2fs0rUySM%3d

From simonpj at microsoft.com  Wed May 25 08:22:37 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 25 May 2016 08:22:37 +0000
Subject: Unpacking single-field, single-strict-constructor GADTs and
 existentials
In-Reply-To: <CAMgWh9vZ8AAbOu_drU5-Kv7KKNmO_iKeYN9fDFJSmmSmkg3jvw@mail.gmail.com>
References: <CAMgWh9uqPCqEqwzp6TvyprN0NGvSJ74SkreyVJEK4YEy+EpGfA@mail.gmail.com>
 <CAMgWh9u=vpNvkwyYtND7brF94EOEEkctdKva5GYtaCLpLbjEvA@mail.gmail.com>
 <CAMgWh9sMsaPA9g2f-2J9FKFHDf+Juf_HDHQy9oZc34nNF=QCJQ@mail.gmail.com>
 <CAMgWh9vZfdo_fKxWWw_s0PTmnGVKqEMQWfaruGkBJB38Lojbtw@mail.gmail.com>
 <CAMgWh9vutqciKs2-U62JLnQUaT7M0uz23inw0ju_xFi+ew92VA@mail.gmail.com>
 <CAMgWh9tr2wG3HT-SY9xtmauHHovVrsCLTo-pBp2+T-9VrhC-ig@mail.gmail.com>
 <CAMgWh9tLi3Gu=8RGWXH9OQLJ6DB=UdM+1MzOvMB_QTFhnQanYg@mail.gmail.com>
 <CAMgWh9veyXkZKSHVKPh6n4-5hy7mhd7n2v53O7h8XYCa7-Q-dQ@mail.gmail.com>
 <CAMgWh9uFVR9kypsEw0oLYmEaQnC8Y1ory7KT18FMRS-fnmE=oQ@mail.gmail.com>
 <CAMgWh9uneS8k1xEM1dYJCmR8cuf8V5s_Ssci21v=PONVJ_t21A@mail.gmail.com>
 <CAMgWh9vsPZbunmEY37rQgvtLjbbspwsrUzNFQYYxco2eyR2J=Q@mail.gmail.com>
 <CAMgWh9u5Jtz30fOrKdd1vXWvOWVkTCaRSahN2R_mMxuxhhc7yA@mail.gmail.com>
 <CAMgWh9uFmuNpNXAXPcj25gOQz66Fud9StT0m8gYrN-tj3Gy4dw@mail.gmail.com>
 <CAMgWh9uYcrNZ17R1H=J8dR=BdqWH7xekt349wFjcTADim3=RVg@mail.gmail.com>
 <CAMgWh9tffEs-3PHWzxhQc2UkL+jyv+wp1=dF4mFEEo2m_m2e2w@mail.gmail.com>
 <CAMgWh9snErv1oEFyv5UhG_JSUfVT3FO1HHA9N2x9AOU7eSW6tA@mail.gmail.com>
 <87vb23vpjj.fsf@smart-cactus.org>
 <CAMgWh9vt89=-qiXntY_fbY9dxCDrgVAwXXhd=UGbymaUA6ogMA@mail.gmail.com>
 <87h9dnv23t.fsf@smart-cactus.org>
 <CAMgWh9s5qrFgkTfTtFtfTzDdEXXm5PJsmmUDfBf2nDKX8-Ky8g@mail.gmail.com>
 <CAHYVw0zLUP5ObmHrGzh6_20n=H-abUkxpObHKz323s7b-SwZhQ@mail.gmail.com>
 <CAMgWh9v5U=u2UtOPMomf+Rm-KM+j-mg3u++bEv1d+fzoGjrrEA@mail.gmail.com>
 <2e3117c3f21c452d867dc2919b7aac03@DB4PR30MB030.064d.mgd.msft.net>
 <CAMgWh9vZ8AAbOu_drU5-Kv7KKNmO_iKeYN9fDFJSmmSmkg3jvw@mail.gmail.com>
Message-ID: <69d30195f7ae4ad7bdfceb44a712087d@DB4PR30MB030.064d.mgd.msft.net>

OK, so nothing new in the email thread?  Is it worth adding any of the examples to the ticket? 

|  -----Original Message-----
|  From: David Feuer [mailto:david.feuer at gmail.com]
|  Sent: 25 May 2016 08:40
|  To: Simon Peyton Jones <simonpj at microsoft.com>
|  Cc: Carter Schonwald <carter.schonwald at gmail.com>; ghc-devs <ghc-
|  devs at haskell.org>
|  Subject: Re: Unpacking single-field, single-strict-constructor GADTs
|  and existentials
|  
|  #1965 *as modified by comments #7 and #9* is pretty much what I'm
|  hoping for.
|  
|  On Wed, May 25, 2016 at 3:27 AM, Simon Peyton Jones
|  <simonpj at microsoft.com> wrote:
|  > I'm not following the details of this discussion.  Would it be
|  possible to write a compact summary, with the key examples, in the
|  appropriate ticket?
|  >
|  > I think that https://ghc.haskell.org/trac/ghc/ticket/10016 is one
|  such ticket, but I think there may be more than one issue at stake
|  here.  For example, #10016 can be done in a strongly typed way in
|  Core; but #1965 cannot (so far as I know).
|  >
|  > It could also help to have a wiki page to summarise the cluster of
|  issues, pointing to the appropriate tickets for individual cases.
|  >
|  > An articulate summary will make it much more likely that progress is
|  made! Thanks.
|  >
|  > Simon
|  >
|  > | -----Original Message-----
|  > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
|  > | David Feuer
|  > | Sent: 24 May 2016 23:14
|  > | To: Carter Schonwald <carter.schonwald at gmail.com>
|  > | Cc: ghc-devs <ghc-devs at haskell.org>
|  > | Subject: Re: Unpacking single-field, single-strict-constructor
|  GADTs
|  > | and existentials
|  > |
|  > | Unboxing, per se, is not required; only newtype optimization. I
|  > | believe Ed would probably have mentioned something when I
|  discussed
|  > | the issue with him if he'd already had an idea for hacking around
|  it.
|  > | Instead, he said he wanted the feature too.
|  > |
|  > | On Tue, May 24, 2016 at 6:03 PM, Carter Schonwald
|  > | <carter.schonwald at gmail.com> wrote:
|  > | > Phrased differently: there's a subclass of existential data
|  types
|  > | > which
|  > | have
|  > | > a well behaved unboxed memory layout?
|  > | >
|  > | > @ David : have you tried simulating this in userland using eds
|  > | > structs / structures lib?
|  > | >
|  > | > On Tuesday, May 24, 2016, David Feuer <david.feuer at gmail.com>
|  wrote:
|  > | >>
|  > | >> I should mention that while this does not require UNPACKing sum
|  > | >> types (or any of the difficult trade-offs that involves), it
|  lets
|  > | >> programmers accomplish such unpacking by hand under
|  sufficiently
|  > | >> general conditions to be quite useful in practice. As long as
|  the
|  > | >> set of types involved is
|  > | closed,
|  > | >> it'll do.
|  > | >>
|  > | >> David Feuer <david.feuer at gmail.com> writes:
|  > | >>
|  > | >> > Given
|  > | >> >
|  > | >> > data Big a = B1 !(Small1 a) | B2 !(Small2 a) | B3 !(Small3
|  a),
|  > | >> > where the Small types are (possibly recursive) sums, it's
|  > | >> > generally possible to express that as something like
|  > | >> >
|  > | >> > data Selector = One | Two | Three data Big a = forall (x ::
|  > | >> > Selector) .
|  > | >> >    Big !(BigG x a)
|  > | >> > data BigG x a where
|  > | >> >   GB1a :: some -> fields -> BigG 'One a
|  > | >> >   GB1b :: fields -> BigG 'One a
|  > | >> >   GB2a :: whatever -> BigG 'Two a
|  > | >> >   GB3a :: yeah -> BigG 'Three a
|  > | >> >
|  > | >> > Making one big GADT from all the constructors of the "small"
|  > | >> > types, and then wrapping it up in an existential. That's what
|  I
|  > | >> > meant about "unpacking". But for efficiency purposes, that
|  > | >> > wrapper needs the newtype optimization.
|  > | >>
|  > | >> Yes, but you'd need to unbox a sum in this case, no? I think
|  this
|  > | >> is the first issue that you need to solve before you can talk
|  > | >> about dealing with the polymorphism issue (although hopefully
|  > | >> ?mer will make progress on this for 8.2).
|  > | >>
|  > | >> Cheers,
|  > | >>
|  > | >> - Ben
|  > | _______________________________________________
|  > | ghc-devs mailing list
|  > | ghc-devs at haskell.org
|  > |
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h
|  askell.
|  > | org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
|  > |
|  devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7ce98f7b01dbeb4
|  > | 7cc8d3908
|  > |
|  d38420b38b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=gFnWAB1of%2f
|  > | p%2b0IXkD
|  > | CgcBbyxHkS7%2b4BusMl%2fs0rUySM%3d

From simonpj at microsoft.com  Wed May 25 08:47:10 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 25 May 2016 08:47:10 +0000
Subject: Unpacking single-field, single-strict-constructor GADTs and
 existentials
In-Reply-To: <CAMgWh9uaxtrmPLHJw7eErxfy9OZBkONR1zrzVhoN1gqVRdKiyw@mail.gmail.com>
References: <CAMgWh9uqPCqEqwzp6TvyprN0NGvSJ74SkreyVJEK4YEy+EpGfA@mail.gmail.com>
 <CAMgWh9u=vpNvkwyYtND7brF94EOEEkctdKva5GYtaCLpLbjEvA@mail.gmail.com>
 <CAMgWh9sMsaPA9g2f-2J9FKFHDf+Juf_HDHQy9oZc34nNF=QCJQ@mail.gmail.com>
 <CAMgWh9vZfdo_fKxWWw_s0PTmnGVKqEMQWfaruGkBJB38Lojbtw@mail.gmail.com>
 <CAMgWh9vutqciKs2-U62JLnQUaT7M0uz23inw0ju_xFi+ew92VA@mail.gmail.com>
 <CAMgWh9tr2wG3HT-SY9xtmauHHovVrsCLTo-pBp2+T-9VrhC-ig@mail.gmail.com>
 <CAMgWh9tLi3Gu=8RGWXH9OQLJ6DB=UdM+1MzOvMB_QTFhnQanYg@mail.gmail.com>
 <CAMgWh9veyXkZKSHVKPh6n4-5hy7mhd7n2v53O7h8XYCa7-Q-dQ@mail.gmail.com>
 <CAMgWh9uFVR9kypsEw0oLYmEaQnC8Y1ory7KT18FMRS-fnmE=oQ@mail.gmail.com>
 <CAMgWh9uneS8k1xEM1dYJCmR8cuf8V5s_Ssci21v=PONVJ_t21A@mail.gmail.com>
 <CAMgWh9vsPZbunmEY37rQgvtLjbbspwsrUzNFQYYxco2eyR2J=Q@mail.gmail.com>
 <CAMgWh9u5Jtz30fOrKdd1vXWvOWVkTCaRSahN2R_mMxuxhhc7yA@mail.gmail.com>
 <CAMgWh9uFmuNpNXAXPcj25gOQz66Fud9StT0m8gYrN-tj3Gy4dw@mail.gmail.com>
 <CAMgWh9uYcrNZ17R1H=J8dR=BdqWH7xekt349wFjcTADim3=RVg@mail.gmail.com>
 <CAMgWh9tffEs-3PHWzxhQc2UkL+jyv+wp1=dF4mFEEo2m_m2e2w@mail.gmail.com>
 <CAMgWh9snErv1oEFyv5UhG_JSUfVT3FO1HHA9N2x9AOU7eSW6tA@mail.gmail.com>
 <87vb23vpjj.fsf@smart-cactus.org>
 <CAMgWh9vt89=-qiXntY_fbY9dxCDrgVAwXXhd=UGbymaUA6ogMA@mail.gmail.com>
 <87h9dnv23t.fsf@smart-cactus.org>
 <CAMgWh9s5qrFgkTfTtFtfTzDdEXXm5PJsmmUDfBf2nDKX8-Ky8g@mail.gmail.com>
 <CAHYVw0zLUP5ObmHrGzh6_20n=H-abUkxpObHKz323s7b-SwZhQ@mail.gmail.com>
 <CAMgWh9v5U=u2UtOPMomf+Rm-KM+j-mg3u++bEv1d+fzoGjrrEA@mail.gmail.com>
 <2e3117c3f21c452d867dc2919b7aac03@DB4PR30MB030.064d.mgd.msft.net>
 <CAMgWh9uaxtrmPLHJw7eErxfy9OZBkONR1zrzVhoN1gqVRdKiyw@mail.gmail.com>
Message-ID: <18dc87c3550a4f2fade4bc668718ec1f@DB4PR30MB030.064d.mgd.msft.net>

Oh, that's helpful thank you.  I have added comments!

SImon

|  -----Original Message-----
|  From: David Feuer [mailto:david.feuer at gmail.com]
|  Sent: 25 May 2016 09:01
|  To: Simon Peyton Jones <simonpj at microsoft.com>
|  Cc: Carter Schonwald <carter.schonwald at gmail.com>; ghc-devs <ghc-
|  devs at haskell.org>
|  Subject: Re: Unpacking single-field, single-strict-constructor GADTs
|  and existentials
|  
|  I've started a wiki page at
|  https://ghc.haskell.org/trac/ghc/wiki/NewtypeOptimizationForGADTS
|  
|  On Wed, May 25, 2016 at 3:27 AM, Simon Peyton Jones
|  <simonpj at microsoft.com> wrote:
|  > I'm not following the details of this discussion.  Would it be
|  possible to write a compact summary, with the key examples, in the
|  appropriate ticket?
|  >
|  > I think that https://ghc.haskell.org/trac/ghc/ticket/10016 is one
|  such ticket, but I think there may be more than one issue at stake
|  here.  For example, #10016 can be done in a strongly typed way in
|  Core; but #1965 cannot (so far as I know).
|  >
|  > It could also help to have a wiki page to summarise the cluster of
|  issues, pointing to the appropriate tickets for individual cases.
|  >
|  > An articulate summary will make it much more likely that progress is
|  made! Thanks.
|  >
|  > Simon
|  >
|  > | -----Original Message-----
|  > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
|  > | David Feuer
|  > | Sent: 24 May 2016 23:14
|  > | To: Carter Schonwald <carter.schonwald at gmail.com>
|  > | Cc: ghc-devs <ghc-devs at haskell.org>
|  > | Subject: Re: Unpacking single-field, single-strict-constructor
|  GADTs
|  > | and existentials
|  > |
|  > | Unboxing, per se, is not required; only newtype optimization. I
|  > | believe Ed would probably have mentioned something when I
|  discussed
|  > | the issue with him if he'd already had an idea for hacking around
|  it.
|  > | Instead, he said he wanted the feature too.
|  > |
|  > | On Tue, May 24, 2016 at 6:03 PM, Carter Schonwald
|  > | <carter.schonwald at gmail.com> wrote:
|  > | > Phrased differently: there's a subclass of existential data
|  types
|  > | > which
|  > | have
|  > | > a well behaved unboxed memory layout?
|  > | >
|  > | > @ David : have you tried simulating this in userland using eds
|  > | > structs / structures lib?
|  > | >
|  > | > On Tuesday, May 24, 2016, David Feuer <david.feuer at gmail.com>
|  wrote:
|  > | >>
|  > | >> I should mention that while this does not require UNPACKing sum
|  > | >> types (or any of the difficult trade-offs that involves), it
|  lets
|  > | >> programmers accomplish such unpacking by hand under
|  sufficiently
|  > | >> general conditions to be quite useful in practice. As long as
|  the
|  > | >> set of types involved is
|  > | closed,
|  > | >> it'll do.
|  > | >>
|  > | >> David Feuer <david.feuer at gmail.com> writes:
|  > | >>
|  > | >> > Given
|  > | >> >
|  > | >> > data Big a = B1 !(Small1 a) | B2 !(Small2 a) | B3 !(Small3
|  a),
|  > | >> > where the Small types are (possibly recursive) sums, it's
|  > | >> > generally possible to express that as something like
|  > | >> >
|  > | >> > data Selector = One | Two | Three data Big a = forall (x ::
|  > | >> > Selector) .
|  > | >> >    Big !(BigG x a)
|  > | >> > data BigG x a where
|  > | >> >   GB1a :: some -> fields -> BigG 'One a
|  > | >> >   GB1b :: fields -> BigG 'One a
|  > | >> >   GB2a :: whatever -> BigG 'Two a
|  > | >> >   GB3a :: yeah -> BigG 'Three a
|  > | >> >
|  > | >> > Making one big GADT from all the constructors of the "small"
|  > | >> > types, and then wrapping it up in an existential. That's what
|  I
|  > | >> > meant about "unpacking". But for efficiency purposes, that
|  > | >> > wrapper needs the newtype optimization.
|  > | >>
|  > | >> Yes, but you'd need to unbox a sum in this case, no? I think
|  this
|  > | >> is the first issue that you need to solve before you can talk
|  > | >> about dealing with the polymorphism issue (although hopefully
|  > | >> ?mer will make progress on this for 8.2).
|  > | >>
|  > | >> Cheers,
|  > | >>
|  > | >> - Ben
|  > | _______________________________________________
|  > | ghc-devs mailing list
|  > | ghc-devs at haskell.org
|  > |
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h
|  askell.
|  > | org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
|  > |
|  devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7ce98f7b01dbeb4
|  > | 7cc8d3908
|  > |
|  d38420b38b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=gFnWAB1of%2f
|  > | p%2b0IXkD
|  > | CgcBbyxHkS7%2b4BusMl%2fs0rUySM%3d

From alan.zimm at gmail.com  Wed May 25 17:38:30 2016
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Wed, 25 May 2016 19:38:30 +0200
Subject: instances for closed type families
Message-ID: <CANma=H94qoDw5Euqh90Nxu3DTGV7sWQ3s4fM0U-C5pT9_QSHZA@mail.gmail.com>

I am working on https://ghc.haskell.org/trac/ghc/ticket/12105, and have a
type to ensure that the `HsMatchContext` has either a `RdrName` or a
`Name`, not an `Id`.

type family NameOrRdrName id where
  NameOrRdrName Id      = Name
  NameOrRdrName Name    = Name
  NameOrRdrName RdrName = RdrName

Is there any way to declare `Data` and `OutputableBndr` instances for this?

Without it I am having to do something like

instance (OutputableBndr name, OutputableBndr (NameOrRdrName name))
         => Outputable (HsDecl name) where

which requires UndecidableInstances.

I get

compiler/hsSyn/PlaceHolder.hs:114:19:
    Illegal type synonym family application in instance:
      NameOrRdrName id
    In the stand-alone deriving instance for ?Data (NameOrRdrName id)?

for the parameterised version and

compiler/hsSyn/PlaceHolder.hs:115:19:
    Illegal type synonym family application in instance:
      NameOrRdrName RdrName
    In the stand-alone deriving instance for
      ?Data (NameOrRdrName RdrName)?

for the one specific to `RdrName`.

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

From simonpj at microsoft.com  Wed May 25 18:03:49 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 25 May 2016 18:03:49 +0000
Subject: instances for closed type families
In-Reply-To: <CANma=H94qoDw5Euqh90Nxu3DTGV7sWQ3s4fM0U-C5pT9_QSHZA@mail.gmail.com>
References: <CANma=H94qoDw5Euqh90Nxu3DTGV7sWQ3s4fM0U-C5pT9_QSHZA@mail.gmail.com>
Message-ID: <596cfc2639984629979128b0653bcbde@DB4PR30MB030.064d.mgd.msft.net>

Can you give a small example? Certainly any instance like
                instance Data x => Data (F x)
is not allowed, of course, if F is a type function. It?s like not allowing

f (g x) = x

in the term language.  Only constructors in patterns!

S

From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Alan & Kim Zimmerman
Sent: 25 May 2016 18:39
To: ghc-devs at haskell.org
Subject: instances for closed type families

I am working on https://ghc.haskell.org/trac/ghc/ticket/12105, and have a type to ensure that the `HsMatchContext` has either a `RdrName` or a `Name`, not an `Id`.

type family NameOrRdrName id where
  NameOrRdrName Id      = Name
  NameOrRdrName Name    = Name
  NameOrRdrName RdrName = RdrName
Is there any way to declare `Data` and `OutputableBndr` instances for this?
Without it I am having to do something like

instance (OutputableBndr name, OutputableBndr (NameOrRdrName name))
         => Outputable (HsDecl name) where
which requires UndecidableInstances.
I get

compiler/hsSyn/PlaceHolder.hs:114:19:
    Illegal type synonym family application in instance:
      NameOrRdrName id
    In the stand-alone deriving instance for ?Data (NameOrRdrName id)?
for the parameterised version and

compiler/hsSyn/PlaceHolder.hs:115:19:
    Illegal type synonym family application in instance:
      NameOrRdrName RdrName
    In the stand-alone deriving instance for
      ?Data (NameOrRdrName RdrName)?
for the one specific to `RdrName`.
Regards
  Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160525/d675e551/attachment.html>

From alan.zimm at gmail.com  Wed May 25 18:25:13 2016
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Wed, 25 May 2016 20:25:13 +0200
Subject: instances for closed type families
In-Reply-To: <596cfc2639984629979128b0653bcbde@DB4PR30MB030.064d.mgd.msft.net>
References: <CANma=H94qoDw5Euqh90Nxu3DTGV7sWQ3s4fM0U-C5pT9_QSHZA@mail.gmail.com>
 <596cfc2639984629979128b0653bcbde@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <CANma=H_5tH9pF7YkGH1PhDAh=b3P_-MvxygJsgK_iz5JJ7PFMg@mail.gmail.com>

There is an example at http://lpaste.net/164532 (attached as well)

The derived Data instance fails with

/home/alanz/Example.hs:19:19:
    Illegal type synonym family application in instance:
      NameOrRdrName id
    In the stand-alone deriving instance for ?Data (NameOrRdrName id)?

And how would an instance for Outputable be defined in terms of the
existing ones?

Alan


On Wed, May 25, 2016 at 8:03 PM, Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> Can you give a small example? Certainly any instance like
>
>                 instance Data x => Data (F x)
>
> is not allowed, of course, if F is a type function. It?s like not allowing
>
>
>
> f (g x) = x
>
>
>
> in the term language.  Only constructors in patterns!
>
>
> S
>
>
>
> *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Alan
> & Kim Zimmerman
> *Sent:* 25 May 2016 18:39
> *To:* ghc-devs at haskell.org
> *Subject:* instances for closed type families
>
>
>
> I am working on https://ghc.haskell.org/trac/ghc/ticket/12105, and have a
> type to ensure that the `HsMatchContext` has either a `RdrName` or a
> `Name`, not an `Id`.
>
> type family NameOrRdrName id where
>   NameOrRdrName Id      = Name
>   NameOrRdrName Name    = Name
>   NameOrRdrName RdrName = RdrName
>
> Is there any way to declare `Data` and `OutputableBndr` instances for this?
>
> Without it I am having to do something like
>
> instance (OutputableBndr name, OutputableBndr (NameOrRdrName name))
>          => Outputable (HsDecl name) where
>
> which requires UndecidableInstances.
>
> I get
>
> compiler/hsSyn/PlaceHolder.hs:114:19:
>     Illegal type synonym family application in instance:
>       NameOrRdrName id
>     In the stand-alone deriving instance for ?Data (NameOrRdrName id)?
>
> for the parameterised version and
>
> compiler/hsSyn/PlaceHolder.hs:115:19:
>     Illegal type synonym family application in instance:
>       NameOrRdrName RdrName
>     In the stand-alone deriving instance for
>       ?Data (NameOrRdrName RdrName)?
>
> for the one specific to `RdrName`.
>
> Regards
>
>   Alan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160525/3f05f826/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Example.hs
Type: text/x-haskell
Size: 733 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160525/3f05f826/attachment-0001.hs>

From omeragacan at gmail.com  Wed May 25 18:27:57 2016
From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=)
Date: Wed, 25 May 2016 14:27:57 -0400
Subject: will close some of the cost-center tickets - how to compare .perf
 outputs?
Message-ID: <CAMQQO3n3r8q9z-q0=dvOD2fqUg=M-dZ0SVzVSbztOrbtOwUbBQ@mail.gmail.com>

I'm trying to write some tests for some profiling-related tickets and
I don't understand how do I compare .prof outputs. Can anyone help?

I tried generating a .prof.sample and it worked, but somehow if I
delete a random line from .prof.sample, my test still succeeds! If I
delete the whole file or keep the file but delete the contents, it
fails. I have no idea what's going on. Any ideas?

Thanks

From ryan.gl.scott at gmail.com  Wed May 25 18:42:42 2016
From: ryan.gl.scott at gmail.com (Ryan Scott)
Date: Wed, 25 May 2016 14:42:42 -0400
Subject: instances for closed type families
Message-ID: <CADdQpRA5MymiiEVH=+iBi5KpWX=3fYsvh-XMN0fOWS7PWJL5Qg@mail.gmail.com>

Simon is right, you cannot use a type family as an instance head. But why
do you need to? Typically, if you're deriving a Data instance that involves
type families, the type families would be inside another data type. A
real-world example is HsBindLR [1]:

    data HsBindLR idL idR
      = FunBind {
          ...
          bind_fvs :: PostRn idL NameSet,
          ...
        } | ...

where PostRn is a type family [2]. Now, you can't simply derive Data for
HsBindLR, because GHC has no way of knowing what PostRn will evaluate to!
But you can use standalone deriving to get what you want:

    deriving instance (Data (PostRn idL NameSet), ...) => Data (HsBindLR
idL idR)

And in fact, this is what GHC does [3], using a convenient type synonyms
for the long, sprawling context you need [4].

So in your example, while you can't directly create a Data instance for
NameOrRdrName itself, you can quite easily create Data instances for
anything that might use NameOrRdrName. Does that work for your use cases?

Ryan S.
-----
[1]
http://git.haskell.org/ghc.git/blob/bdc555885b8898684549eca70053c9ce0ec7fa39:/compiler/hsSyn/HsBinds.hs#l111
[2]
http://git.haskell.org/ghc.git/blob/bdc555885b8898684549eca70053c9ce0ec7fa39:/compiler/hsSyn/PlaceHolder.hs#l47
[3]
http://git.haskell.org/ghc.git/blob/bdc555885b8898684549eca70053c9ce0ec7fa39:/compiler/hsSyn/HsBinds.hs#l264
[4]
http://git.haskell.org/ghc.git/blob/bdc555885b8898684549eca70053c9ce0ec7fa39:/compiler/hsSyn/PlaceHolder.hs#l102
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160525/0c95f847/attachment.html>

From alan.zimm at gmail.com  Wed May 25 18:52:59 2016
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Wed, 25 May 2016 20:52:59 +0200
Subject: instances for closed type families
In-Reply-To: <CADdQpRA5MymiiEVH=+iBi5KpWX=3fYsvh-XMN0fOWS7PWJL5Qg@mail.gmail.com>
References: <CADdQpRA5MymiiEVH=+iBi5KpWX=3fYsvh-XMN0fOWS7PWJL5Qg@mail.gmail.com>
Message-ID: <CANma=H8xFNdfU6-SmUDZnRueRrpM17q6e24WKemrWCHF5uFQ2w@mail.gmail.com>

Ryan / Simon, thanks.

I have been working it in the way the PostRn stuff was done, but then it
struck me there may be an easier way.

I recall there was some discussion when the PostRn/PostTc stuff went in
around the closed type family solution being better, and I thought it was
that the Data instances would be more easy to define.

And I also seem to recall that the closed type families should be able to
get rid of the UndecidableInstances pragma, but I do not recall the details.

We are now able to use closed type families in GHC source, as it is
supported from GHC 7.8 onwards

Regards
  Alan


On Wed, May 25, 2016 at 8:42 PM, Ryan Scott <ryan.gl.scott at gmail.com> wrote:

> Simon is right, you cannot use a type family as an instance head. But why
> do you need to? Typically, if you're deriving a Data instance that involves
> type families, the type families would be inside another data type. A
> real-world example is HsBindLR [1]:
>
>     data HsBindLR idL idR
>       = FunBind {
>           ...
>           bind_fvs :: PostRn idL NameSet,
>           ...
>         } | ...
>
> where PostRn is a type family [2]. Now, you can't simply derive Data for
> HsBindLR, because GHC has no way of knowing what PostRn will evaluate to!
> But you can use standalone deriving to get what you want:
>
>     deriving instance (Data (PostRn idL NameSet), ...) => Data (HsBindLR
> idL idR)
>
> And in fact, this is what GHC does [3], using a convenient type synonyms
> for the long, sprawling context you need [4].
>
> So in your example, while you can't directly create a Data instance for
> NameOrRdrName itself, you can quite easily create Data instances for
> anything that might use NameOrRdrName. Does that work for your use cases?
>
> Ryan S.
> -----
> [1]
> http://git.haskell.org/ghc.git/blob/bdc555885b8898684549eca70053c9ce0ec7fa39:/compiler/hsSyn/HsBinds.hs#l111
> [2]
> http://git.haskell.org/ghc.git/blob/bdc555885b8898684549eca70053c9ce0ec7fa39:/compiler/hsSyn/PlaceHolder.hs#l47
> [3]
> http://git.haskell.org/ghc.git/blob/bdc555885b8898684549eca70053c9ce0ec7fa39:/compiler/hsSyn/HsBinds.hs#l264
> [4]
> http://git.haskell.org/ghc.git/blob/bdc555885b8898684549eca70053c9ce0ec7fa39:/compiler/hsSyn/PlaceHolder.hs#l102
>
> _______________________________________________
> 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/20160525/f508da88/attachment.html>

From ryan.gl.scott at gmail.com  Wed May 25 19:09:57 2016
From: ryan.gl.scott at gmail.com (Ryan Scott)
Date: Wed, 25 May 2016 15:09:57 -0400
Subject: instances for closed type families
In-Reply-To: <CANma=H8xFNdfU6-SmUDZnRueRrpM17q6e24WKemrWCHF5uFQ2w@mail.gmail.com>
References: <CADdQpRA5MymiiEVH=+iBi5KpWX=3fYsvh-XMN0fOWS7PWJL5Qg@mail.gmail.com>
 <CANma=H8xFNdfU6-SmUDZnRueRrpM17q6e24WKemrWCHF5uFQ2w@mail.gmail.com>
Message-ID: <CADdQpRBGXMq4qbD2+u7hEeF8AA0xH7Y_CQy8UHz7btJv+DGiKw@mail.gmail.com>

> I recall there was some discussion when the PostRn/PostTc stuff went in around the closed type family solution being better, and I thought it was that the Data instances would be more easy to define.

Do you happen to know where this discussion can be found online? To be
honest, I'm not sure whether closed vs. open type families is even a
relevant distinction in this case. Regardless of where NameOrRdrName
is open or closed, the following code won't compile:

    data Foo a = Foo (NameOrRdrName a) deriving Data

And that's simply because GHC hasn't enough information to know
whether Foo a will always resolve to something that's a Data instance.
Even if NameOrRdrName is closed, someone could still use types like
NameOrRdrName Char.

If NameOrRdrName were somehow made to be injective, then it'd be a
different story. But I doubt that such a thing is possible in this
case (based on the definition of NameOrRdrName you gave), so I think
we'll just have to settle for turning on UndecidableInstances and
writing code that we know won't throw the typechecker into a loop.

Ryan S.

On Wed, May 25, 2016 at 2:52 PM, Alan & Kim Zimmerman
<alan.zimm at gmail.com> wrote:
> Ryan / Simon, thanks.
>
> I have been working it in the way the PostRn stuff was done, but then it
> struck me there may be an easier way.
>
> I recall there was some discussion when the PostRn/PostTc stuff went in
> around the closed type family solution being better, and I thought it was
> that the Data instances would be more easy to define.
>
> And I also seem to recall that the closed type families should be able to
> get rid of the UndecidableInstances pragma, but I do not recall the details.
>
> We are now able to use closed type families in GHC source, as it is
> supported from GHC 7.8 onwards
>
> Regards
>   Alan
>
>
> On Wed, May 25, 2016 at 8:42 PM, Ryan Scott <ryan.gl.scott at gmail.com> wrote:
>>
>> Simon is right, you cannot use a type family as an instance head. But why
>> do you need to? Typically, if you're deriving a Data instance that involves
>> type families, the type families would be inside another data type. A
>> real-world example is HsBindLR [1]:
>>
>>     data HsBindLR idL idR
>>       = FunBind {
>>           ...
>>           bind_fvs :: PostRn idL NameSet,
>>           ...
>>         } | ...
>>
>> where PostRn is a type family [2]. Now, you can't simply derive Data for
>> HsBindLR, because GHC has no way of knowing what PostRn will evaluate to!
>> But you can use standalone deriving to get what you want:
>>
>>     deriving instance (Data (PostRn idL NameSet), ...) => Data (HsBindLR
>> idL idR)
>>
>> And in fact, this is what GHC does [3], using a convenient type synonyms
>> for the long, sprawling context you need [4].
>>
>> So in your example, while you can't directly create a Data instance for
>> NameOrRdrName itself, you can quite easily create Data instances for
>> anything that might use NameOrRdrName. Does that work for your use cases?
>>
>> Ryan S.
>> -----
>> [1]
>> http://git.haskell.org/ghc.git/blob/bdc555885b8898684549eca70053c9ce0ec7fa39:/compiler/hsSyn/HsBinds.hs#l111
>> [2]
>> http://git.haskell.org/ghc.git/blob/bdc555885b8898684549eca70053c9ce0ec7fa39:/compiler/hsSyn/PlaceHolder.hs#l47
>> [3]
>> http://git.haskell.org/ghc.git/blob/bdc555885b8898684549eca70053c9ce0ec7fa39:/compiler/hsSyn/HsBinds.hs#l264
>> [4]
>> http://git.haskell.org/ghc.git/blob/bdc555885b8898684549eca70053c9ce0ec7fa39:/compiler/hsSyn/PlaceHolder.hs#l102
>>
>> _______________________________________________
>> 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  Wed May 25 19:26:54 2016
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Wed, 25 May 2016 21:26:54 +0200
Subject: instances for closed type families
In-Reply-To: <CADdQpRBGXMq4qbD2+u7hEeF8AA0xH7Y_CQy8UHz7btJv+DGiKw@mail.gmail.com>
References: <CADdQpRA5MymiiEVH=+iBi5KpWX=3fYsvh-XMN0fOWS7PWJL5Qg@mail.gmail.com>
 <CANma=H8xFNdfU6-SmUDZnRueRrpM17q6e24WKemrWCHF5uFQ2w@mail.gmail.com>
 <CADdQpRBGXMq4qbD2+u7hEeF8AA0xH7Y_CQy8UHz7btJv+DGiKw@mail.gmail.com>
Message-ID: <CANma=H-hAbjJs9G516MAb61biXz4rRN=q0R=CBkSRgL12==v_g@mail.gmail.com>

Ryan

The discussion was in this thread [1], but went off list at some point.

The relevant part of the off-list discussion, quoting Philip H?lzenspies  is

"UndecidableInstances comes from having to constrain the type that the
PostTcType-family projects to, besides the arguments of the AST-types;

instance (Data (PostTcType id), Data id) => Data (HsIPBinds id) where ...

If we could derive that from the definition of PostTcType (and I don't see
why we couldn't from a closed family; not sure about the open ones), we
would only need to constrain "id" and, thus, we could actually just use
"deriving".

Of the diff, btw, I don't get why PendingRnSplice is suddenly
parameterised... Thoughts?

Ph."

and SimonPJ responded

"

Why do we need UndecidableInstances?



I still (currently) think we can use open type families perfectly well.
Why won?t that work?  (Could switch to closed after GHC?s bootstrap caught
up.)



Simon

 "

So basically there is a mention that it may be possible.

Alan





[1] https://mail.haskell.org/pipermail/ghc-devs/2014-July/005808.html

On Wed, May 25, 2016 at 9:09 PM, Ryan Scott <ryan.gl.scott at gmail.com> wrote:

> > I recall there was some discussion when the PostRn/PostTc stuff went in
> around the closed type family solution being better, and I thought it was
> that the Data instances would be more easy to define.
>
> Do you happen to know where this discussion can be found online? To be
> honest, I'm not sure whether closed vs. open type families is even a
> relevant distinction in this case. Regardless of where NameOrRdrName
> is open or closed, the following code won't compile:
>
>     data Foo a = Foo (NameOrRdrName a) deriving Data
>
> And that's simply because GHC hasn't enough information to know
> whether Foo a will always resolve to something that's a Data instance.
> Even if NameOrRdrName is closed, someone could still use types like
> NameOrRdrName Char.
>
> If NameOrRdrName were somehow made to be injective, then it'd be a
> different story. But I doubt that such a thing is possible in this
> case (based on the definition of NameOrRdrName you gave), so I think
> we'll just have to settle for turning on UndecidableInstances and
> writing code that we know won't throw the typechecker into a loop.
>
> Ryan S.
>
> On Wed, May 25, 2016 at 2:52 PM, Alan & Kim Zimmerman
> <alan.zimm at gmail.com> wrote:
> > Ryan / Simon, thanks.
> >
> > I have been working it in the way the PostRn stuff was done, but then it
> > struck me there may be an easier way.
> >
> > I recall there was some discussion when the PostRn/PostTc stuff went in
> > around the closed type family solution being better, and I thought it was
> > that the Data instances would be more easy to define.
> >
> > And I also seem to recall that the closed type families should be able to
> > get rid of the UndecidableInstances pragma, but I do not recall the
> details.
> >
> > We are now able to use closed type families in GHC source, as it is
> > supported from GHC 7.8 onwards
> >
> > Regards
> >   Alan
> >
> >
> > On Wed, May 25, 2016 at 8:42 PM, Ryan Scott <ryan.gl.scott at gmail.com>
> wrote:
> >>
> >> Simon is right, you cannot use a type family as an instance head. But
> why
> >> do you need to? Typically, if you're deriving a Data instance that
> involves
> >> type families, the type families would be inside another data type. A
> >> real-world example is HsBindLR [1]:
> >>
> >>     data HsBindLR idL idR
> >>       = FunBind {
> >>           ...
> >>           bind_fvs :: PostRn idL NameSet,
> >>           ...
> >>         } | ...
> >>
> >> where PostRn is a type family [2]. Now, you can't simply derive Data for
> >> HsBindLR, because GHC has no way of knowing what PostRn will evaluate
> to!
> >> But you can use standalone deriving to get what you want:
> >>
> >>     deriving instance (Data (PostRn idL NameSet), ...) => Data (HsBindLR
> >> idL idR)
> >>
> >> And in fact, this is what GHC does [3], using a convenient type synonyms
> >> for the long, sprawling context you need [4].
> >>
> >> So in your example, while you can't directly create a Data instance for
> >> NameOrRdrName itself, you can quite easily create Data instances for
> >> anything that might use NameOrRdrName. Does that work for your use
> cases?
> >>
> >> Ryan S.
> >> -----
> >> [1]
> >>
> http://git.haskell.org/ghc.git/blob/bdc555885b8898684549eca70053c9ce0ec7fa39:/compiler/hsSyn/HsBinds.hs#l111
> >> [2]
> >>
> http://git.haskell.org/ghc.git/blob/bdc555885b8898684549eca70053c9ce0ec7fa39:/compiler/hsSyn/PlaceHolder.hs#l47
> >> [3]
> >>
> http://git.haskell.org/ghc.git/blob/bdc555885b8898684549eca70053c9ce0ec7fa39:/compiler/hsSyn/HsBinds.hs#l264
> >> [4]
> >>
> http://git.haskell.org/ghc.git/blob/bdc555885b8898684549eca70053c9ce0ec7fa39:/compiler/hsSyn/PlaceHolder.hs#l102
> >>
> >> _______________________________________________
> >> 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/20160525/d88d230c/attachment-0001.html>

From david.feuer at gmail.com  Wed May 25 23:51:36 2016
From: david.feuer at gmail.com (David Feuer)
Date: Wed, 25 May 2016 19:51:36 -0400
Subject: Optimizing "counting" GADTs
In-Reply-To: <CAMgWh9vMWMu+d+tEmzOnwfytdWYaqiga-oD_xmrgh-MvWBP6kA@mail.gmail.com>
References: <CAMgWh9syF+3Nk5fsrKPVF+DYU4Aype3_vULqboNQjwwkpbbSLA@mail.gmail.com>
 <CAMgWh9vMWMu+d+tEmzOnwfytdWYaqiga-oD_xmrgh-MvWBP6kA@mail.gmail.com>
Message-ID: <CAMgWh9v8pJrboFedXVN-fr0R_OC4iA7CwaMK4M-CBgUxgA2jHQ@mail.gmail.com>

I've started a wiki page,
https://ghc.haskell.org/trac/ghc/wiki/OptimizeCountingGADTs , to consider
optimizing GADTs that look like natural numbers but that possibly have
"heavy zeros". Please take a look.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160525/a3c4ce53/attachment.html>

From david.feuer at gmail.com  Thu May 26 00:40:01 2016
From: david.feuer at gmail.com (David Feuer)
Date: Wed, 25 May 2016 20:40:01 -0400
Subject: Optimizing "counting" GADTs
In-Reply-To: <CAMgWh9v2rGSW-QuU-BhZUNVRGuc5yAUrcqSOd_hwhVR730ex0w@mail.gmail.com>
References: <CAMgWh9syF+3Nk5fsrKPVF+DYU4Aype3_vULqboNQjwwkpbbSLA@mail.gmail.com>
 <CAMgWh9vMWMu+d+tEmzOnwfytdWYaqiga-oD_xmrgh-MvWBP6kA@mail.gmail.com>
 <CAMgWh9v8pJrboFedXVN-fr0R_OC4iA7CwaMK4M-CBgUxgA2jHQ@mail.gmail.com>
 <CAHYVw0wfynJVh==T8pd2cB-Pkq93PikGvCm3fR2VuSfnOSjY7Q@mail.gmail.com>
 <CAMgWh9s985Ekfk6rVYZHe9RUKP4+=4y8sjd5Ch8BMd5Q7kriuA@mail.gmail.com>
 <CAMgWh9v2rGSW-QuU-BhZUNVRGuc5yAUrcqSOd_hwhVR730ex0w@mail.gmail.com>
Message-ID: <CAMgWh9uUHQ_DDBTR2uSc4LZ7m4x_7AoSTLz9CjP70t1k35aXFA@mail.gmail.com>

Partially. Unfortunately, bidirectional pattern synonyms tie the types of
the pattern synonyms to the types of the smart constructors for no good
reason, making them (currently) inappropriate. But fixing that problem
would offer one way to this optimization, I think.
On May 25, 2016 8:37 PM, "Carter Schonwald" <carter.schonwald at gmail.com>
wrote:

could this be simulated/modeled with pattern synonyms?

On Wed, May 25, 2016 at 7:51 PM, David Feuer <david.feuer at gmail.com> wrote:

> I've started a wiki page,
> https://ghc.haskell.org/trac/ghc/wiki/OptimizeCountingGADTs , to consider
> optimizing GADTs that look like natural numbers but that possibly have
> "heavy zeros". Please take a look.
>
> _______________________________________________
> 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/20160525/4e8d4d43/attachment.html>

From juhpetersen at gmail.com  Fri May 27 09:09:34 2016
From: juhpetersen at gmail.com (Jens Petersen)
Date: Fri, 27 May 2016 18:09:34 +0900
Subject: [ANNOUNCE] GHC 8.0.1 is available!
In-Reply-To: <8737pbxwvo.fsf@smart-cactus.org>
References: <8737pbxwvo.fsf@smart-cactus.org>
Message-ID: <CAEDGBqJ9=hcrWPnvi24xR0wqZsM4Zce2-c-WdNycrA+MGN2e8A@mail.gmail.com>

On 22 May 2016 at 00:18, Ben Gamari <ben at well-typed.com> wrote:

> The GHC developers are very pleased to announce the release of the first
> new super-major version of our Haskell compiler in six years, GHC 8.0.1.
>

Congratulations on the release!

I forgot to mention I built it for Fedora and RHEL/Centos 7 in my Copr repo:
https://copr.fedorainfracloud.org/coprs/petersen/ghc-8.0.1/

If you run into any problems please report them to me.

I also made a Fedora docker image with 8.0.1 tag that includes also
cabal-install and stack:
https://hub.docker.com/r/juhp/fedora-haskell-ghc/

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

From david.feuer at gmail.com  Fri May 27 11:50:41 2016
From: david.feuer at gmail.com (David Feuer)
Date: Fri, 27 May 2016 07:50:41 -0400
Subject: Optimizing "counting" GADTs
In-Reply-To: <CAMgWh9uUHQ_DDBTR2uSc4LZ7m4x_7AoSTLz9CjP70t1k35aXFA@mail.gmail.com>
References: <CAMgWh9syF+3Nk5fsrKPVF+DYU4Aype3_vULqboNQjwwkpbbSLA@mail.gmail.com>
 <CAMgWh9vMWMu+d+tEmzOnwfytdWYaqiga-oD_xmrgh-MvWBP6kA@mail.gmail.com>
 <CAMgWh9v8pJrboFedXVN-fr0R_OC4iA7CwaMK4M-CBgUxgA2jHQ@mail.gmail.com>
 <CAHYVw0wfynJVh==T8pd2cB-Pkq93PikGvCm3fR2VuSfnOSjY7Q@mail.gmail.com>
 <CAMgWh9s985Ekfk6rVYZHe9RUKP4+=4y8sjd5Ch8BMd5Q7kriuA@mail.gmail.com>
 <CAMgWh9v2rGSW-QuU-BhZUNVRGuc5yAUrcqSOd_hwhVR730ex0w@mail.gmail.com>
 <CAMgWh9uUHQ_DDBTR2uSc4LZ7m4x_7AoSTLz9CjP70t1k35aXFA@mail.gmail.com>
Message-ID: <CAMgWh9vi4-dw7mhDrz=rO9rZGmLbfSJxeKGhmeMYTvqbdTnk6Q@mail.gmail.com>

Scratch that. I think you might be right.
On May 25, 2016 8:40 PM, "David Feuer" <david.feuer at gmail.com> wrote:

> Partially. Unfortunately, bidirectional pattern synonyms tie the types of
> the pattern synonyms to the types of the smart constructors for no good
> reason, making them (currently) inappropriate. But fixing that problem
> would offer one way to this optimization, I think.
> On May 25, 2016 8:37 PM, "Carter Schonwald" <carter.schonwald at gmail.com>
> wrote:
>
> could this be simulated/modeled with pattern synonyms?
>
> On Wed, May 25, 2016 at 7:51 PM, David Feuer <david.feuer at gmail.com>
> wrote:
>
>> I've started a wiki page,
>> https://ghc.haskell.org/trac/ghc/wiki/OptimizeCountingGADTs , to
>> consider optimizing GADTs that look like natural numbers but that possibly
>> have "heavy zeros". Please take a look.
>>
>> _______________________________________________
>> 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/20160527/21e7916a/attachment.html>

From omeragacan at gmail.com  Sat May 28 18:56:08 2016
From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=)
Date: Sat, 28 May 2016 14:56:08 -0400
Subject: can't build with release settings
Message-ID: <CAMQQO3kCM7eiRwL+2WVa-n4CiOhmo3bp542AtkANC1TgZKwNtw@mail.gmail.com>

Is anyone else having this problem when building with default settings
(no build.mk):

    "inplace/bin/ghc-stage2" -hisuf dyn_hi -osuf  dyn_o -hcsuf dyn_hc
-fPIC -dynamic  -H32m -O -Wall      -hide-all-packages -i
-iutils/haddock/driver -iutils/haddock/haddock-api/src
-iutils/haddock/haddock-library/vendor/attoparsec-0.12.1.1
-iutils/haddock/haddock-library/src -iutils/haddock/dist/build
-iutils/haddock/dist/build/autogen -Iutils/haddock/dist/build
-Iutils/haddock/dist/build/autogen    -optP-DIN_GHC_TREE -optP-include
-optPutils/haddock/dist/build/autogen/cabal_macros.h -package-id
Cabal-1.25.0.0 -package-id array-0.5.1.1 -package-id base-4.9.0.0
-package-id bytestring-0.10.8.1 -package-id containers-0.5.7.1
-package-id deepseq-1.4.2.0 -package-id directory-1.2.6.2 -package-id
filepath-1.4.1.0 -package-id ghc-8.1 -package-id ghc-boot-8.1
-package-id transformers-0.5.2.0 -package-id xhtml-3000.2.1
-funbox-strict-fields -Wall -fwarn-tabs -O2 -threaded -XHaskell2010
-no-user-package-db -rtsopts -Wno-unused-imports -Wno-deprecations
-Wnoncanonical-monad-instances  -odir utils/haddock/dist/build -hidir
utils/haddock/dist/build -stubdir utils/haddock/dist/build    -c
utils/haddock/haddock-library/src/Documentation/Haddock/Types.hs -o
utils/haddock/dist/build/Documentation/Haddock/Types.dyn_o

    utils/haddock/haddock-library/src/Documentation/Haddock/Types.hs:15:8:
error:
        Failed to load interface for ?Prelude?
        It is a member of the hidden package ?base-4.9.0.0?.
        Use -v to see a list of the files searched for.

    utils/haddock/haddock-library/src/Documentation/Haddock/Types.hs:17:1:
error:
        Failed to load interface for ?Data.Foldable?
        It is a member of the hidden package ?base-4.9.0.0?.
        Use -v to see a list of the files searched for.

    utils/haddock/haddock-library/src/Documentation/Haddock/Types.hs:18:1:
error:
        Failed to load interface for ?Data.Traversable?
        It is a member of the hidden package ?base-4.9.0.0?.
        Use -v to see a list of the files searched for.

    utils/haddock/driver/ResponseFile.hs:2:8: error:
        Failed to load interface for ?Prelude?
        It is a member of the hidden package ?base-4.9.0.0?.
        Use -v to see a list of the files searched for.

    utils/haddock/driver/ResponseFile.hs:8:1: error:
        Failed to load interface for ?Control.Exception?
        It is a member of the hidden package ?base-4.9.0.0?.
        Use -v to see a list of the files searched for.

    utils/haddock/driver/ResponseFile.hs:9:1: error:
        Failed to load interface for ?Data.Char?
        It is a member of the hidden package ?base-4.9.0.0?.
        Use -v to see a list of the files searched for.

    utils/haddock/driver/ResponseFile.hs:10:1: error:
        Failed to load interface for ?Data.Foldable?
        It is a member of the hidden package ?base-4.9.0.0?.
        Use -v to see a list of the files searched for.

    utils/haddock/driver/ResponseFile.hs:11:1: error:
        Failed to load interface for ?System.Exit?
        It is a member of the hidden package ?base-4.9.0.0?.
        Use -v to see a list of the files searched for.

    utils/haddock/driver/ResponseFile.hs:12:1: error:
        Failed to load interface for ?System.IO?
        It is a member of the hidden package ?base-4.9.0.0?.
        Use -v to see a list of the files searched for.


    utils/haddock/haddock-api/src/Haddock/GhcUtils.hs:16:8:
error:utils/haddock/haddock-api/src/Haddock/Backends/Hyperlinker/Types.hs:1:8:
error:
        Failed to load interface for ?Prelude?

        It is a member of the hidden package    Failed to load
interface for ?base-4.9.0.0?.
        Use -v to see a list of the files searched for.
     ?Prelude?

        It is a member of the hidden package ?base-4.9.0.0?.
        Use -v to see a list of the files searched for.

    utils/haddock/haddock-api/src/Haddock/GhcUtils.hs:19:1: error:
        Failed to load interface for ?Control.Arrow?
        It is a member of the hidden package ?base-4.9.0.0?.
        Use -v to see a list of the files searched for.

    utils/haddock/haddock-api/src/Haddock/Backends/Hyperlinker/Types.hs:4:1:
error:utils/haddock/haddock-api/src/Haddock/GhcUtils.hs:20:1: error:
        Failed to load interface for
        Failed to load interface for ?GHC?
     ?Data.Function?
        It is a member of the hidden package    It is a member of the
hidden package ?base-4.9.0.0?.
     ?ghc-8.1?.
        Use -v to see a list of the files searched for.
        Use -v to see a list of the files searched for.

    utils/haddock/haddock-api/src/Haddock/GhcUtils.hs:22:1: error:
        Failed to load interface for ?Exception?
        It is a member of the hidden package ?ghc-8.1?.
        Use -v to see a list of the files searched for.

    utils/haddock/haddock-api/src/Haddock/GhcUtils.hs:23:1: error:
        Failed to load interface for ?Outputable?
        It is a member of the hidden package ?ghc-8.1?.
        Use -v to see a list of the files searched for.

    utils/haddock/haddock-api/src/Haddock/GhcUtils.hs:24:1: error:
        Failed to load interface for ?Name?
        It is a member of the hidden package ?ghc-8.1?.
        Use -v to see a list of the files searched for.

    utils/haddock/haddock-api/src/Haddock/GhcUtils.hs:25:1: error:
        Failed to load interface for ?Lexeme?
        It is a member of the hidden package ?ghc-8.1?.
        Use -v to see a list of the files searched for.

    utils/haddock/haddock-api/src/Haddock/GhcUtils.hs:26:1: error:
        Failed to load interface for ?Module?
        It is a member of the hidden package ?ghc-8.1?.
        Use -v to see a list of the files searched for.

    utils/haddock/haddock-api/src/Haddock/GhcUtils.hs:27:1: error:
        Failed to load interface for ?RdrName?
        It is a member of the hidden package ?ghc-8.1?.
        Use -v to see a list of the files searched for.

    utils/haddock/haddock-api/src/Haddock/GhcUtils.hs:28:1: error:
        Failed to load interface for ?GhcMonad?
        It is a member of the hidden package ?ghc-8.1?.
        Use -v to see a list of the files searched for.

    utils/haddock/haddock-api/src/Haddock/GhcUtils.hs:29:1: error:
        Failed to load interface for ?HscTypes?
        It is a member of the hidden package ?ghc-8.1?.
        Use -v to see a list of the files searched for.

    utils/haddock/haddock-api/src/Haddock/GhcUtils.hs:30:1: error:
        Failed to load interface for ?UniqFM?
        It is a member of the hidden package ?ghc-8.1?.
        Use -v to see a list of the files searched for.

    utils/haddock/haddock-api/src/Haddock/GhcUtils.hs:31:1: error:
        Failed to load interface for ?GHC?
        It is a member of the hidden package ?ghc-8.1?.
        Use -v to see a list of the files searched for.

    utils/haddock/haddock-api/src/Haddock/GhcUtils.hs:32:1: error:
        Failed to load interface for ?Class?
        It is a member of the hidden package ?ghc-8.1?.
        Use -v to see a list of the files searched for.
    utils/haddock/ghc.mk:21: recipe for target
'utils/haddock/dist/build/ResponseFile.dyn_o' failed
    make[1]: *** [utils/haddock/dist/build/ResponseFile.dyn_o] Error 1
    make[1]: *** Waiting for unfinished jobs....
    utils/haddock/ghc.mk:21: recipe for target
'utils/haddock/dist/build/Documentation/Haddock/Types.dyn_o' failed
    make[1]: ***
[utils/haddock/dist/build/Documentation/Haddock/Types.dyn_o] Error 1
    utils/haddock/ghc.mk:21: recipe for target
'utils/haddock/dist/build/Haddock/Backends/Hyperlinker/Types.dyn_o'
failed
    make[1]: ***
[utils/haddock/dist/build/Haddock/Backends/Hyperlinker/Types.dyn_o]
Error 1
    utils/haddock/ghc.mk:21: recipe for target
'utils/haddock/dist/build/Haddock/GhcUtils.dyn_o' failed
    make[1]: *** [utils/haddock/dist/build/Haddock/GhcUtils.dyn_o] Error 1
    Makefile:129: recipe for target 'all' failed
    make: *** [all] Error 2
    ( make distclean && ./boot && ./configure && make -j4; ) 2>&1
6382.95s user 1069.99s system 336% cpu 36:57.03 total
    tee build_output  0.04s user 0.60s system 0% cpu 36:57.03 total

This is d40682e + one commit that I'm sure wouldn't break the build this way. I
can't compile anything with stage2 compiler becuase of this:

    ?  strict_cmm ghc-stage2 Main.hs
    [1 of 1] Compiling Lib              ( Main.hs, Main.o ) [Prelude changed]

    Main.hs:4:1: error:
        Failed to load interface for ?Prelude?
        It is a member of the hidden package ?base-4.9.0.0?.
        Use -v to see a list of the files searched for.

-v output:

    ?  strict_cmm ghc-stage2 Main.hs -v
    Glasgow Haskell Compiler, Version 8.1.20160528, stage 2 booted by
GHC version 8.0.1
    Using binary package database:
/home/omer/haskell/ghc_3/inplace/lib/package.conf.d/package.cache
    loading package database /home/omer/haskell/ghc_3/inplace/lib/package.conf.d
    wired-in package ghc-prim mapped to ghc-prim-0.5.0.0
    wired-in package integer-gmp mapped to integer-gmp-1.0.0.1
    wired-in package base mapped to base-4.9.0.0
    wired-in package rts mapped to rts
    wired-in package template-haskell mapped to template-haskell-2.11.0.0
    wired-in package ghc mapped to ghc-8.1
    wired-in package dph-seq not found.
    wired-in package dph-par not found.
    Hsc static flags:
    loading package database /home/omer/haskell/ghc_3/inplace/lib/package.conf.d
    wired-in package ghc-prim mapped to ghc-prim-0.5.0.0
    wired-in package integer-gmp mapped to integer-gmp-1.0.0.1
    wired-in package base mapped to base-4.9.0.0
    wired-in package rts mapped to rts-1.0
    wired-in package template-haskell mapped to template-haskell-2.11.0.0
    wired-in package ghc mapped to ghc-8.1
    wired-in package dph-seq not found.
    wired-in package dph-par not found.
    *** Chasing dependencies:
    Chasing modules from: *Main.hs
    !!! Chasing dependencies: finished in 0.44 milliseconds, allocated
0.417 megabytes
    Stable obj: [Lib]
    Stable BCO: []
    Ready for upsweep
      [NONREC
          ModSummary {
             ms_hs_date = 2016-05-28 13:53:06.703533428 UTC
             ms_mod = Lib,
             ms_textual_imps = [(Nothing, Prelude)]
             ms_srcimps = []
          }]
    *** Deleting temp files:
    Deleting:
    compile: input file Main.hs
    *** Checking old interface for Lib:
    [1 of 1] Compiling Lib              ( Main.hs, Main.o ) [Prelude changed]
    *** Parser [Lib]:
    !!! Parser [Lib]: finished in 0.42 milliseconds, allocated 0.466 megabytes
    *** Renamer/typechecker [Lib]:
    !!! Renamer/typechecker [Lib]: finished in 0.05 milliseconds,
allocated 0.004 megabytes

    Main.hs:4:1: error:
        Failed to load interface for ?Prelude?
        It is a member of the hidden package ?base-4.9.0.0?.
        Locations searched:
          Prelude.hs
          Prelude.lhs
          Prelude.hsig
          Prelude.lhsig
    Upsweep partially successful.
    *** Deleting temp files:
    Deleting:
    link(batch): upsweep (partially) failed OR
       Main.main not exported; not linking.
    *** Deleting temp files:
    Deleting:
    *** Deleting temp dirs:
    Deleting:

Any ideas?

From omeragacan at gmail.com  Sat May 28 19:03:50 2016
From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=)
Date: Sat, 28 May 2016 15:03:50 -0400
Subject: can't build with release settings
In-Reply-To: <CAMQQO3kCM7eiRwL+2WVa-n4CiOhmo3bp542AtkANC1TgZKwNtw@mail.gmail.com>
References: <CAMQQO3kCM7eiRwL+2WVa-n4CiOhmo3bp542AtkANC1TgZKwNtw@mail.gmail.com>
Message-ID: <CAMQQO3nBgnp19Au5oVzZowqfvjGCveYu0Sha8SMy1EfR3vHF5A@mail.gmail.com>

I just had the same error when I checkout current HEAD. (without a
distclean though)

2016-05-28 14:56 GMT-04:00 ?mer Sinan A?acan <omeragacan at gmail.com>:
> Is anyone else having this problem when building with default settings
> (no build.mk):
>
>     "inplace/bin/ghc-stage2" -hisuf dyn_hi -osuf  dyn_o -hcsuf dyn_hc
> -fPIC -dynamic  -H32m -O -Wall      -hide-all-packages -i
> -iutils/haddock/driver -iutils/haddock/haddock-api/src
> -iutils/haddock/haddock-library/vendor/attoparsec-0.12.1.1
> -iutils/haddock/haddock-library/src -iutils/haddock/dist/build
> -iutils/haddock/dist/build/autogen -Iutils/haddock/dist/build
> -Iutils/haddock/dist/build/autogen    -optP-DIN_GHC_TREE -optP-include
> -optPutils/haddock/dist/build/autogen/cabal_macros.h -package-id
> Cabal-1.25.0.0 -package-id array-0.5.1.1 -package-id base-4.9.0.0
> -package-id bytestring-0.10.8.1 -package-id containers-0.5.7.1
> -package-id deepseq-1.4.2.0 -package-id directory-1.2.6.2 -package-id
> filepath-1.4.1.0 -package-id ghc-8.1 -package-id ghc-boot-8.1
> -package-id transformers-0.5.2.0 -package-id xhtml-3000.2.1
> -funbox-strict-fields -Wall -fwarn-tabs -O2 -threaded -XHaskell2010
> -no-user-package-db -rtsopts -Wno-unused-imports -Wno-deprecations
> -Wnoncanonical-monad-instances  -odir utils/haddock/dist/build -hidir
> utils/haddock/dist/build -stubdir utils/haddock/dist/build    -c
> utils/haddock/haddock-library/src/Documentation/Haddock/Types.hs -o
> utils/haddock/dist/build/Documentation/Haddock/Types.dyn_o
>
>     utils/haddock/haddock-library/src/Documentation/Haddock/Types.hs:15:8:
> error:
>         Failed to load interface for ?Prelude?
>         It is a member of the hidden package ?base-4.9.0.0?.
>         Use -v to see a list of the files searched for.
>
>     utils/haddock/haddock-library/src/Documentation/Haddock/Types.hs:17:1:
> error:
>         Failed to load interface for ?Data.Foldable?
>         It is a member of the hidden package ?base-4.9.0.0?.
>         Use -v to see a list of the files searched for.
>
>     utils/haddock/haddock-library/src/Documentation/Haddock/Types.hs:18:1:
> error:
>         Failed to load interface for ?Data.Traversable?
>         It is a member of the hidden package ?base-4.9.0.0?.
>         Use -v to see a list of the files searched for.
>
>     utils/haddock/driver/ResponseFile.hs:2:8: error:
>         Failed to load interface for ?Prelude?
>         It is a member of the hidden package ?base-4.9.0.0?.
>         Use -v to see a list of the files searched for.
>
>     utils/haddock/driver/ResponseFile.hs:8:1: error:
>         Failed to load interface for ?Control.Exception?
>         It is a member of the hidden package ?base-4.9.0.0?.
>         Use -v to see a list of the files searched for.
>
>     utils/haddock/driver/ResponseFile.hs:9:1: error:
>         Failed to load interface for ?Data.Char?
>         It is a member of the hidden package ?base-4.9.0.0?.
>         Use -v to see a list of the files searched for.
>
>     utils/haddock/driver/ResponseFile.hs:10:1: error:
>         Failed to load interface for ?Data.Foldable?
>         It is a member of the hidden package ?base-4.9.0.0?.
>         Use -v to see a list of the files searched for.
>
>     utils/haddock/driver/ResponseFile.hs:11:1: error:
>         Failed to load interface for ?System.Exit?
>         It is a member of the hidden package ?base-4.9.0.0?.
>         Use -v to see a list of the files searched for.
>
>     utils/haddock/driver/ResponseFile.hs:12:1: error:
>         Failed to load interface for ?System.IO?
>         It is a member of the hidden package ?base-4.9.0.0?.
>         Use -v to see a list of the files searched for.
>
>
>     utils/haddock/haddock-api/src/Haddock/GhcUtils.hs:16:8:
> error:utils/haddock/haddock-api/src/Haddock/Backends/Hyperlinker/Types.hs:1:8:
> error:
>         Failed to load interface for ?Prelude?
>
>         It is a member of the hidden package    Failed to load
> interface for ?base-4.9.0.0?.
>         Use -v to see a list of the files searched for.
>      ?Prelude?
>
>         It is a member of the hidden package ?base-4.9.0.0?.
>         Use -v to see a list of the files searched for.
>
>     utils/haddock/haddock-api/src/Haddock/GhcUtils.hs:19:1: error:
>         Failed to load interface for ?Control.Arrow?
>         It is a member of the hidden package ?base-4.9.0.0?.
>         Use -v to see a list of the files searched for.
>
>     utils/haddock/haddock-api/src/Haddock/Backends/Hyperlinker/Types.hs:4:1:
> error:utils/haddock/haddock-api/src/Haddock/GhcUtils.hs:20:1: error:
>         Failed to load interface for
>         Failed to load interface for ?GHC?
>      ?Data.Function?
>         It is a member of the hidden package    It is a member of the
> hidden package ?base-4.9.0.0?.
>      ?ghc-8.1?.
>         Use -v to see a list of the files searched for.
>         Use -v to see a list of the files searched for.
>
>     utils/haddock/haddock-api/src/Haddock/GhcUtils.hs:22:1: error:
>         Failed to load interface for ?Exception?
>         It is a member of the hidden package ?ghc-8.1?.
>         Use -v to see a list of the files searched for.
>
>     utils/haddock/haddock-api/src/Haddock/GhcUtils.hs:23:1: error:
>         Failed to load interface for ?Outputable?
>         It is a member of the hidden package ?ghc-8.1?.
>         Use -v to see a list of the files searched for.
>
>     utils/haddock/haddock-api/src/Haddock/GhcUtils.hs:24:1: error:
>         Failed to load interface for ?Name?
>         It is a member of the hidden package ?ghc-8.1?.
>         Use -v to see a list of the files searched for.
>
>     utils/haddock/haddock-api/src/Haddock/GhcUtils.hs:25:1: error:
>         Failed to load interface for ?Lexeme?
>         It is a member of the hidden package ?ghc-8.1?.
>         Use -v to see a list of the files searched for.
>
>     utils/haddock/haddock-api/src/Haddock/GhcUtils.hs:26:1: error:
>         Failed to load interface for ?Module?
>         It is a member of the hidden package ?ghc-8.1?.
>         Use -v to see a list of the files searched for.
>
>     utils/haddock/haddock-api/src/Haddock/GhcUtils.hs:27:1: error:
>         Failed to load interface for ?RdrName?
>         It is a member of the hidden package ?ghc-8.1?.
>         Use -v to see a list of the files searched for.
>
>     utils/haddock/haddock-api/src/Haddock/GhcUtils.hs:28:1: error:
>         Failed to load interface for ?GhcMonad?
>         It is a member of the hidden package ?ghc-8.1?.
>         Use -v to see a list of the files searched for.
>
>     utils/haddock/haddock-api/src/Haddock/GhcUtils.hs:29:1: error:
>         Failed to load interface for ?HscTypes?
>         It is a member of the hidden package ?ghc-8.1?.
>         Use -v to see a list of the files searched for.
>
>     utils/haddock/haddock-api/src/Haddock/GhcUtils.hs:30:1: error:
>         Failed to load interface for ?UniqFM?
>         It is a member of the hidden package ?ghc-8.1?.
>         Use -v to see a list of the files searched for.
>
>     utils/haddock/haddock-api/src/Haddock/GhcUtils.hs:31:1: error:
>         Failed to load interface for ?GHC?
>         It is a member of the hidden package ?ghc-8.1?.
>         Use -v to see a list of the files searched for.
>
>     utils/haddock/haddock-api/src/Haddock/GhcUtils.hs:32:1: error:
>         Failed to load interface for ?Class?
>         It is a member of the hidden package ?ghc-8.1?.
>         Use -v to see a list of the files searched for.
>     utils/haddock/ghc.mk:21: recipe for target
> 'utils/haddock/dist/build/ResponseFile.dyn_o' failed
>     make[1]: *** [utils/haddock/dist/build/ResponseFile.dyn_o] Error 1
>     make[1]: *** Waiting for unfinished jobs....
>     utils/haddock/ghc.mk:21: recipe for target
> 'utils/haddock/dist/build/Documentation/Haddock/Types.dyn_o' failed
>     make[1]: ***
> [utils/haddock/dist/build/Documentation/Haddock/Types.dyn_o] Error 1
>     utils/haddock/ghc.mk:21: recipe for target
> 'utils/haddock/dist/build/Haddock/Backends/Hyperlinker/Types.dyn_o'
> failed
>     make[1]: ***
> [utils/haddock/dist/build/Haddock/Backends/Hyperlinker/Types.dyn_o]
> Error 1
>     utils/haddock/ghc.mk:21: recipe for target
> 'utils/haddock/dist/build/Haddock/GhcUtils.dyn_o' failed
>     make[1]: *** [utils/haddock/dist/build/Haddock/GhcUtils.dyn_o] Error 1
>     Makefile:129: recipe for target 'all' failed
>     make: *** [all] Error 2
>     ( make distclean && ./boot && ./configure && make -j4; ) 2>&1
> 6382.95s user 1069.99s system 336% cpu 36:57.03 total
>     tee build_output  0.04s user 0.60s system 0% cpu 36:57.03 total
>
> This is d40682e + one commit that I'm sure wouldn't break the build this way. I
> can't compile anything with stage2 compiler becuase of this:
>
>     ?  strict_cmm ghc-stage2 Main.hs
>     [1 of 1] Compiling Lib              ( Main.hs, Main.o ) [Prelude changed]
>
>     Main.hs:4:1: error:
>         Failed to load interface for ?Prelude?
>         It is a member of the hidden package ?base-4.9.0.0?.
>         Use -v to see a list of the files searched for.
>
> -v output:
>
>     ?  strict_cmm ghc-stage2 Main.hs -v
>     Glasgow Haskell Compiler, Version 8.1.20160528, stage 2 booted by
> GHC version 8.0.1
>     Using binary package database:
> /home/omer/haskell/ghc_3/inplace/lib/package.conf.d/package.cache
>     loading package database /home/omer/haskell/ghc_3/inplace/lib/package.conf.d
>     wired-in package ghc-prim mapped to ghc-prim-0.5.0.0
>     wired-in package integer-gmp mapped to integer-gmp-1.0.0.1
>     wired-in package base mapped to base-4.9.0.0
>     wired-in package rts mapped to rts
>     wired-in package template-haskell mapped to template-haskell-2.11.0.0
>     wired-in package ghc mapped to ghc-8.1
>     wired-in package dph-seq not found.
>     wired-in package dph-par not found.
>     Hsc static flags:
>     loading package database /home/omer/haskell/ghc_3/inplace/lib/package.conf.d
>     wired-in package ghc-prim mapped to ghc-prim-0.5.0.0
>     wired-in package integer-gmp mapped to integer-gmp-1.0.0.1
>     wired-in package base mapped to base-4.9.0.0
>     wired-in package rts mapped to rts-1.0
>     wired-in package template-haskell mapped to template-haskell-2.11.0.0
>     wired-in package ghc mapped to ghc-8.1
>     wired-in package dph-seq not found.
>     wired-in package dph-par not found.
>     *** Chasing dependencies:
>     Chasing modules from: *Main.hs
>     !!! Chasing dependencies: finished in 0.44 milliseconds, allocated
> 0.417 megabytes
>     Stable obj: [Lib]
>     Stable BCO: []
>     Ready for upsweep
>       [NONREC
>           ModSummary {
>              ms_hs_date = 2016-05-28 13:53:06.703533428 UTC
>              ms_mod = Lib,
>              ms_textual_imps = [(Nothing, Prelude)]
>              ms_srcimps = []
>           }]
>     *** Deleting temp files:
>     Deleting:
>     compile: input file Main.hs
>     *** Checking old interface for Lib:
>     [1 of 1] Compiling Lib              ( Main.hs, Main.o ) [Prelude changed]
>     *** Parser [Lib]:
>     !!! Parser [Lib]: finished in 0.42 milliseconds, allocated 0.466 megabytes
>     *** Renamer/typechecker [Lib]:
>     !!! Renamer/typechecker [Lib]: finished in 0.05 milliseconds,
> allocated 0.004 megabytes
>
>     Main.hs:4:1: error:
>         Failed to load interface for ?Prelude?
>         It is a member of the hidden package ?base-4.9.0.0?.
>         Locations searched:
>           Prelude.hs
>           Prelude.lhs
>           Prelude.hsig
>           Prelude.lhsig
>     Upsweep partially successful.
>     *** Deleting temp files:
>     Deleting:
>     link(batch): upsweep (partially) failed OR
>        Main.main not exported; not linking.
>     *** Deleting temp files:
>     Deleting:
>     *** Deleting temp dirs:
>     Deleting:
>
> Any ideas?

From omeragacan at gmail.com  Sat May 28 19:47:15 2016
From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=)
Date: Sat, 28 May 2016 15:47:15 -0400
Subject: can't build with release settings
In-Reply-To: <CAMQQO3nBgnp19Au5oVzZowqfvjGCveYu0Sha8SMy1EfR3vHF5A@mail.gmail.com>
References: <CAMQQO3kCM7eiRwL+2WVa-n4CiOhmo3bp542AtkANC1TgZKwNtw@mail.gmail.com>
 <CAMQQO3nBgnp19Au5oVzZowqfvjGCveYu0Sha8SMy1EfR3vHF5A@mail.gmail.com>
Message-ID: <CAMQQO3knKPwmFVkNLQZe2=4=NVjj1t68rD9NZ9cK3gGDtWRgyA@mail.gmail.com>

Please ignore. I realized I had a bug in my code (which makes some
changes in generated Cmm) and I realized -DDEBUG is not on for stage1
in release mode, so my assertions were not running. I have no idea how
can the bug cause this error though...

2016-05-28 15:03 GMT-04:00 ?mer Sinan A?acan <omeragacan at gmail.com>:
> I just had the same error when I checkout current HEAD. (without a
> distclean though)
>
> 2016-05-28 14:56 GMT-04:00 ?mer Sinan A?acan <omeragacan at gmail.com>:
>> Is anyone else having this problem when building with default settings
>> (no build.mk):
>>
>>     "inplace/bin/ghc-stage2" -hisuf dyn_hi -osuf  dyn_o -hcsuf dyn_hc
>> -fPIC -dynamic  -H32m -O -Wall      -hide-all-packages -i
>> -iutils/haddock/driver -iutils/haddock/haddock-api/src
>> -iutils/haddock/haddock-library/vendor/attoparsec-0.12.1.1
>> -iutils/haddock/haddock-library/src -iutils/haddock/dist/build
>> -iutils/haddock/dist/build/autogen -Iutils/haddock/dist/build
>> -Iutils/haddock/dist/build/autogen    -optP-DIN_GHC_TREE -optP-include
>> -optPutils/haddock/dist/build/autogen/cabal_macros.h -package-id
>> Cabal-1.25.0.0 -package-id array-0.5.1.1 -package-id base-4.9.0.0
>> -package-id bytestring-0.10.8.1 -package-id containers-0.5.7.1
>> -package-id deepseq-1.4.2.0 -package-id directory-1.2.6.2 -package-id
>> filepath-1.4.1.0 -package-id ghc-8.1 -package-id ghc-boot-8.1
>> -package-id transformers-0.5.2.0 -package-id xhtml-3000.2.1
>> -funbox-strict-fields -Wall -fwarn-tabs -O2 -threaded -XHaskell2010
>> -no-user-package-db -rtsopts -Wno-unused-imports -Wno-deprecations
>> -Wnoncanonical-monad-instances  -odir utils/haddock/dist/build -hidir
>> utils/haddock/dist/build -stubdir utils/haddock/dist/build    -c
>> utils/haddock/haddock-library/src/Documentation/Haddock/Types.hs -o
>> utils/haddock/dist/build/Documentation/Haddock/Types.dyn_o
>>
>>     utils/haddock/haddock-library/src/Documentation/Haddock/Types.hs:15:8:
>> error:
>>         Failed to load interface for ?Prelude?
>>         It is a member of the hidden package ?base-4.9.0.0?.
>>         Use -v to see a list of the files searched for.
>>
>>     utils/haddock/haddock-library/src/Documentation/Haddock/Types.hs:17:1:
>> error:
>>         Failed to load interface for ?Data.Foldable?
>>         It is a member of the hidden package ?base-4.9.0.0?.
>>         Use -v to see a list of the files searched for.
>>
>>     utils/haddock/haddock-library/src/Documentation/Haddock/Types.hs:18:1:
>> error:
>>         Failed to load interface for ?Data.Traversable?
>>         It is a member of the hidden package ?base-4.9.0.0?.
>>         Use -v to see a list of the files searched for.
>>
>>     utils/haddock/driver/ResponseFile.hs:2:8: error:
>>         Failed to load interface for ?Prelude?
>>         It is a member of the hidden package ?base-4.9.0.0?.
>>         Use -v to see a list of the files searched for.
>>
>>     utils/haddock/driver/ResponseFile.hs:8:1: error:
>>         Failed to load interface for ?Control.Exception?
>>         It is a member of the hidden package ?base-4.9.0.0?.
>>         Use -v to see a list of the files searched for.
>>
>>     utils/haddock/driver/ResponseFile.hs:9:1: error:
>>         Failed to load interface for ?Data.Char?
>>         It is a member of the hidden package ?base-4.9.0.0?.
>>         Use -v to see a list of the files searched for.
>>
>>     utils/haddock/driver/ResponseFile.hs:10:1: error:
>>         Failed to load interface for ?Data.Foldable?
>>         It is a member of the hidden package ?base-4.9.0.0?.
>>         Use -v to see a list of the files searched for.
>>
>>     utils/haddock/driver/ResponseFile.hs:11:1: error:
>>         Failed to load interface for ?System.Exit?
>>         It is a member of the hidden package ?base-4.9.0.0?.
>>         Use -v to see a list of the files searched for.
>>
>>     utils/haddock/driver/ResponseFile.hs:12:1: error:
>>         Failed to load interface for ?System.IO?
>>         It is a member of the hidden package ?base-4.9.0.0?.
>>         Use -v to see a list of the files searched for.
>>
>>
>>     utils/haddock/haddock-api/src/Haddock/GhcUtils.hs:16:8:
>> error:utils/haddock/haddock-api/src/Haddock/Backends/Hyperlinker/Types.hs:1:8:
>> error:
>>         Failed to load interface for ?Prelude?
>>
>>         It is a member of the hidden package    Failed to load
>> interface for ?base-4.9.0.0?.
>>         Use -v to see a list of the files searched for.
>>      ?Prelude?
>>
>>         It is a member of the hidden package ?base-4.9.0.0?.
>>         Use -v to see a list of the files searched for.
>>
>>     utils/haddock/haddock-api/src/Haddock/GhcUtils.hs:19:1: error:
>>         Failed to load interface for ?Control.Arrow?
>>         It is a member of the hidden package ?base-4.9.0.0?.
>>         Use -v to see a list of the files searched for.
>>
>>     utils/haddock/haddock-api/src/Haddock/Backends/Hyperlinker/Types.hs:4:1:
>> error:utils/haddock/haddock-api/src/Haddock/GhcUtils.hs:20:1: error:
>>         Failed to load interface for
>>         Failed to load interface for ?GHC?
>>      ?Data.Function?
>>         It is a member of the hidden package    It is a member of the
>> hidden package ?base-4.9.0.0?.
>>      ?ghc-8.1?.
>>         Use -v to see a list of the files searched for.
>>         Use -v to see a list of the files searched for.
>>
>>     utils/haddock/haddock-api/src/Haddock/GhcUtils.hs:22:1: error:
>>         Failed to load interface for ?Exception?
>>         It is a member of the hidden package ?ghc-8.1?.
>>         Use -v to see a list of the files searched for.
>>
>>     utils/haddock/haddock-api/src/Haddock/GhcUtils.hs:23:1: error:
>>         Failed to load interface for ?Outputable?
>>         It is a member of the hidden package ?ghc-8.1?.
>>         Use -v to see a list of the files searched for.
>>
>>     utils/haddock/haddock-api/src/Haddock/GhcUtils.hs:24:1: error:
>>         Failed to load interface for ?Name?
>>         It is a member of the hidden package ?ghc-8.1?.
>>         Use -v to see a list of the files searched for.
>>
>>     utils/haddock/haddock-api/src/Haddock/GhcUtils.hs:25:1: error:
>>         Failed to load interface for ?Lexeme?
>>         It is a member of the hidden package ?ghc-8.1?.
>>         Use -v to see a list of the files searched for.
>>
>>     utils/haddock/haddock-api/src/Haddock/GhcUtils.hs:26:1: error:
>>         Failed to load interface for ?Module?
>>         It is a member of the hidden package ?ghc-8.1?.
>>         Use -v to see a list of the files searched for.
>>
>>     utils/haddock/haddock-api/src/Haddock/GhcUtils.hs:27:1: error:
>>         Failed to load interface for ?RdrName?
>>         It is a member of the hidden package ?ghc-8.1?.
>>         Use -v to see a list of the files searched for.
>>
>>     utils/haddock/haddock-api/src/Haddock/GhcUtils.hs:28:1: error:
>>         Failed to load interface for ?GhcMonad?
>>         It is a member of the hidden package ?ghc-8.1?.
>>         Use -v to see a list of the files searched for.
>>
>>     utils/haddock/haddock-api/src/Haddock/GhcUtils.hs:29:1: error:
>>         Failed to load interface for ?HscTypes?
>>         It is a member of the hidden package ?ghc-8.1?.
>>         Use -v to see a list of the files searched for.
>>
>>     utils/haddock/haddock-api/src/Haddock/GhcUtils.hs:30:1: error:
>>         Failed to load interface for ?UniqFM?
>>         It is a member of the hidden package ?ghc-8.1?.
>>         Use -v to see a list of the files searched for.
>>
>>     utils/haddock/haddock-api/src/Haddock/GhcUtils.hs:31:1: error:
>>         Failed to load interface for ?GHC?
>>         It is a member of the hidden package ?ghc-8.1?.
>>         Use -v to see a list of the files searched for.
>>
>>     utils/haddock/haddock-api/src/Haddock/GhcUtils.hs:32:1: error:
>>         Failed to load interface for ?Class?
>>         It is a member of the hidden package ?ghc-8.1?.
>>         Use -v to see a list of the files searched for.
>>     utils/haddock/ghc.mk:21: recipe for target
>> 'utils/haddock/dist/build/ResponseFile.dyn_o' failed
>>     make[1]: *** [utils/haddock/dist/build/ResponseFile.dyn_o] Error 1
>>     make[1]: *** Waiting for unfinished jobs....
>>     utils/haddock/ghc.mk:21: recipe for target
>> 'utils/haddock/dist/build/Documentation/Haddock/Types.dyn_o' failed
>>     make[1]: ***
>> [utils/haddock/dist/build/Documentation/Haddock/Types.dyn_o] Error 1
>>     utils/haddock/ghc.mk:21: recipe for target
>> 'utils/haddock/dist/build/Haddock/Backends/Hyperlinker/Types.dyn_o'
>> failed
>>     make[1]: ***
>> [utils/haddock/dist/build/Haddock/Backends/Hyperlinker/Types.dyn_o]
>> Error 1
>>     utils/haddock/ghc.mk:21: recipe for target
>> 'utils/haddock/dist/build/Haddock/GhcUtils.dyn_o' failed
>>     make[1]: *** [utils/haddock/dist/build/Haddock/GhcUtils.dyn_o] Error 1
>>     Makefile:129: recipe for target 'all' failed
>>     make: *** [all] Error 2
>>     ( make distclean && ./boot && ./configure && make -j4; ) 2>&1
>> 6382.95s user 1069.99s system 336% cpu 36:57.03 total
>>     tee build_output  0.04s user 0.60s system 0% cpu 36:57.03 total
>>
>> This is d40682e + one commit that I'm sure wouldn't break the build this way. I
>> can't compile anything with stage2 compiler becuase of this:
>>
>>     ?  strict_cmm ghc-stage2 Main.hs
>>     [1 of 1] Compiling Lib              ( Main.hs, Main.o ) [Prelude changed]
>>
>>     Main.hs:4:1: error:
>>         Failed to load interface for ?Prelude?
>>         It is a member of the hidden package ?base-4.9.0.0?.
>>         Use -v to see a list of the files searched for.
>>
>> -v output:
>>
>>     ?  strict_cmm ghc-stage2 Main.hs -v
>>     Glasgow Haskell Compiler, Version 8.1.20160528, stage 2 booted by
>> GHC version 8.0.1
>>     Using binary package database:
>> /home/omer/haskell/ghc_3/inplace/lib/package.conf.d/package.cache
>>     loading package database /home/omer/haskell/ghc_3/inplace/lib/package.conf.d
>>     wired-in package ghc-prim mapped to ghc-prim-0.5.0.0
>>     wired-in package integer-gmp mapped to integer-gmp-1.0.0.1
>>     wired-in package base mapped to base-4.9.0.0
>>     wired-in package rts mapped to rts
>>     wired-in package template-haskell mapped to template-haskell-2.11.0.0
>>     wired-in package ghc mapped to ghc-8.1
>>     wired-in package dph-seq not found.
>>     wired-in package dph-par not found.
>>     Hsc static flags:
>>     loading package database /home/omer/haskell/ghc_3/inplace/lib/package.conf.d
>>     wired-in package ghc-prim mapped to ghc-prim-0.5.0.0
>>     wired-in package integer-gmp mapped to integer-gmp-1.0.0.1
>>     wired-in package base mapped to base-4.9.0.0
>>     wired-in package rts mapped to rts-1.0
>>     wired-in package template-haskell mapped to template-haskell-2.11.0.0
>>     wired-in package ghc mapped to ghc-8.1
>>     wired-in package dph-seq not found.
>>     wired-in package dph-par not found.
>>     *** Chasing dependencies:
>>     Chasing modules from: *Main.hs
>>     !!! Chasing dependencies: finished in 0.44 milliseconds, allocated
>> 0.417 megabytes
>>     Stable obj: [Lib]
>>     Stable BCO: []
>>     Ready for upsweep
>>       [NONREC
>>           ModSummary {
>>              ms_hs_date = 2016-05-28 13:53:06.703533428 UTC
>>              ms_mod = Lib,
>>              ms_textual_imps = [(Nothing, Prelude)]
>>              ms_srcimps = []
>>           }]
>>     *** Deleting temp files:
>>     Deleting:
>>     compile: input file Main.hs
>>     *** Checking old interface for Lib:
>>     [1 of 1] Compiling Lib              ( Main.hs, Main.o ) [Prelude changed]
>>     *** Parser [Lib]:
>>     !!! Parser [Lib]: finished in 0.42 milliseconds, allocated 0.466 megabytes
>>     *** Renamer/typechecker [Lib]:
>>     !!! Renamer/typechecker [Lib]: finished in 0.05 milliseconds,
>> allocated 0.004 megabytes
>>
>>     Main.hs:4:1: error:
>>         Failed to load interface for ?Prelude?
>>         It is a member of the hidden package ?base-4.9.0.0?.
>>         Locations searched:
>>           Prelude.hs
>>           Prelude.lhs
>>           Prelude.hsig
>>           Prelude.lhsig
>>     Upsweep partially successful.
>>     *** Deleting temp files:
>>     Deleting:
>>     link(batch): upsweep (partially) failed OR
>>        Main.main not exported; not linking.
>>     *** Deleting temp files:
>>     Deleting:
>>     *** Deleting temp dirs:
>>     Deleting:
>>
>> Any ideas?

From omeragacan at gmail.com  Sat May 28 22:14:29 2016
From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=)
Date: Sat, 28 May 2016 18:14:29 -0400
Subject: comment lines in Cmm outputs
Message-ID: <CAMQQO3kEPQpgwudj9-rPGg+RsfCT5hRyXnTYK3sPN=-4hzYcaA@mail.gmail.com>

I'm reading a lot of Cmm  these days and comments added by Cmm dump (which are
apparently added after 8.0.1) are so annoying becuase they're not saying
anything useful (what's the point of adding "// CmmCall" to a "call" line or
"// CmmCondBranch" to a "if" line?) but making a lot of noise. Why were those
added? Can we remove them?

From david.feuer at gmail.com  Sun May 29 00:00:20 2016
From: david.feuer at gmail.com (David Feuer)
Date: Sat, 28 May 2016 20:00:20 -0400
Subject: Strictness/laziness warnings
In-Reply-To: <CAMgWh9uWZd2Hn0t6XTEkJQmWE_jtHsFZTcn2sH7ndXaUvjUQwg@mail.gmail.com>
References: <CAMgWh9vN5_M72cfJZka3v660_AFoW0_nZqtwr3ViAa+atg2wEg@mail.gmail.com>
 <CAMgWh9vRqRgNx6ZQt0Pj-ArGtoejGrx8zarP7mht6+7Cp7FRtA@mail.gmail.com>
 <CAMgWh9tQMLGCmHjiTeSe0cs7FhS==HMudt0o9bA+vzUEL=XoEQ@mail.gmail.com>
 <CAMgWh9ur-tJYV-D5xaY+TT2R-__cs92YC9ueMX1SCz1fw0gRHA@mail.gmail.com>
 <CAMgWh9s_-oeVEoi1Tq4gANrmg+wok-kS6W8_KV44yURijpcgxw@mail.gmail.com>
 <CAMgWh9uTLcDmgLYECoz0BVj1rsJGDpnd4n2tc3nEq9s5PKE=3Q@mail.gmail.com>
 <CAMgWh9tX0yjHaTXVREH4XCwWMSc+Xv_vvfELxSFB2MW3TShG6A@mail.gmail.com>
 <CAMgWh9tGf3mm5uNMeCday7PPPMehEoZWiK6amda-g1OyBHrdgg@mail.gmail.com>
 <CAMgWh9vT3m1yK3iZy5h72rFFbJxZ9zQgG5Ofd_4K3YTU9gA9hA@mail.gmail.com>
 <CAMgWh9sLDuqXRw7YkvA6_4O6sa_jQfjWxOiMKO6YrL=RW+H67Q@mail.gmail.com>
 <CAMgWh9s_cfstCnHDa=ppXdTVLH5qMD8A449Hobho5kscTDeVcw@mail.gmail.com>
 <CAMgWh9uQ3E=M2ewWDCw4-5ppu3GvyNO2G2xiOatctL8Hzdy86Q@mail.gmail.com>
 <CAMgWh9u6z6s8ewChQsha_p0-wWp=JSdHjQDUi4aiych1Y=2CcQ@mail.gmail.com>
 <CAMgWh9tU_7fvJotKUzLv0VwcMCLb2x-52chH5Vb804snk5Xagw@mail.gmail.com>
 <CAMgWh9vYKKCWCHzwDNqovzJFUJsEGXqPDFsVGzX3hdOQ0ZxRUQ@mail.gmail.com>
 <CAMgWh9uWZd2Hn0t6XTEkJQmWE_jtHsFZTcn2sH7ndXaUvjUQwg@mail.gmail.com>
Message-ID: <CAMgWh9tU_AEFho7TajE8RZB08ywCMDRhGgVgAKEOWKS9x1jz6g@mail.gmail.com>

There are certain patterns of strictness or laziness that signal the need
for extra caution. I'm wondering whether it might be possible to offer
warnings for different varieties of them, and pragmas suppressing the
warnings at the relevant sites. Some function behaviors that suggest extra
care:

1. Conditionally strict in an argument. In many cases, making it
unconditionally strict will improve performance.
2. Strict in an argument that is or could be a function or a newtype
wrapper around a function. This can be caused by  adding too much
strictness defensively or to plug a leak.
3. Lazy in a primitive argument like an Int. This could lead to unnecessary
boxing.

Any of these could occur in correct, efficient code. But I'd love to be
presented a list of warnings to check over, and a way to check items off
the list with pragmas.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160528/d71d6d36/attachment.html>

From anthony_clayden at clear.net.nz  Sun May 29 00:19:23 2016
From: anthony_clayden at clear.net.nz (AntC)
Date: Sun, 29 May 2016 00:19:23 +0000 (UTC)
Subject: Unpacking single-field,
 single-strict-constructor GADTs and existentials
References: <CAMgWh9uqPCqEqwzp6TvyprN0NGvSJ74SkreyVJEK4YEy+EpGfA@mail.gmail.com>
 <CAMgWh9u=vpNvkwyYtND7brF94EOEEkctdKva5GYtaCLpLbjEvA@mail.gmail.com>
 <CAMgWh9sMsaPA9g2f-2J9FKFHDf+Juf_HDHQy9oZc34nNF=QCJQ@mail.gmail.com>
 <CAMgWh9vZfdo_fKxWWw_s0PTmnGVKqEMQWfaruGkBJB38Lojbtw@mail.gmail.com>
 <CAMgWh9vutqciKs2-U62JLnQUaT7M0uz23inw0ju_xFi+ew92VA@mail.gmail.com>
 <CAMgWh9tr2wG3HT-SY9xtmauHHovVrsCLTo-pBp2+T-9VrhC-ig@mail.gmail.com>
 <CAMgWh9tLi3Gu=8RGWXH9OQLJ6DB=UdM+1MzOvMB_QTFhnQanYg@mail.gmail.com>
 <CAMgWh9veyXkZKSHVKPh6n4-5hy7mhd7n2v53O7h8XYCa7-Q-dQ@mail.gmail.com>
 <CAMgWh9uFVR9kypsEw0oLYmEaQnC8Y1ory7KT18FMRS-fnmE=oQ@mail.gmail.com>
 <CAMgWh9uneS8k1xEM1dYJCmR8cuf8V5s_Ssci21v=PONVJ_t21A@mail.gmail.com>
 <CAMgWh9vsPZbunmEY37rQgvtLjbbspwsrUzNFQYYxco2eyR2J=Q@mail.gmail.com>
 <CAMgWh9u5Jtz30fOrKdd1vXWvOWVkTCaRSahN2R_mMxuxhhc7yA@mail.gmail.com>
 <CAMgWh9uFmuNpNXAXPcj25gOQz66Fud9StT0m8gYrN-tj3Gy4dw@mail.gmail.com>
 <CAMgWh9uYcrNZ17R1H=J8dR=BdqWH7xekt349wFjcTADim3=RVg@mail.gmail.com>
 <CAMgWh9tffEs-3PHWzxhQc2UkL+jyv+wp1=dF4mFEEo2m_m2e2w@mail.gmail.com>
 <CAMgWh9snErv1oEFyv5UhG_JSUfVT3FO1HHA9N2x9AOU7eSW6tA@mail.gmail.com>
 <87vb23vpjj.fsf@smart-cactus.org>
 <CAMgWh9vt89=-qiXntY_fbY9dxCDrgVAwXXhd=UGbymaUA6ogMA@mail.gmail.com>
 <87h9dnv23t.fsf@smart-cactus.org>
 <CAMgWh9s5qrFgkTfTtFtfTzDdEXXm5PJsmmUDfBf2nDKX8-Ky8g@mail.gmail.com>
 <CAHYVw0zLUP5ObmHrGzh6_20n=H-abUkxpObHKz323s7b-SwZhQ@mail.gmail.com>
 <CAMgWh9v5U=u2UtOPMomf+Rm-KM+j-mg3u++bEv1d+fzoGjrrEA@mail.gmail.com>
 <2e3117c3f21c452d867dc2919b7aac03@DB4PR30MB030.064d.mgd.msft.net>
 <CAMgWh9uaxtrmPLHJw7eErxfy9OZBkONR1zrzVhoN1gqVRdKiyw@mail.gmail.com>
 <18dc87c3550a4f2fade4bc668718ec1f@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <loom.20160529T020815-733@post.gmane.org>

> Simon Peyton Jones <simonpj <at> microsoft.com> writes:
> 
> Oh, that's helpful thank you.  I have added comments!
> 

I've added a further use case (Example 3 -- from my one-eyed focus on Records).

And apologies if these are two dumb questions, but is there a bigger prize here?

If we can figure out rules for when a GADT can be 'newtype'd; 
then can we also figure it out for ordinary 'data'?

Then 'newtype' becomes more of an optimisation pragma
than a distinct declaration.

And we can smooth over that nervous cluelessness for newbies
agonising about what/whether they can newtype.
(Ref the examples in Haskell 12010 report 4.2.3.)

Also: are the conditions under which we can newtype a GADT
also the conditions under which we can implement deriving ...
That is, deriving as part of the decl, rather than standalone.
(A Summer-of-code project?)

AntC


From ekmett at gmail.com  Sun May 29 01:16:27 2016
From: ekmett at gmail.com (Edward Kmett)
Date: Sat, 28 May 2016 21:16:27 -0400
Subject: Strictness/laziness warnings
In-Reply-To: <CAMgWh9tU_AEFho7TajE8RZB08ywCMDRhGgVgAKEOWKS9x1jz6g@mail.gmail.com>
References: <CAMgWh9vN5_M72cfJZka3v660_AFoW0_nZqtwr3ViAa+atg2wEg@mail.gmail.com>
 <CAMgWh9vRqRgNx6ZQt0Pj-ArGtoejGrx8zarP7mht6+7Cp7FRtA@mail.gmail.com>
 <CAMgWh9tQMLGCmHjiTeSe0cs7FhS==HMudt0o9bA+vzUEL=XoEQ@mail.gmail.com>
 <CAMgWh9ur-tJYV-D5xaY+TT2R-__cs92YC9ueMX1SCz1fw0gRHA@mail.gmail.com>
 <CAMgWh9s_-oeVEoi1Tq4gANrmg+wok-kS6W8_KV44yURijpcgxw@mail.gmail.com>
 <CAMgWh9uTLcDmgLYECoz0BVj1rsJGDpnd4n2tc3nEq9s5PKE=3Q@mail.gmail.com>
 <CAMgWh9tX0yjHaTXVREH4XCwWMSc+Xv_vvfELxSFB2MW3TShG6A@mail.gmail.com>
 <CAMgWh9tGf3mm5uNMeCday7PPPMehEoZWiK6amda-g1OyBHrdgg@mail.gmail.com>
 <CAMgWh9vT3m1yK3iZy5h72rFFbJxZ9zQgG5Ofd_4K3YTU9gA9hA@mail.gmail.com>
 <CAMgWh9sLDuqXRw7YkvA6_4O6sa_jQfjWxOiMKO6YrL=RW+H67Q@mail.gmail.com>
 <CAMgWh9s_cfstCnHDa=ppXdTVLH5qMD8A449Hobho5kscTDeVcw@mail.gmail.com>
 <CAMgWh9uQ3E=M2ewWDCw4-5ppu3GvyNO2G2xiOatctL8Hzdy86Q@mail.gmail.com>
 <CAMgWh9u6z6s8ewChQsha_p0-wWp=JSdHjQDUi4aiych1Y=2CcQ@mail.gmail.com>
 <CAMgWh9tU_7fvJotKUzLv0VwcMCLb2x-52chH5Vb804snk5Xagw@mail.gmail.com>
 <CAMgWh9vYKKCWCHzwDNqovzJFUJsEGXqPDFsVGzX3hdOQ0ZxRUQ@mail.gmail.com>
 <CAMgWh9uWZd2Hn0t6XTEkJQmWE_jtHsFZTcn2sH7ndXaUvjUQwg@mail.gmail.com>
 <CAMgWh9tU_AEFho7TajE8RZB08ywCMDRhGgVgAKEOWKS9x1jz6g@mail.gmail.com>
Message-ID: <CAJumaK9gEjasenAFguRFF-unOsZPkH8eZKD4fO2aiMSpQWyuog@mail.gmail.com>

I have code that'd trip at least 2&3 in use in production. #2 arises for
some tricks that Wren first introduced me to for loop invariant code
motion. #3 arises when you want to memoize a result but only produce it
lazily in case it isn't used. I don't quite understand what you mean by
"conditionally strict" in an argument though.

-Edward

On Sat, May 28, 2016 at 8:00 PM, David Feuer <david.feuer at gmail.com> wrote:

> There are certain patterns of strictness or laziness that signal the need
> for extra caution. I'm wondering whether it might be possible to offer
> warnings for different varieties of them, and pragmas suppressing the
> warnings at the relevant sites. Some function behaviors that suggest extra
> care:
>
> 1. Conditionally strict in an argument. In many cases, making it
> unconditionally strict will improve performance.
> 2. Strict in an argument that is or could be a function or a newtype
> wrapper around a function. This can be caused by  adding too much
> strictness defensively or to plug a leak.
> 3. Lazy in a primitive argument like an Int. This could lead to
> unnecessary boxing.
>
> Any of these could occur in correct, efficient code. But I'd love to be
> presented a list of warnings to check over, and a way to check items off
> the list with pragmas.
>
> _______________________________________________
> 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/20160528/17c9aa2b/attachment-0001.html>

From david.feuer at gmail.com  Sun May 29 02:02:32 2016
From: david.feuer at gmail.com (David Feuer)
Date: Sat, 28 May 2016 22:02:32 -0400
Subject: Strictness/laziness warnings
In-Reply-To: <CAJumaK9gEjasenAFguRFF-unOsZPkH8eZKD4fO2aiMSpQWyuog@mail.gmail.com>
References: <CAMgWh9vN5_M72cfJZka3v660_AFoW0_nZqtwr3ViAa+atg2wEg@mail.gmail.com>
 <CAMgWh9vRqRgNx6ZQt0Pj-ArGtoejGrx8zarP7mht6+7Cp7FRtA@mail.gmail.com>
 <CAMgWh9tQMLGCmHjiTeSe0cs7FhS==HMudt0o9bA+vzUEL=XoEQ@mail.gmail.com>
 <CAMgWh9ur-tJYV-D5xaY+TT2R-__cs92YC9ueMX1SCz1fw0gRHA@mail.gmail.com>
 <CAMgWh9s_-oeVEoi1Tq4gANrmg+wok-kS6W8_KV44yURijpcgxw@mail.gmail.com>
 <CAMgWh9uTLcDmgLYECoz0BVj1rsJGDpnd4n2tc3nEq9s5PKE=3Q@mail.gmail.com>
 <CAMgWh9tX0yjHaTXVREH4XCwWMSc+Xv_vvfELxSFB2MW3TShG6A@mail.gmail.com>
 <CAMgWh9tGf3mm5uNMeCday7PPPMehEoZWiK6amda-g1OyBHrdgg@mail.gmail.com>
 <CAMgWh9vT3m1yK3iZy5h72rFFbJxZ9zQgG5Ofd_4K3YTU9gA9hA@mail.gmail.com>
 <CAMgWh9sLDuqXRw7YkvA6_4O6sa_jQfjWxOiMKO6YrL=RW+H67Q@mail.gmail.com>
 <CAMgWh9s_cfstCnHDa=ppXdTVLH5qMD8A449Hobho5kscTDeVcw@mail.gmail.com>
 <CAMgWh9uQ3E=M2ewWDCw4-5ppu3GvyNO2G2xiOatctL8Hzdy86Q@mail.gmail.com>
 <CAMgWh9u6z6s8ewChQsha_p0-wWp=JSdHjQDUi4aiych1Y=2CcQ@mail.gmail.com>
 <CAMgWh9tU_7fvJotKUzLv0VwcMCLb2x-52chH5Vb804snk5Xagw@mail.gmail.com>
 <CAMgWh9vYKKCWCHzwDNqovzJFUJsEGXqPDFsVGzX3hdOQ0ZxRUQ@mail.gmail.com>
 <CAMgWh9uWZd2Hn0t6XTEkJQmWE_jtHsFZTcn2sH7ndXaUvjUQwg@mail.gmail.com>
 <CAMgWh9tU_AEFho7TajE8RZB08ywCMDRhGgVgAKEOWKS9x1jz6g@mail.gmail.com>
 <CAJumaK9gEjasenAFguRFF-unOsZPkH8eZKD4fO2aiMSpQWyuog@mail.gmail.com>
Message-ID: <CAMgWh9uKxY75_PAG13qSF_cKZ_L+Mn7pK9Y9tjdfUGiJvh9few@mail.gmail.com>

I'm not suggesting these things are *wrong*, and I wouldn't want the
warnings to be included in -Wall. They're just possible areas of concern.
By "conditionally strict" I mean that the argument in question is only
forced sometimes.
On May 28, 2016 9:16 PM, "Edward Kmett" <ekmett at gmail.com> wrote:

> I have code that'd trip at least 2&3 in use in production. #2 arises for
> some tricks that Wren first introduced me to for loop invariant code
> motion. #3 arises when you want to memoize a result but only produce it
> lazily in case it isn't used. I don't quite understand what you mean by
> "conditionally strict" in an argument though.
>
> -Edward
>
> On Sat, May 28, 2016 at 8:00 PM, David Feuer <david.feuer at gmail.com>
> wrote:
>
>> There are certain patterns of strictness or laziness that signal the need
>> for extra caution. I'm wondering whether it might be possible to offer
>> warnings for different varieties of them, and pragmas suppressing the
>> warnings at the relevant sites. Some function behaviors that suggest extra
>> care:
>>
>> 1. Conditionally strict in an argument. In many cases, making it
>> unconditionally strict will improve performance.
>> 2. Strict in an argument that is or could be a function or a newtype
>> wrapper around a function. This can be caused by  adding too much
>> strictness defensively or to plug a leak.
>> 3. Lazy in a primitive argument like an Int. This could lead to
>> unnecessary boxing.
>>
>> Any of these could occur in correct, efficient code. But I'd love to be
>> presented a list of warnings to check over, and a way to check items off
>> the list with pragmas.
>>
>> _______________________________________________
>> 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/20160528/3f5ff442/attachment.html>

From ekmett at gmail.com  Sun May 29 02:14:26 2016
From: ekmett at gmail.com (Edward Kmett)
Date: Sat, 28 May 2016 22:14:26 -0400
Subject: Strictness/laziness warnings
In-Reply-To: <CAMgWh9uKxY75_PAG13qSF_cKZ_L+Mn7pK9Y9tjdfUGiJvh9few@mail.gmail.com>
References: <CAMgWh9vN5_M72cfJZka3v660_AFoW0_nZqtwr3ViAa+atg2wEg@mail.gmail.com>
 <CAMgWh9vRqRgNx6ZQt0Pj-ArGtoejGrx8zarP7mht6+7Cp7FRtA@mail.gmail.com>
 <CAMgWh9tQMLGCmHjiTeSe0cs7FhS==HMudt0o9bA+vzUEL=XoEQ@mail.gmail.com>
 <CAMgWh9ur-tJYV-D5xaY+TT2R-__cs92YC9ueMX1SCz1fw0gRHA@mail.gmail.com>
 <CAMgWh9s_-oeVEoi1Tq4gANrmg+wok-kS6W8_KV44yURijpcgxw@mail.gmail.com>
 <CAMgWh9uTLcDmgLYECoz0BVj1rsJGDpnd4n2tc3nEq9s5PKE=3Q@mail.gmail.com>
 <CAMgWh9tX0yjHaTXVREH4XCwWMSc+Xv_vvfELxSFB2MW3TShG6A@mail.gmail.com>
 <CAMgWh9tGf3mm5uNMeCday7PPPMehEoZWiK6amda-g1OyBHrdgg@mail.gmail.com>
 <CAMgWh9vT3m1yK3iZy5h72rFFbJxZ9zQgG5Ofd_4K3YTU9gA9hA@mail.gmail.com>
 <CAMgWh9sLDuqXRw7YkvA6_4O6sa_jQfjWxOiMKO6YrL=RW+H67Q@mail.gmail.com>
 <CAMgWh9s_cfstCnHDa=ppXdTVLH5qMD8A449Hobho5kscTDeVcw@mail.gmail.com>
 <CAMgWh9uQ3E=M2ewWDCw4-5ppu3GvyNO2G2xiOatctL8Hzdy86Q@mail.gmail.com>
 <CAMgWh9u6z6s8ewChQsha_p0-wWp=JSdHjQDUi4aiych1Y=2CcQ@mail.gmail.com>
 <CAMgWh9tU_7fvJotKUzLv0VwcMCLb2x-52chH5Vb804snk5Xagw@mail.gmail.com>
 <CAMgWh9vYKKCWCHzwDNqovzJFUJsEGXqPDFsVGzX3hdOQ0ZxRUQ@mail.gmail.com>
 <CAMgWh9uWZd2Hn0t6XTEkJQmWE_jtHsFZTcn2sH7ndXaUvjUQwg@mail.gmail.com>
 <CAMgWh9tU_AEFho7TajE8RZB08ywCMDRhGgVgAKEOWKS9x1jz6g@mail.gmail.com>
 <CAJumaK9gEjasenAFguRFF-unOsZPkH8eZKD4fO2aiMSpQWyuog@mail.gmail.com>
 <CAMgWh9uKxY75_PAG13qSF_cKZ_L+Mn7pK9Y9tjdfUGiJvh9few@mail.gmail.com>
Message-ID: <CAJumaK_4GZqp20JM_hExL=1QsamhpohsGbjf2cbX8txzoPS6pg@mail.gmail.com>

How would you detect the argument only being forced some of the time?
Sounds like a lot of long-term cross-module book-keeping.

-Edward

On Sat, May 28, 2016 at 10:02 PM, David Feuer <david.feuer at gmail.com> wrote:

> I'm not suggesting these things are *wrong*, and I wouldn't want the
> warnings to be included in -Wall. They're just possible areas of concern.
> By "conditionally strict" I mean that the argument in question is only
> forced sometimes.
> On May 28, 2016 9:16 PM, "Edward Kmett" <ekmett at gmail.com> wrote:
>
>> I have code that'd trip at least 2&3 in use in production. #2 arises for
>> some tricks that Wren first introduced me to for loop invariant code
>> motion. #3 arises when you want to memoize a result but only produce it
>> lazily in case it isn't used. I don't quite understand what you mean by
>> "conditionally strict" in an argument though.
>>
>> -Edward
>>
>> On Sat, May 28, 2016 at 8:00 PM, David Feuer <david.feuer at gmail.com>
>> wrote:
>>
>>> There are certain patterns of strictness or laziness that signal the
>>> need for extra caution. I'm wondering whether it might be possible to offer
>>> warnings for different varieties of them, and pragmas suppressing the
>>> warnings at the relevant sites. Some function behaviors that suggest extra
>>> care:
>>>
>>> 1. Conditionally strict in an argument. In many cases, making it
>>> unconditionally strict will improve performance.
>>> 2. Strict in an argument that is or could be a function or a newtype
>>> wrapper around a function. This can be caused by  adding too much
>>> strictness defensively or to plug a leak.
>>> 3. Lazy in a primitive argument like an Int. This could lead to
>>> unnecessary boxing.
>>>
>>> Any of these could occur in correct, efficient code. But I'd love to be
>>> presented a list of warnings to check over, and a way to check items off
>>> the list with pragmas.
>>>
>>> _______________________________________________
>>> 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/20160528/8526f5de/attachment.html>

From ben at smart-cactus.org  Sun May 29 15:14:52 2016
From: ben at smart-cactus.org (Ben Gamari)
Date: Sun, 29 May 2016 17:14:52 +0200
Subject: comment lines in Cmm outputs
In-Reply-To: <CAMQQO3kEPQpgwudj9-rPGg+RsfCT5hRyXnTYK3sPN=-4hzYcaA@mail.gmail.com>
References: <CAMQQO3kEPQpgwudj9-rPGg+RsfCT5hRyXnTYK3sPN=-4hzYcaA@mail.gmail.com>
Message-ID: <878tysopzn.fsf@smart-cactus.org>

?mer Sinan A?acan <omeragacan at gmail.com> writes:

> I'm reading a lot of Cmm  these days and comments added by Cmm dump (which are
> apparently added after 8.0.1) are so annoying becuase they're not saying
> anything useful (what's the point of adding "// CmmCall" to a "call" line or
> "// CmmCondBranch" to a "if" line?) but making a lot of noise. Why were those
> added? Can we remove them?

It looks like they've been with us since the initial merge of the new
codegen. I agree that they don't add much value but I don't have any
strong opinion either way. The only comment that we might want to
retain is the one for CmmUnsafeForeignCall as it looks quite similar to
a CmmCall.

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/20160529/88baf616/attachment.sig>

From mgoremeier at gmail.com  Sun May 29 16:47:15 2016
From: mgoremeier at gmail.com (Michael Karg)
Date: Sun, 29 May 2016 18:47:15 +0200
Subject: Rank2Types example not typechecking w/ GHC8. Bug or feature?
Message-ID: <CAK7-0znhUVBJ-+yVXNE2vhHkm+=7p9t95NLtC5+PFjd+4GzB9g@mail.gmail.com>

Hi devs,

could you please have a look at the following code snippet (modeled after a
real-world app of mine)? There's a rank2type involved, and it doesn't
type-check anymore when the type is e.g. part of a tuple, whereas
everything's fine when it's the "outermost" type.

With GHC7.10 both variants type-check. Could anyone shed some light on
what's behind this? Is the way the types are used in the snippet considered
dispreferred or wrong under GHC8?

Thanks for having a look and hopefully pointing me to a page/ticket/...
providing insight,
Michael

--------

{-# LANGUAGE Rank2Types #-}

module TestTypes where

data State a        = State a

data Dummy          = Dummy

type Handler result = forall state . State state -> IO result

type Resolver       = String -> Handler String


eventRouter :: Resolver -> String -> IO ()
eventRouter resolver event =
    resolver event state >> return ()
  where
    state :: State ()
    state = undefined

{-
-- does type check
createResolver :: Resolver
createResolver = \event state -> return "result"

processor :: IO ()
processor =
    getLine >>= eventRouter resolver >> processor
  where
    resolver = createResolver
-}


-- does not type check when the rank 2 type isn't the "outermost" one?
createResolver :: (Resolver, Dummy)
createResolver = (\event state -> return "result", Dummy)

processor :: IO ()
processor =
    getLine >>= eventConsumer resolver >> processor
  where
    (resolver, _) = createResolver

{-
    ? Couldn't match type ?t? with ?Resolver?
      ?t? is a rigid type variable bound by
        the inferred type of resolver :: t at TestTypes.hs:41:5
      Expected type: (t, Dummy)
        Actual type: (Resolver, Dummy)
-}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160529/b6fb7091/attachment.html>

From ggreif at gmail.com  Sun May 29 18:02:39 2016
From: ggreif at gmail.com (Gabor Greif)
Date: Sun, 29 May 2016 20:02:39 +0200
Subject: Rank2Types example not typechecking w/ GHC8. Bug or feature?
In-Reply-To: <CAK7-0znhUVBJ-+yVXNE2vhHkm+=7p9t95NLtC5+PFjd+4GzB9g@mail.gmail.com>
References: <CAK7-0znhUVBJ-+yVXNE2vhHkm+=7p9t95NLtC5+PFjd+4GzB9g@mail.gmail.com>
Message-ID: <CAK-hX0k44wHdfT7k6BvY_o6v3XLpC=Z4EjL8GFAcE4heMT2A=w@mail.gmail.com>

The same bug has bitten git-annex too. IIRC.

Cheers,

    Gabor

Em domingo, 29 de maio de 2016, Michael Karg <mgoremeier at gmail.com>
escreveu:

> Hi devs,
>
> could you please have a look at the following code snippet (modeled after
> a real-world app of mine)? There's a rank2type involved, and it doesn't
> type-check anymore when the type is e.g. part of a tuple, whereas
> everything's fine when it's the "outermost" type.
>
> With GHC7.10 both variants type-check. Could anyone shed some light on
> what's behind this? Is the way the types are used in the snippet considered
> dispreferred or wrong under GHC8?
>
> Thanks for having a look and hopefully pointing me to a page/ticket/...
> providing insight,
> Michael
>
> --------
>
> {-# LANGUAGE Rank2Types #-}
>
> module TestTypes where
>
> data State a        = State a
>
> data Dummy          = Dummy
>
> type Handler result = forall state . State state -> IO result
>
> type Resolver       = String -> Handler String
>
>
> eventRouter :: Resolver -> String -> IO ()
> eventRouter resolver event =
>     resolver event state >> return ()
>   where
>     state :: State ()
>     state = undefined
>
> {-
> -- does type check
> createResolver :: Resolver
> createResolver = \event state -> return "result"
>
> processor :: IO ()
> processor =
>     getLine >>= eventRouter resolver >> processor
>   where
>     resolver = createResolver
> -}
>
>
> -- does not type check when the rank 2 type isn't the "outermost" one?
> createResolver :: (Resolver, Dummy)
> createResolver = (\event state -> return "result", Dummy)
>
> processor :: IO ()
> processor =
>     getLine >>= eventConsumer resolver >> processor
>   where
>     (resolver, _) = createResolver
>
> {-
>     ? Couldn't match type ?t? with ?Resolver?
>       ?t? is a rigid type variable bound by
>         the inferred type of resolver :: t at TestTypes.hs:41:5
>       Expected type: (t, Dummy)
>         Actual type: (Resolver, Dummy)
> -}
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160529/d5db4ce7/attachment.html>

From adam at well-typed.com  Sun May 29 18:18:53 2016
From: adam at well-typed.com (Adam Gundry)
Date: Sun, 29 May 2016 19:18:53 +0100
Subject: Rank2Types example not typechecking w/ GHC8. Bug or feature?
In-Reply-To: <CAK7-0znhUVBJ-+yVXNE2vhHkm+=7p9t95NLtC5+PFjd+4GzB9g@mail.gmail.com>
References: <CAK7-0znhUVBJ-+yVXNE2vhHkm+=7p9t95NLtC5+PFjd+4GzB9g@mail.gmail.com>
Message-ID: <2f35ab0f-1491-9549-23a1-8a2bcfc30f72@well-typed.com>

Hi Michael,

I think that GHC 8 is correct to reject this program without
ImpredicativeTypes (and if you enable ImpredicativeTypes, all bets are
off). Previous versions incorrectly accepted such programs, because they
didn't look through type synonyms. If you expand the type of the second
createResolver, you get

    ((String -> forall state . State state -> IO String), Dummy)

which has a quantified type in the first argument of the pair (i.e. it
requires impredicativity). See ticket #10194 for more details.

All the best,

Adam


On 29/05/16 17:47, Michael Karg wrote:
> Hi devs,
> 
> could you please have a look at the following code snippet (modeled
> after a real-world app of mine)? There's a rank2type involved, and it
> doesn't type-check anymore when the type is e.g. part of a tuple,
> whereas everything's fine when it's the "outermost" type.
> 
> With GHC7.10 both variants type-check. Could anyone shed some light on
> what's behind this? Is the way the types are used in the snippet
> considered dispreferred or wrong under GHC8?
> 
> Thanks for having a look and hopefully pointing me to a page/ticket/...
> providing insight,
> Michael
> 
> --------
> 
> {-# LANGUAGE Rank2Types #-}
> 
> module TestTypes where
> 
> data State a        = State a
> 
> data Dummy          = Dummy
> 
> type Handler result = forall state . State state -> IO result
> 
> type Resolver       = String -> Handler String
> 
> 
> eventRouter :: Resolver -> String -> IO ()
> eventRouter resolver event =
>     resolver event state >> return ()
>   where
>     state :: State ()
>     state = undefined
> 
> {-
> -- does type check
> createResolver :: Resolver
> createResolver = \event state -> return "result"
> 
> processor :: IO ()
> processor =
>     getLine >>= eventRouter resolver >> processor
>   where
>     resolver = createResolver
> -}
> 
> 
> -- does not type check when the rank 2 type isn't the "outermost" one?
> createResolver :: (Resolver, Dummy)
> createResolver = (\event state -> return "result", Dummy)
> 
> processor :: IO ()
> processor =
>     getLine >>= eventConsumer resolver >> processor
>   where
>     (resolver, _) = createResolver
> 
> {-
>     ? Couldn't match type ?t? with ?Resolver?
>       ?t? is a rigid type variable bound by
>         the inferred type of resolver :: t at TestTypes.hs:41:5
>       Expected type: (t, Dummy)
>         Actual type: (Resolver, Dummy)
> -}


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

From oleg.grenrus at iki.fi  Sun May 29 18:20:01 2016
From: oleg.grenrus at iki.fi (Oleg Grenrus)
Date: Sun, 29 May 2016 21:20:01 +0300
Subject: Rank2Types example not typechecking w/ GHC8. Bug or feature?
In-Reply-To: <CAK-hX0k44wHdfT7k6BvY_o6v3XLpC=Z4EjL8GFAcE4heMT2A=w@mail.gmail.com>
References: <CAK7-0znhUVBJ-+yVXNE2vhHkm+=7p9t95NLtC5+PFjd+4GzB9g@mail.gmail.com>
 <CAK-hX0k44wHdfT7k6BvY_o6v3XLpC=Z4EjL8GFAcE4heMT2A=w@mail.gmail.com>
Message-ID: <54B7543D-12E8-4E00-8115-0A5D4E3E2D38@iki.fi>

The non-outer variant works, because then there aren?t higher rank types at all, i.e. `state` of `Handler` is free to flow outwards.

There is two ways to fix issue: Either use `newtype` or use `ImpredicativeTypes`

?

{-# LANGUAGE RankNTypes #-}

module TestTypes where

data State a        = State a

data Dummy          = Dummy

newtype Handler result = Handler { runHandler :: forall state . State state -> IO result }

type Resolver       = String -> Handler String

eventRouter :: Resolver -> String -> IO ()
eventRouter resolver event =
    runHandler (resolver event) state >> return ()
  where
    state :: State ()
    state = undefined

{-
-- does type check
createResolver :: Resolver
createResolver = \event state -> return "result"

processor :: IO ()
processor =
    getLine >>= eventRouter resolver >> processor
  where
    resolver = createResolver
-}

eventConsumer :: Resolver -> String -> IO ()
eventConsumer = undefined
{-
rank2.hs:34:17: error:
    ? Cannot instantiate unification variable ?a0?
      with a type involving foralls: Resolver -> String -> IO ()
        GHC doesn't yet support impredicative polymorphism
    ? In the expression: undefined
      In an equation for ?eventConsumer?: eventConsumer = undefined
-}

-- does not type check when the rank 2 type isn't the "outermost" one?
createResolver :: (Resolver, Dummy)
createResolver = (\event -> Handler $ \state -> return "result", Dummy)

processor :: IO ()
processor =
    getLine >>= eventConsumer resolver >> processor
  where
    resolver :: Resolver
    resolver = fst (createResolver :: (Resolver, Dummy))

{-
    ? Couldn't match type ?t? with ?Resolver?
      ?t? is a rigid type variable bound by
        the inferred type of resolver :: t at TestTypes.hs:41:5
      Expected type: (t, Dummy)
        Actual type: (Resolver, Dummy)
-}

---

> On 29 May 2016, at 21:02, Gabor Greif <ggreif at gmail.com> wrote:
> 
> The same bug has bitten git-annex too. IIRC.
> 
> Cheers,
> 
>     Gabor
> 
> Em domingo, 29 de maio de 2016, Michael Karg <mgoremeier at gmail.com <mailto:mgoremeier at gmail.com>> escreveu:
> Hi devs,
> 
> could you please have a look at the following code snippet (modeled after a real-world app of mine)? There's a rank2type involved, and it doesn't type-check anymore when the type is e.g. part of a tuple, whereas everything's fine when it's the "outermost" type.
> 
> With GHC7.10 both variants type-check. Could anyone shed some light on what's behind this? Is the way the types are used in the snippet considered dispreferred or wrong under GHC8?
> 
> Thanks for having a look and hopefully pointing me to a page/ticket/... providing insight,
> Michael
> 
> --------
> 
> {-# LANGUAGE Rank2Types #-}
> 
> module TestTypes where
> 
> data State a        = State a
> 
> data Dummy          = Dummy
> 
> type Handler result = forall state . State state -> IO result
> 
> type Resolver       = String -> Handler String
> 
> 
> eventRouter :: Resolver -> String -> IO ()
> eventRouter resolver event =
>     resolver event state >> return ()
>   where
>     state :: State ()
>     state = undefined
> 
> {-
> -- does type check
> createResolver :: Resolver
> createResolver = \event state -> return "result"
> 
> processor :: IO ()
> processor =
>     getLine >>= eventRouter resolver >> processor
>   where
>     resolver = createResolver
> -}
> 
> 
> -- does not type check when the rank 2 type isn't the "outermost" one?
> createResolver :: (Resolver, Dummy)
> createResolver = (\event state -> return "result", Dummy)
> 
> processor :: IO ()
> processor =
>     getLine >>= eventConsumer resolver >> processor
>   where
>     (resolver, _) = createResolver
> 
> {-
>     ? Couldn't match type ?t? with ?Resolver?
>       ?t? is a rigid type variable bound by
>         the inferred type of resolver :: t at TestTypes.hs:41:5
>       Expected type: (t, Dummy)
>         Actual type: (Resolver, Dummy)
> -}
> 
> 
> _______________________________________________
> 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/20160529/e51c3a36/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160529/e51c3a36/attachment-0001.sig>

From eir at cis.upenn.edu  Sun May 29 18:23:38 2016
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Sun, 29 May 2016 14:23:38 -0400
Subject: real person believed to be a spambot
Message-ID: <AC8272EE-3638-400C-915A-5AB6166878A8@cis.upenn.edu>

Hi devs,

I'm forwarding the following from a friend (cc'd) who was unable to register for Trac. Can anyone help?

----

Hi.  I tried to register with username "j6carey" and email "j6carey at gmail.com" to report a bug in GHC 8.0.1, and the system says there's a 97% chance I'm a spammer.  It asked me a question first ("What does the G stand for in GHC?"), and I thought I answered correctly, in lowercase as requested, but it still rejected me, and now it won't even ask that question again (for the same browser, at least).

Do you know what's going wrong?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160529/168e4c54/attachment.html>

From ben at smart-cactus.org  Sun May 29 18:40:24 2016
From: ben at smart-cactus.org (Ben Gamari)
Date: Sun, 29 May 2016 20:40:24 +0200
Subject: real person believed to be a spambot
In-Reply-To: <AC8272EE-3638-400C-915A-5AB6166878A8@cis.upenn.edu>
References: <AC8272EE-3638-400C-915A-5AB6166878A8@cis.upenn.edu>
Message-ID: <8737p0ogh3.fsf@smart-cactus.org>

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

> Hi devs,
>
> I'm forwarding the following from a friend (cc'd) who was unable to register for Trac. Can anyone help?
>
> ----
>
> Hi.  I tried to register with username "j6carey" and email "j6carey at gmail.com" to report a bug in GHC 8.0.1, and the system says there's a 97% chance I'm a spammer.  It asked me a question first ("What does the G stand for in GHC?"), and I thought I answered correctly, in lowercase as requested, but it still rejected me, and now it won't even ask that question again (for the same browser, at least).
>
> Do you know what's going wrong?

Oh dear, it seems that our spam filter seems to be a bit overzealous.
Thanks for reporting this!

I've tried training your events as ham. Could you try again?

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/20160529/99de5a80/attachment.sig>

From mgoremeier at gmail.com  Sun May 29 18:52:44 2016
From: mgoremeier at gmail.com (Michael Karg)
Date: Sun, 29 May 2016 20:52:44 +0200
Subject: Rank2Types example not typechecking w/ GHC8. Bug or feature?
In-Reply-To: <54B7543D-12E8-4E00-8115-0A5D4E3E2D38@iki.fi>
References: <CAK7-0znhUVBJ-+yVXNE2vhHkm+=7p9t95NLtC5+PFjd+4GzB9g@mail.gmail.com>
 <CAK-hX0k44wHdfT7k6BvY_o6v3XLpC=Z4EjL8GFAcE4heMT2A=w@mail.gmail.com>
 <54B7543D-12E8-4E00-8115-0A5D4E3E2D38@iki.fi>
Message-ID: <CAK7-0z=DsCWgDFhrpmpdTuVCyj_-KcAmo0g73ezkFHv9dVaYKQ@mail.gmail.com>

Hi all,

thank you for the quick response.
Since ImpredicativeTypes is not a road I want to go down, a newtype instead
of a type synonym seems like the best bet for that particular case.

Avoiding impredicativity "by accident" makes complete sense to me. I just
thought to bring up the example on the list, since there's a clear change
from GHC7 regarding which programs are accepted and which are not.

Thx again + enjoy the rest of the weekend
M.



2016-05-29 20:20 GMT+02:00 Oleg Grenrus <oleg.grenrus at iki.fi>:

> The non-outer variant works, because then there aren?t higher rank types
> at all, i.e. `state` of `Handler` is free to flow outwards.
>
> There is two ways to fix issue: Either use `newtype` or use
> `ImpredicativeTypes`
>
> ?
>
> {-# LANGUAGE RankNTypes #-}
>
> module TestTypes where
>
> data State a        = State a
>
> data Dummy          = Dummy
>
> newtype Handler result = Handler { runHandler :: forall state . State
> state -> IO result }
>
> type Resolver       = String -> Handler String
>
> eventRouter :: Resolver -> String -> IO ()
> eventRouter resolver event =
>     runHandler (resolver event) state >> return ()
>   where
>     state :: State ()
>     state = undefined
>
> {-
> -- does type check
> createResolver :: Resolver
> createResolver = \event state -> return "result"
>
> processor :: IO ()
> processor =
>     getLine >>= eventRouter resolver >> processor
>   where
>     resolver = createResolver
> -}
>
> eventConsumer :: Resolver -> String -> IO ()
> eventConsumer = undefined
> {-
> rank2.hs:34:17: error:
>     ? Cannot instantiate unification variable ?a0?
>       with a type involving foralls: Resolver -> String -> IO ()
>         GHC doesn't yet support impredicative polymorphism
>     ? In the expression: undefined
>       In an equation for ?eventConsumer?: eventConsumer = undefined
> -}
>
> -- does not type check when the rank 2 type isn't the "outermost" one?
> createResolver :: (Resolver, Dummy)
> createResolver = (\event -> Handler $ \state -> return "result", Dummy)
>
> processor :: IO ()
> processor =
>     getLine >>= eventConsumer resolver >> processor
>   where
>     resolver :: Resolver
>     resolver = fst (createResolver :: (Resolver, Dummy))
>
> {-
>     ? Couldn't match type ?t? with ?Resolver?
>       ?t? is a rigid type variable bound by
>         the inferred type of resolver :: t at TestTypes.hs:41:5
>       Expected type: (t, Dummy)
>         Actual type: (Resolver, Dummy)
> -}
>
> ---
>
> On 29 May 2016, at 21:02, Gabor Greif <ggreif at gmail.com> wrote:
>
> The same bug has bitten git-annex too. IIRC.
>
> Cheers,
>
>     Gabor
>
> Em domingo, 29 de maio de 2016, Michael Karg <mgoremeier at gmail.com>
> escreveu:
>
>> Hi devs,
>>
>> could you please have a look at the following code snippet (modeled after
>> a real-world app of mine)? There's a rank2type involved, and it doesn't
>> type-check anymore when the type is e.g. part of a tuple, whereas
>> everything's fine when it's the "outermost" type.
>>
>> With GHC7.10 both variants type-check. Could anyone shed some light on
>> what's behind this? Is the way the types are used in the snippet considered
>> dispreferred or wrong under GHC8?
>>
>> Thanks for having a look and hopefully pointing me to a page/ticket/...
>> providing insight,
>> Michael
>>
>> --------
>>
>> {-# LANGUAGE Rank2Types #-}
>>
>> module TestTypes where
>>
>> data State a        = State a
>>
>> data Dummy          = Dummy
>>
>> type Handler result = forall state . State state -> IO result
>>
>> type Resolver       = String -> Handler String
>>
>>
>> eventRouter :: Resolver -> String -> IO ()
>> eventRouter resolver event =
>>     resolver event state >> return ()
>>   where
>>     state :: State ()
>>     state = undefined
>>
>> {-
>> -- does type check
>> createResolver :: Resolver
>> createResolver = \event state -> return "result"
>>
>> processor :: IO ()
>> processor =
>>     getLine >>= eventRouter resolver >> processor
>>   where
>>     resolver = createResolver
>> -}
>>
>>
>> -- does not type check when the rank 2 type isn't the "outermost" one?
>> createResolver :: (Resolver, Dummy)
>> createResolver = (\event state -> return "result", Dummy)
>>
>> processor :: IO ()
>> processor =
>>     getLine >>= eventConsumer resolver >> processor
>>   where
>>     (resolver, _) = createResolver
>>
>> {-
>>     ? Couldn't match type ?t? with ?Resolver?
>>       ?t? is a rigid type variable bound by
>>         the inferred type of resolver :: t at TestTypes.hs:41:5
>>       Expected type: (t, Dummy)
>>         Actual type: (Resolver, Dummy)
>> -}
>>
>>
>> _______________________________________________
> 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/20160529/822ad090/attachment.html>

From omeragacan at gmail.com  Sun May 29 19:09:41 2016
From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=)
Date: Sun, 29 May 2016 15:09:41 -0400
Subject: comment lines in Cmm outputs
In-Reply-To: <878tysopzn.fsf@smart-cactus.org>
References: <CAMQQO3kEPQpgwudj9-rPGg+RsfCT5hRyXnTYK3sPN=-4hzYcaA@mail.gmail.com>
 <878tysopzn.fsf@smart-cactus.org>
Message-ID: <CAMQQO3nujnZkYO=Gfj7-YJbjkDJ1MrzBCjL7i1xmR_1go=s61A@mail.gmail.com>

Wait, isn't new codegen merged years ago? I don't see these comment
lines in 8.0.1-generated Cmm files. Comments in the AST may be there
but no comments were printed until very recently.

If no one feels strongly about this I'd love to remove those.

2016-05-29 11:14 GMT-04:00 Ben Gamari <ben at smart-cactus.org>:
> ?mer Sinan A?acan <omeragacan at gmail.com> writes:
>
>> I'm reading a lot of Cmm  these days and comments added by Cmm dump (which are
>> apparently added after 8.0.1) are so annoying becuase they're not saying
>> anything useful (what's the point of adding "// CmmCall" to a "call" line or
>> "// CmmCondBranch" to a "if" line?) but making a lot of noise. Why were those
>> added? Can we remove them?
>
> It looks like they've been with us since the initial merge of the new
> codegen. I agree that they don't add much value but I don't have any
> strong opinion either way. The only comment that we might want to
> retain is the one for CmmUnsafeForeignCall as it looks quite similar to
> a CmmCall.
>
> Cheers,
>
> - Ben

From omeragacan at gmail.com  Sun May 29 19:11:17 2016
From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=)
Date: Sun, 29 May 2016 15:11:17 -0400
Subject: comment lines in Cmm outputs
In-Reply-To: <878tysopzn.fsf@smart-cactus.org>
References: <CAMQQO3kEPQpgwudj9-rPGg+RsfCT5hRyXnTYK3sPN=-4hzYcaA@mail.gmail.com>
 <878tysopzn.fsf@smart-cactus.org>
Message-ID: <CAMQQO3=XeQ_wNyi0Ddo6EHdXcCxK_JCU6bdc6533mmezw17t=Q@mail.gmail.com>

2016-05-29 11:14 GMT-04:00 Ben Gamari <ben at smart-cactus.org>:
> CmmUnsafeForeignCall as it looks quite similar to
> a CmmCall

Well then maybe we should print those differently instead of adding
noise to every single line just to distinguish CmmUnsafeForeignCall
from CmmCall.

From ben at smart-cactus.org  Sun May 29 19:48:20 2016
From: ben at smart-cactus.org (Ben Gamari)
Date: Sun, 29 May 2016 21:48:20 +0200
Subject: comment lines in Cmm outputs
In-Reply-To: <CAMQQO3nujnZkYO=Gfj7-YJbjkDJ1MrzBCjL7i1xmR_1go=s61A@mail.gmail.com>
References: <CAMQQO3kEPQpgwudj9-rPGg+RsfCT5hRyXnTYK3sPN=-4hzYcaA@mail.gmail.com>
 <878tysopzn.fsf@smart-cactus.org>
 <CAMQQO3nujnZkYO=Gfj7-YJbjkDJ1MrzBCjL7i1xmR_1go=s61A@mail.gmail.com>
Message-ID: <87zir8myrf.fsf@smart-cactus.org>

?mer Sinan A?acan <omeragacan at gmail.com> writes:

> Wait, isn't new codegen merged years ago? I don't see these comment
> lines in 8.0.1-generated Cmm files. Comments in the AST may be there
> but no comments were printed until very recently.
>
Are you sure you are looking at code generated with similar options?
Note that the comments that you are referring to are only generated with
DEBUG defined (see the bottom of PprCmm).

> If no one feels strongly about this I'd love to remove those.
>
Assuming Simon Marlow is okay with it I certainly won't object.

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/20160529/e77bc95f/attachment.sig>

From david.feuer at gmail.com  Mon May 30 03:16:26 2016
From: david.feuer at gmail.com (David Feuer)
Date: Sun, 29 May 2016 23:16:26 -0400
Subject: Strictness/laziness warnings
In-Reply-To: <CABUjdS6=dEWccE2Jt+9J6husSBJmTOcKk2PTEaQeHeK_X94V8w@mail.gmail.com>
References: <CAMgWh9vN5_M72cfJZka3v660_AFoW0_nZqtwr3ViAa+atg2wEg@mail.gmail.com>
 <CAMgWh9vRqRgNx6ZQt0Pj-ArGtoejGrx8zarP7mht6+7Cp7FRtA@mail.gmail.com>
 <CAMgWh9tQMLGCmHjiTeSe0cs7FhS==HMudt0o9bA+vzUEL=XoEQ@mail.gmail.com>
 <CAMgWh9ur-tJYV-D5xaY+TT2R-__cs92YC9ueMX1SCz1fw0gRHA@mail.gmail.com>
 <CAMgWh9s_-oeVEoi1Tq4gANrmg+wok-kS6W8_KV44yURijpcgxw@mail.gmail.com>
 <CAMgWh9uTLcDmgLYECoz0BVj1rsJGDpnd4n2tc3nEq9s5PKE=3Q@mail.gmail.com>
 <CAMgWh9tX0yjHaTXVREH4XCwWMSc+Xv_vvfELxSFB2MW3TShG6A@mail.gmail.com>
 <CAMgWh9tGf3mm5uNMeCday7PPPMehEoZWiK6amda-g1OyBHrdgg@mail.gmail.com>
 <CAMgWh9vT3m1yK3iZy5h72rFFbJxZ9zQgG5Ofd_4K3YTU9gA9hA@mail.gmail.com>
 <CAMgWh9sLDuqXRw7YkvA6_4O6sa_jQfjWxOiMKO6YrL=RW+H67Q@mail.gmail.com>
 <CAMgWh9s_cfstCnHDa=ppXdTVLH5qMD8A449Hobho5kscTDeVcw@mail.gmail.com>
 <CAMgWh9uQ3E=M2ewWDCw4-5ppu3GvyNO2G2xiOatctL8Hzdy86Q@mail.gmail.com>
 <CAMgWh9u6z6s8ewChQsha_p0-wWp=JSdHjQDUi4aiych1Y=2CcQ@mail.gmail.com>
 <CAMgWh9tU_7fvJotKUzLv0VwcMCLb2x-52chH5Vb804snk5Xagw@mail.gmail.com>
 <CAMgWh9vYKKCWCHzwDNqovzJFUJsEGXqPDFsVGzX3hdOQ0ZxRUQ@mail.gmail.com>
 <CAMgWh9uWZd2Hn0t6XTEkJQmWE_jtHsFZTcn2sH7ndXaUvjUQwg@mail.gmail.com>
 <CAMgWh9tU_AEFho7TajE8RZB08ywCMDRhGgVgAKEOWKS9x1jz6g@mail.gmail.com>
 <CAJumaK9gEjasenAFguRFF-unOsZPkH8eZKD4fO2aiMSpQWyuog@mail.gmail.com>
 <CAMgWh9uKxY75_PAG13qSF_cKZ_L+Mn7pK9Y9tjdfUGiJvh9few@mail.gmail.com>
 <CAJumaK_4GZqp20JM_hExL=1QsamhpohsGbjf2cbX8txzoPS6pg@mail.gmail.com>
 <CABUjdS6=dEWccE2Jt+9J6husSBJmTOcKk2PTEaQeHeK_X94V8w@mail.gmail.com>
Message-ID: <CAMgWh9tcPaRDeK2d=iBd4q0a9DZ_Tr2CWp6XX+LCFO40Ny958w@mail.gmail.com>

Mostly I'm looking for a rough estimate. Some false positives and
false negatives are tolerable. If I have something like

f :: Int -> Maybe String -> String
f _ Nothing = "Hi there!"
f n (Just b) = if n > 0 then show b else "whatever"

then I'd likely be interested in a warning about the fact that the
first case is not strict in the Int and the second is. I'd also likely
be interested in a warning about the first case because I'm taking a
small primitive value (Int) and doing so lazily.

On Sun, May 29, 2016 at 11:04 PM, wren romano <winterkoninkje at gmail.com> wrote:
> On Sat, May 28, 2016 at 10:14 PM, Edward Kmett <ekmett at gmail.com> wrote:
>> How would you detect the argument only being forced some of the time? Sounds
>> like a lot of long-term cross-module book-keeping.
>
> Sounds to me like what the strictness analyzer is already doing, ne? I
> missed the beginning of the thread, so might be off base. If it's more
> about noticing when the use sites of a given function have some
> pattern not captured by the strictness determined from the function's
> definition, then it seems like we shouldn't need /cross/-module
> bookkeeping: we should be able to just tabulate how each use site's
> strictness does/doesn't match the interface's spec.
>
> --
> Live well,
> ~wren

From ggreif at gmail.com  Mon May 30 10:27:11 2016
From: ggreif at gmail.com (Gabor Greif)
Date: Mon, 30 May 2016 12:27:11 +0200
Subject: GHC HEAD (built with itself) blows allocation stats :-(
Message-ID: <CAK-hX0=bF-FKKQCxYq-dTBveSUg+nLhP0ybeHYdXNC1XSaprNA@mail.gmail.com>

Hi devs,

I get some pretty bad allocation statistics when testing GHC HEAD. Not sure why,
but this is with a stage-0 compiler that is also GHC HEAD. (I doubt
that that is the reason, though.)

I see on a linux x64 system (RHEL6) :

Unexpected stat failures:
   /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T10370      T10370 [stat
not good enough] (optasm)
   /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T10547      T10547 [stat
not good enough] (normal)
   /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T1969       T1969 [stat
not good enough] (normal)
   /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T3064       T3064 [stat
not good enough] (normal)
   /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T3294       T3294 [stat
not good enough] (normal)
   /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T4801       T4801 [stat
not good enough] (normal)
   /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T5030       T5030 [stat
not good enough] (normal)
   /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T5321FD     T5321FD [stat
not good enough] (normal)
   /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T5321Fun    T5321Fun
[stat not good enough] (normal)
   /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T5631       T5631 [stat
not good enough] (normal)
   /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T5642       T5642 [stat
not good enough] (normal)
   /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T5837       T5837 [stat
not good enough] (normal)
   /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T6048       T6048 [stat
not good enough] (optasm)
   /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T783        T783 [stat
not good enough] (normal)
   /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T9020       T9020 [stat
not good enough] (optasm)
   /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T9233       T9233 [stat
not good enough] (normal)
   /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T9675       T9675 [stat
not good enough] (optasm)
   /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T9872a      T9872a [stat
not good enough] (normal)
   /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T9872b      T9872b [stat
not good enough] (normal)
   /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T9872c      T9872c [stat
not good enough] (normal)
   /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T9872d      T9872d [stat
not good enough] (normal)
   /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T9961       T9961 [stat
not good enough] (normal)
   /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/parsing001  parsing001
[stat not good enough] (normal)
   /tmp/ghctest/ayiNBP/1/2/3/./perf/space_leaks/T4029    T4029 [stat
not good enough] (ghci)


Some of the tests look like this:

cd /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T9872a &&
"ghc-head-x86_64/inplace/test   spaces/ghc-stage2" -c T9872a.hs
-fforce-recomp -dno-debug-output -no-user-package-db -rtsopts
-fno-warn-tabs -fno-warn-missed-specialisations -fshow-warning-groups
-fno-ghci-history   +RTS -V0 -tT9872a.comp.stats --machine-readable
-RTS > T9872a.comp.stderr 2>&1
bytes allocated value is too high:
    Expected    T9872a(normal) bytes allocated:  3352882080 +/-5%
    Lower bound T9872a(normal) bytes allocated:  3185237976
    Upper bound T9872a(normal) bytes allocated:  3520526184
    Actual      T9872a(normal) bytes allocated: 13260131240
    Deviation   T9872a(normal) bytes allocated:       295.5 %
*** unexpected stat test failure for T9872a(normal)

Around 300% looks really bad. Can anybody reproduce this? For
reference, this is the test command I run:

$ make test TEST="T9961 T10547 T10370 T3064 T4029 T5642 parsing001
T783 T3294 T9872d T9872b T9872c T9872a T1969 T5321Fun T5837 T5631
T5321FD T5030 T4801 T6048 T9675 T9233 T9020"

The testsuite works nicely otherwise.

Cheers and thanks,

    Gabor

From ben at smart-cactus.org  Mon May 30 10:39:25 2016
From: ben at smart-cactus.org (Ben Gamari)
Date: Mon, 30 May 2016 12:39:25 +0200
Subject: GHC HEAD (built with itself) blows allocation stats :-(
In-Reply-To: <CAK-hX0=bF-FKKQCxYq-dTBveSUg+nLhP0ybeHYdXNC1XSaprNA@mail.gmail.com>
References: <CAK-hX0=bF-FKKQCxYq-dTBveSUg+nLhP0ybeHYdXNC1XSaprNA@mail.gmail.com>
Message-ID: <87pos3n82q.fsf@smart-cactus.org>

Gabor Greif <ggreif at gmail.com> writes:

> Hi devs,
>
> I get some pretty bad allocation statistics when testing GHC HEAD. Not sure why,
> but this is with a stage-0 compiler that is also GHC HEAD. (I doubt
> that that is the reason, though.)
>
Hmm, I haven't been able to reproduce this on Debian 8, bootstrapped
with 8.0.1.

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/20160530/69230abc/attachment.sig>

From jan.stolarek at p.lodz.pl  Mon May 30 10:54:45 2016
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Mon, 30 May 2016 12:54:45 +0200
Subject: GHC HEAD (built with itself) blows allocation stats :-(
In-Reply-To: <CAK-hX0=bF-FKKQCxYq-dTBveSUg+nLhP0ybeHYdXNC1XSaprNA@mail.gmail.com>
References: <CAK-hX0=bF-FKKQCxYq-dTBveSUg+nLhP0ybeHYdXNC1XSaprNA@mail.gmail.com>
Message-ID: <201605301254.45278.jan.stolarek@p.lodz.pl>

Sanity check: was the stage0 compiler built using "perf" settings?

Janek

Dnia poniedzia?ek, 30 maja 2016, Gabor Greif napisa?:
> Hi devs,
>
> I get some pretty bad allocation statistics when testing GHC HEAD. Not sure
> why, but this is with a stage-0 compiler that is also GHC HEAD. (I doubt
> that that is the reason, though.)
>
> I see on a linux x64 system (RHEL6) :
>
> Unexpected stat failures:
>    /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T10370      T10370 [stat
> not good enough] (optasm)
>    /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T10547      T10547 [stat
> not good enough] (normal)
>    /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T1969       T1969 [stat
> not good enough] (normal)
>    /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T3064       T3064 [stat
> not good enough] (normal)
>    /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T3294       T3294 [stat
> not good enough] (normal)
>    /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T4801       T4801 [stat
> not good enough] (normal)
>    /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T5030       T5030 [stat
> not good enough] (normal)
>    /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T5321FD     T5321FD [stat
> not good enough] (normal)
>    /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T5321Fun    T5321Fun
> [stat not good enough] (normal)
>    /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T5631       T5631 [stat
> not good enough] (normal)
>    /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T5642       T5642 [stat
> not good enough] (normal)
>    /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T5837       T5837 [stat
> not good enough] (normal)
>    /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T6048       T6048 [stat
> not good enough] (optasm)
>    /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T783        T783 [stat
> not good enough] (normal)
>    /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T9020       T9020 [stat
> not good enough] (optasm)
>    /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T9233       T9233 [stat
> not good enough] (normal)
>    /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T9675       T9675 [stat
> not good enough] (optasm)
>    /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T9872a      T9872a [stat
> not good enough] (normal)
>    /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T9872b      T9872b [stat
> not good enough] (normal)
>    /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T9872c      T9872c [stat
> not good enough] (normal)
>    /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T9872d      T9872d [stat
> not good enough] (normal)
>    /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T9961       T9961 [stat
> not good enough] (normal)
>    /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/parsing001  parsing001
> [stat not good enough] (normal)
>    /tmp/ghctest/ayiNBP/1/2/3/./perf/space_leaks/T4029    T4029 [stat
> not good enough] (ghci)
>
>
> Some of the tests look like this:
>
> cd /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T9872a &&
> "ghc-head-x86_64/inplace/test   spaces/ghc-stage2" -c T9872a.hs
> -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts
> -fno-warn-tabs -fno-warn-missed-specialisations -fshow-warning-groups
> -fno-ghci-history   +RTS -V0 -tT9872a.comp.stats --machine-readable
> -RTS > T9872a.comp.stderr 2>&1
> bytes allocated value is too high:
>     Expected    T9872a(normal) bytes allocated:  3352882080 +/-5%
>     Lower bound T9872a(normal) bytes allocated:  3185237976
>     Upper bound T9872a(normal) bytes allocated:  3520526184
>     Actual      T9872a(normal) bytes allocated: 13260131240
>     Deviation   T9872a(normal) bytes allocated:       295.5 %
> *** unexpected stat test failure for T9872a(normal)
>
> Around 300% looks really bad. Can anybody reproduce this? For
> reference, this is the test command I run:
>
> $ make test TEST="T9961 T10547 T10370 T3064 T4029 T5642 parsing001
> T783 T3294 T9872d T9872b T9872c T9872a T1969 T5321Fun T5837 T5631
> T5321FD T5030 T4801 T6048 T9675 T9233 T9020"
>
> The testsuite works nicely otherwise.
>
> Cheers and thanks,
>
>     Gabor
> _______________________________________________
> 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 ben at smart-cactus.org  Mon May 30 11:04:06 2016
From: ben at smart-cactus.org (Ben Gamari)
Date: Mon, 30 May 2016 13:04:06 +0200
Subject: GHC HEAD (built with itself) blows allocation stats :-(
In-Reply-To: <CAK-hX0=bF-FKKQCxYq-dTBveSUg+nLhP0ybeHYdXNC1XSaprNA@mail.gmail.com>
References: <CAK-hX0=bF-FKKQCxYq-dTBveSUg+nLhP0ybeHYdXNC1XSaprNA@mail.gmail.com>
Message-ID: <87k2ibn6xl.fsf@smart-cactus.org>

Gabor Greif <ggreif at gmail.com> writes:

> Hi devs,
>
> I get some pretty bad allocation statistics when testing GHC HEAD. Not sure why,
> but this is with a stage-0 compiler that is also GHC HEAD. (I doubt
> that that is the reason, though.)
>
I presume this wasn't with ./validate. Have you tried ./validate?

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/20160530/95c46062/attachment.sig>

From ggreif at gmail.com  Mon May 30 13:16:07 2016
From: ggreif at gmail.com (Gabor Greif)
Date: Mon, 30 May 2016 15:16:07 +0200
Subject: GHC HEAD (built with itself) blows allocation stats :-(
In-Reply-To: <87k2ibn6xl.fsf@smart-cactus.org>
References: <CAK-hX0=bF-FKKQCxYq-dTBveSUg+nLhP0ybeHYdXNC1XSaprNA@mail.gmail.com>
 <87k2ibn6xl.fsf@smart-cactus.org>
Message-ID: <CAK-hX0=hQruxm1_39tAmHSEPn66AoYPsWVvHZOQMcRhVNTwpxw@mail.gmail.com>

Thanks for the tip, Ben! I have just tried with ./validate and those
horrific stats are gone.

`$(MAKE) test` now also works. Apparently the thorough cleaning was
overdue. I'm fine with this.

Cheers,

    Gabor

PS: Out of sheer curiosity, what could have caused the hiccups?

On 5/30/16, Ben Gamari <ben at smart-cactus.org> wrote:
> Gabor Greif <ggreif at gmail.com> writes:
>
>> Hi devs,
>>
>> I get some pretty bad allocation statistics when testing GHC HEAD. Not
>> sure why,
>> but this is with a stage-0 compiler that is also GHC HEAD. (I doubt
>> that that is the reason, though.)
>>
> I presume this wasn't with ./validate. Have you tried ./validate?
>
> Cheers,
>
> - Ben
>

From ben at smart-cactus.org  Mon May 30 13:56:36 2016
From: ben at smart-cactus.org (Ben Gamari)
Date: Mon, 30 May 2016 15:56:36 +0200
Subject: GHC HEAD (built with itself) blows allocation stats :-(
In-Reply-To: <CAK-hX0=hQruxm1_39tAmHSEPn66AoYPsWVvHZOQMcRhVNTwpxw@mail.gmail.com>
References: <CAK-hX0=bF-FKKQCxYq-dTBveSUg+nLhP0ybeHYdXNC1XSaprNA@mail.gmail.com>
 <87k2ibn6xl.fsf@smart-cactus.org>
 <CAK-hX0=hQruxm1_39tAmHSEPn66AoYPsWVvHZOQMcRhVNTwpxw@mail.gmail.com>
Message-ID: <87h9dfmyy3.fsf@smart-cactus.org>

Gabor Greif <ggreif at gmail.com> writes:

> Thanks for the tip, Ben! I have just tried with ./validate and those
> horrific stats are gone.
>
> `$(MAKE) test` now also works. Apparently the thorough cleaning was
> overdue. I'm fine with this.
>
> Cheers,
>
>     Gabor
>
> PS: Out of sheer curiosity, what could have caused the hiccups?
>
You may have been using a build with DEBUG enabled, which enables a
number of rather expensive assertions in the compiler.

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/20160530/d2bbf0b7/attachment.sig>

From omeragacan at gmail.com  Mon May 30 19:14:48 2016
From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=)
Date: Mon, 30 May 2016 15:14:48 -0400
Subject: Parser changes for supporting top-level SCC annotations
Message-ID: <CAMQQO3=iCmXq48OzsV7PaVGeP-ehwgHTnfbUaOxvHY9Dqgq0jw@mail.gmail.com>

I'm trying to support SCCs at the top-level. The implementation should be
trivial except the parsing part turned out to be tricky. Since expressions can
appear at the top-level, after a {-# SCC ... #-} parser can't decide whether to
reduce the token in `sigdecl` to generate a `(LHsDecl (Sig (SCCSig ...)))` or to
keep shifting to parse an expression. As shifting is the default behavior when a
shift/reduce conflict happens, it's always trying to parse an expression, which
is always the wrong thing to do.

Does anyone have any ideas on how to handle this?

Motivation: Not having SCCs at the top level is becoming annoying real quick.
For simplest cases, it's possible to do this transformation:

    f x y = ...
    =>
    f = {-# SCC f #-} \x y -> ...

However, it doesn't work when there's a `where` clause:

    f x y = <t is in scope>
      where t = ...
    =>
    f = {-# SCC f #-} \x y -> <t is out of scope>
      where t = ...

Or when we have a "equation style" definition:

    f (C1 ...) = ...
    f (C2 ...) = ...
    f (C3 ...) = ...
    ...

(usual solution is to rename `f` to `f'` and define a new `f` with a `SCC`)

From jmct at jmct.cc  Mon May 30 19:46:53 2016
From: jmct at jmct.cc (=?UTF-8?Q?Jos=C3=A9_Manuel_Calder=C3=B3n_Trilla?=)
Date: Mon, 30 May 2016 15:46:53 -0400
Subject: Strictness/laziness warnings
In-Reply-To: <CAMgWh9tcPaRDeK2d=iBd4q0a9DZ_Tr2CWp6XX+LCFO40Ny958w@mail.gmail.com>
References: <CAMgWh9vN5_M72cfJZka3v660_AFoW0_nZqtwr3ViAa+atg2wEg@mail.gmail.com>
 <CAMgWh9vRqRgNx6ZQt0Pj-ArGtoejGrx8zarP7mht6+7Cp7FRtA@mail.gmail.com>
 <CAMgWh9tQMLGCmHjiTeSe0cs7FhS==HMudt0o9bA+vzUEL=XoEQ@mail.gmail.com>
 <CAMgWh9ur-tJYV-D5xaY+TT2R-__cs92YC9ueMX1SCz1fw0gRHA@mail.gmail.com>
 <CAMgWh9s_-oeVEoi1Tq4gANrmg+wok-kS6W8_KV44yURijpcgxw@mail.gmail.com>
 <CAMgWh9uTLcDmgLYECoz0BVj1rsJGDpnd4n2tc3nEq9s5PKE=3Q@mail.gmail.com>
 <CAMgWh9tX0yjHaTXVREH4XCwWMSc+Xv_vvfELxSFB2MW3TShG6A@mail.gmail.com>
 <CAMgWh9tGf3mm5uNMeCday7PPPMehEoZWiK6amda-g1OyBHrdgg@mail.gmail.com>
 <CAMgWh9vT3m1yK3iZy5h72rFFbJxZ9zQgG5Ofd_4K3YTU9gA9hA@mail.gmail.com>
 <CAMgWh9sLDuqXRw7YkvA6_4O6sa_jQfjWxOiMKO6YrL=RW+H67Q@mail.gmail.com>
 <CAMgWh9s_cfstCnHDa=ppXdTVLH5qMD8A449Hobho5kscTDeVcw@mail.gmail.com>
 <CAMgWh9uQ3E=M2ewWDCw4-5ppu3GvyNO2G2xiOatctL8Hzdy86Q@mail.gmail.com>
 <CAMgWh9u6z6s8ewChQsha_p0-wWp=JSdHjQDUi4aiych1Y=2CcQ@mail.gmail.com>
 <CAMgWh9tU_7fvJotKUzLv0VwcMCLb2x-52chH5Vb804snk5Xagw@mail.gmail.com>
 <CAMgWh9vYKKCWCHzwDNqovzJFUJsEGXqPDFsVGzX3hdOQ0ZxRUQ@mail.gmail.com>
 <CAMgWh9uWZd2Hn0t6XTEkJQmWE_jtHsFZTcn2sH7ndXaUvjUQwg@mail.gmail.com>
 <CAMgWh9tU_AEFho7TajE8RZB08ywCMDRhGgVgAKEOWKS9x1jz6g@mail.gmail.com>
 <CAJumaK9gEjasenAFguRFF-unOsZPkH8eZKD4fO2aiMSpQWyuog@mail.gmail.com>
 <CAMgWh9uKxY75_PAG13qSF_cKZ_L+Mn7pK9Y9tjdfUGiJvh9few@mail.gmail.com>
 <CAJumaK_4GZqp20JM_hExL=1QsamhpohsGbjf2cbX8txzoPS6pg@mail.gmail.com>
 <CABUjdS6=dEWccE2Jt+9J6husSBJmTOcKk2PTEaQeHeK_X94V8w@mail.gmail.com>
 <CAMgWh9tcPaRDeK2d=iBd4q0a9DZ_Tr2CWp6XX+LCFO40Ny958w@mail.gmail.com>
Message-ID: <CAK+ijdtsgZpANW0TjEw4yDKDZefFxEEMn-WYUBd9Fy+6gabf6Q@mail.gmail.com>

This is strictness over sum types. ?mer and I worked on adding it to a
fork of GHC.

It's definitely possible, the main complications are how to deal with
recursive types in the presence of polymorphic recursion and how to
detect recursive types in the presence of higher-kinded types. Because
the former is pretty complicated I'm working on the latter to avoid
recursive types altogether.

If you're interested, Ralf Hinze's PhD thesis ("Projection-based
Strictness Analysis: Theoretical and Practical Aspects") is my go-to
recommendation for what can be done with strictness analysis,
unfortunately it doesn't solve the problem of strictness over
polymorphic recursion.

If you search for "Generalising the demand analysis to sum types" on
the ghc-devs list the past discussion should come up.

Cheers,

Jose




On Sun, May 29, 2016 at 11:16 PM, David Feuer <david.feuer at gmail.com> wrote:
> Mostly I'm looking for a rough estimate. Some false positives and
> false negatives are tolerable. If I have something like
>
> f :: Int -> Maybe String -> String
> f _ Nothing = "Hi there!"
> f n (Just b) = if n > 0 then show b else "whatever"
>
> then I'd likely be interested in a warning about the fact that the
> first case is not strict in the Int and the second is. I'd also likely
> be interested in a warning about the first case because I'm taking a
> small primitive value (Int) and doing so lazily.
>
> On Sun, May 29, 2016 at 11:04 PM, wren romano <winterkoninkje at gmail.com> wrote:
>> On Sat, May 28, 2016 at 10:14 PM, Edward Kmett <ekmett at gmail.com> wrote:
>>> How would you detect the argument only being forced some of the time? Sounds
>>> like a lot of long-term cross-module book-keeping.
>>
>> Sounds to me like what the strictness analyzer is already doing, ne? I
>> missed the beginning of the thread, so might be off base. If it's more
>> about noticing when the use sites of a given function have some
>> pattern not captured by the strictness determined from the function's
>> definition, then it seems like we shouldn't need /cross/-module
>> bookkeeping: we should be able to just tabulate how each use site's
>> strictness does/doesn't match the interface's spec.
>>
>> --
>> Live well,
>> ~wren
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From niteria at gmail.com  Tue May 31 13:54:45 2016
From: niteria at gmail.com (Bartosz Nitka)
Date: Tue, 31 May 2016 14:54:45 +0100
Subject: Template Haskell determinism
Message-ID: <CAOSxnRhPdzVTQUihXCfEr6Wh-jTNuFnT8DLyuwomKqTBA8B8_Q@mail.gmail.com>

Template Haskell with its ability to do arbitrary IO is non-deterministic by
design. You could for example embed the current date in a file. There is
however one kind of non-deterministic behavior that you can trigger
accidentally. It has to do with how Names are reified. If you take a look
at
the definition of reifyName you can see that it puts the assigned Unique in
a
NameU:

  reifyName :: NamedThing n => n -> TH.Name
  reifyName thing
    | isExternalName name = mk_varg pkg_str mod_str occ_str
    | otherwise           = TH.mkNameU occ_str (getKey (getUnique name))
    ...
NameFlavour which NameU is a constructor of has a default Ord instance,
meaning
that it ends up comparing the Uniques. The relative ordering of Uniques is
not
guaranteed to be stable across recompilations [1], so this can lead to
ABI-incompatible binaries.

This isn't an abstract problem and it actually happens in practice. The
microlens package keeps Names in a Set and later turns that set into a list.
The results have different orders of TyVars resulting in different ABI
hashes
and can potentially be optimized differently.

I believe it's worth to handle this case in a deterministic way and I have a
solution in mind. The idea is to extend NameU (and potentially NameL) with
an
ordering key. To be more concrete:

-   | NameU !Int
+   | NameU !Int !Int

This way the Ord instance can use a stable key and the problem reduces to
ensuring the keys are stable. To generate stable keys we can use the fact
that
reify traverses the expressions in the same order every time and
sequentially
allocate new keys based on traversal order. The way I have it implemented
now
is to add a new field in TcGblEnv which maps Uniques to allocated keys:

+        tcg_th_names :: TcRef (UniqFM Int, Int),

Then the reifyName and qNewName do the necessary bookkeeping and translate
the
Uniques on the fly.

This is a breaking change and it doesn't fix the problem that NameFlavour is
not abstract and leaks the Uniques. It would break at least:

- singletons
- th-lift
- haskell-src-meta
- shakespeare
- distributed-closure

I'd like to get feedback if this is an acceptable solution and if the
problem
is worth solving.

Cheers,
Bartosz

[1]
https://ghc.haskell.org/trac/ghc/wiki/DeterministicBuilds#NondeterministicUniques
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160531/a88bb92d/attachment.html>

From eir at cis.upenn.edu  Tue May 31 15:10:46 2016
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Tue, 31 May 2016 11:10:46 -0400
Subject: Template Haskell determinism
In-Reply-To: <CAOSxnRhPdzVTQUihXCfEr6Wh-jTNuFnT8DLyuwomKqTBA8B8_Q@mail.gmail.com>
References: <CAOSxnRhPdzVTQUihXCfEr6Wh-jTNuFnT8DLyuwomKqTBA8B8_Q@mail.gmail.com>
Message-ID: <7B73C786-9F39-48D6-AB5F-C64C4F800624@cis.upenn.edu>


On May 31, 2016, at 9:54 AM, Bartosz Nitka <niteria at gmail.com> wrote:

> I'd like to get feedback if this is an acceptable solution and if the problem
> is worth solving.

I don't have an opinion about "worth solving". While I understand your description of the problem and believe you that it crops up in practice, I don't have a grasp on the net effect of this all. Bottom line on this front: I trust your judgment.

As to the breaking change: go for it. Template Haskell churns a good deal between releases (though not within a single major release) and so breaking changes are common. And NameFlavour really should be abstract (it can't be due to the linkage between the template-haskell and ghc packages) and anyone who uses it (including me) is doing something fishy. Accordingly, I'd personally be OK with a breaking change in a minor release around NameFlavour, as long as nothing exported from Language.Haskell.TH is changed. (We do have a way of using CPP to detect minor version bumps, right?)

I hope this helps,
Richard


From albertosadde at gmail.com  Tue May 31 20:04:16 2016
From: albertosadde at gmail.com (Alberto Sadde O.)
Date: Tue, 31 May 2016 21:04:16 +0100
Subject: Core of a whole package
Message-ID: <CAA3tLup5T3ihiTZZz9xvK9neRSiCiYo48_Dw+HdtKmkGtLxQdQ@mail.gmail.com>

Hi,

I am trying to get the Core of a whole package.
I have been using the GHC API to get the Core of each file in a package but
I have a problems with non-exposed modules of the package.

I might not been setting up all the flags correctly but at this point I am
completely lost!!

I posted a question on S.O.
<http://stackoverflow.com/questions/37410615/ghc-api-compile-whole-package-to-core>
The code I am using is in the above link.

Any help/comments/tips would be greatly appreciated!

Many thanks,

Alberto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160531/50f669ff/attachment.html>

From omeragacan at gmail.com  Tue May 31 21:34:40 2016
From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=)
Date: Tue, 31 May 2016 17:34:40 -0400
Subject: Core of a whole package
In-Reply-To: <CAA3tLup5T3ihiTZZz9xvK9neRSiCiYo48_Dw+HdtKmkGtLxQdQ@mail.gmail.com>
References: <CAA3tLup5T3ihiTZZz9xvK9neRSiCiYo48_Dw+HdtKmkGtLxQdQ@mail.gmail.com>
Message-ID: <CAMQQO3=S2FTSEXa0OqzPzUyW7Lis31-UQ8EXqT0DBJhBJeH65g@mail.gmail.com>

2016-05-31 16:04 GMT-04:00 Alberto Sadde O. <albertosadde at gmail.com>:
> I am trying to get the Core of a whole package.
> I have been using the GHC API to get the Core of each file in a package but
> I have a problems with non-exposed modules of the package.

Try `cabal install --ghc-options="-ddump-simpl -ddump-to-file"`. You
should see Core outputs under `dist/`.
(or `cabal configure --ghc-options=...` then `cabal build`)

If you have all the dependencies installed already you can just do
`ghc --make Main.hs -fforce-recomp -ddump-simpl -ddump-to-file` where
`Main.hs` imports all the modules in your project.

From albertosadde at gmail.com  Tue May 31 21:56:37 2016
From: albertosadde at gmail.com (Alberto Sadde O.)
Date: Tue, 31 May 2016 22:56:37 +0100
Subject: Core of a whole package
In-Reply-To: <CAMQQO3=S2FTSEXa0OqzPzUyW7Lis31-UQ8EXqT0DBJhBJeH65g@mail.gmail.com>
References: <CAA3tLup5T3ihiTZZz9xvK9neRSiCiYo48_Dw+HdtKmkGtLxQdQ@mail.gmail.com>
 <CAMQQO3=S2FTSEXa0OqzPzUyW7Lis31-UQ8EXqT0DBJhBJeH65g@mail.gmail.com>
Message-ID: <CAA3tLuppVnjNRgOr1sGDM1cbfqEz3xe5tfS0bAj=5RQd02yMyA@mail.gmail.com>

> 2016-05-31 16:04 GMT-04:00 Alberto Sadde O. <albertosadde at gmail.com>:
> > I am trying to get the Core of a whole package.
> > I have been using the GHC API to get the Core of each file in a package
> but
> > I have a problems with non-exposed modules of the package.
>
> Try `cabal install --ghc-options="-ddump-simpl -ddump-to-file"`. You
> should see Core outputs under `dist/`.
> (or `cabal configure --ghc-options=...` then `cabal build`)
>
> If you have all the dependencies installed already you can just do
> `ghc --make Main.hs -fforce-recomp -ddump-simpl -ddump-to-file` where
> `Main.hs` imports all the modules in your project.
>

Thanks for the answer.
The thing is that I want to manipulate the Core of the package not just
simply dump it to a file.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160531/d6bd5c38/attachment.html>

From ben at well-typed.com  Thu May  5 07:35:00 2016
From: ben at well-typed.com (Ben Gamari)
Date: Thu, 05 May 2016 07:35:00 -0000
Subject: [Action Needed] Document your work for the Haskell Communities
 and Activities Report
In-Reply-To: <87inza69vo.fsf@smart-cactus.org>
References: <87inza69vo.fsf@smart-cactus.org>
Message-ID: <8760ut6jds.fsf@smart-cactus.org>

Ben Gamari <ben at well-typed.com> writes:

> [ Unknown signature status ]
> TL;DR. If you see your name in one of the two lists below, please edit
>        the entries for your contributions to 8.0 and plans for 8.2 in
>        the 2016 GHC HCAR report [1]. The deadline is in a few short
>        weeks so act soon!
>
Thanks to everyone for your contributions!

I've sent the final version for submission so there's no need to push
further amendments to the wiki page.

However, I have transferred the 8.2 tasks to the new GHC 8.2.1 status
page [1]. If you have things you would like to amend in your 8.2 goals
please do update the text on the status page. Thanks!

Cheers,

- Ben


[1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.2.1
-------------- 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/20160505/87eb6ba7/attachment-0001.sig>