From karel.gardas at centrum.cz Fri Jan 1 11:22:50 2016 From: karel.gardas at centrum.cz (Karel Gardas) Date: Fri, 01 Jan 2016 12:22:50 +0100 Subject: Flag warnings show intermediate hscpp filenames on SmartOS In-Reply-To: References: <5684E713.4050503@centrum.cz> <87a8oq94xe.fsf@smart-cactus.org> <568547F8.1040209@centrum.cz> <56858E53.8010105@centrum.cz> Message-ID: <5686618A.30905@centrum.cz> Alain, indeed, on SmartOS you are free to modify the supplied GCC so the fix to remove -P is most natural one. On the other hand I'm not so lucky with binary Solaris 11.x distribution provided by Oracle so I need to use not so clean and nice workarounds... Karel On 01/ 1/16 12:17 AM, Alain O'Dea wrote: > cpphs isn't a direct option. It won't install on SmartOS with Cabal. > GCC 4.7 is the earliest GCC supported so I'll have to try something else > for SmartOS. > > It looks like the GCC Specs are the problem. > > On Ubuntu the Spec for cpp is: > > *cpp: > %{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT} > > On SmartOS the Spec for cpp is: > > *cpp: > %{,assembler-with-cpp:-P} %(cpp_subtarget) > > I think this is how the -P gets injected. I think this is correctable. > I had a similar issue with -std=c99 which is the default for C compiling > on Ubuntu but not on SmartOS leading to issues with compiling source > that isn't old school C (like persistent-sqlite). > > Anyways I must retire from this and entertain my guests. Happy New Year > folks. > > > On Thu, Dec 31, 2015 at 5:19 PM Alain O'Dea > wrote: > > Thanks for the clarification. I understand now. > On Thu, Dec 31, 2015 at 16:52 Karel Gardas > wrote: > > On 12/31/15 07:41 PM, Alain O'Dea wrote: > > Yes. I can do that. > > > > On SmartOS it may not be GCC 3.4.3 causing this. I see this > on GCC 4.7.x > > through 4.9.x. The paths to gcc on SmartOS also differ. I'll > have to > > verify that as part of checking this. > > This is misunderstanding. GCC 3.4.3 provides *correct* CPP behavior, > while all 4.x provides broken CPP. That means as a workaround > when GCC > 3.4.3 is installed I set it as GHC's CPP automatically on > Solaris. When > it is not available, then GHC behaves like you've seen when > using CPP... > > Hopefully this is more clear now, > > Karel > From ben at smart-cactus.org Fri Jan 1 18:07:12 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Fri, 01 Jan 2016 19:07:12 +0100 Subject: Haskeline on Windows In-Reply-To: References: Message-ID: <87ege1rx67.fsf@smart-cactus.org> Ryan Scott writes: > This is already fixed in the haskeline GitHub repo [1], but I never > got around to updating the downstream haskeline repo on > git.haskell.org [2] since I don't have push access. Can someone update > it for me? > It appears that this has been done. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From alain.odea at gmail.com Fri Jan 1 18:38:20 2016 From: alain.odea at gmail.com (Alain O'Dea) Date: Fri, 01 Jan 2016 18:38:20 +0000 Subject: Flag warnings show intermediate hscpp filenames on SmartOS In-Reply-To: <5686618A.30905@centrum.cz> References: <5684E713.4050503@centrum.cz> <87a8oq94xe.fsf@smart-cactus.org> <568547F8.1040209@centrum.cz> <56858E53.8010105@centrum.cz> <5686618A.30905@centrum.cz> Message-ID: True, but I'd still like to find a mutual solution since we're both somewhat at the edge of the supported landscape for GHC. Is installing cpphs and configuring GHC to use that an option on Solaris 11? I haven't built cpphs successfully on SmartOS yet. Supplying a custom C preprocessor may be your best bet and using GCC 3.4's works for you. If I can get cpphs working that may be the common ground needed to keep Illumos and Solaris support from diverging. On Fri, Jan 1, 2016 at 7:52 AM Karel Gardas wrote: > > Alain, > > indeed, on SmartOS you are free to modify the supplied GCC so the fix to > remove -P is most natural one. On the other hand I'm not so lucky with > binary Solaris 11.x distribution provided by Oracle so I need to use not > so clean and nice workarounds... > > Karel > > On 01/ 1/16 12:17 AM, Alain O'Dea wrote: > > cpphs isn't a direct option. It won't install on SmartOS with Cabal. > > GCC 4.7 is the earliest GCC supported so I'll have to try something else > > for SmartOS. > > > > It looks like the GCC Specs are the problem. > > > > On Ubuntu the Spec for cpp is: > > > > *cpp: > > %{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT} > > > > On SmartOS the Spec for cpp is: > > > > *cpp: > > %{,assembler-with-cpp:-P} %(cpp_subtarget) > > > > I think this is how the -P gets injected. I think this is correctable. > > I had a similar issue with -std=c99 which is the default for C compiling > > on Ubuntu but not on SmartOS leading to issues with compiling source > > that isn't old school C (like persistent-sqlite). > > > > Anyways I must retire from this and entertain my guests. Happy New Year > > folks. > > > > > > On Thu, Dec 31, 2015 at 5:19 PM Alain O'Dea > > wrote: > > > > Thanks for the clarification. I understand now. > > On Thu, Dec 31, 2015 at 16:52 Karel Gardas > > wrote: > > > > On 12/31/15 07:41 PM, Alain O'Dea wrote: > > > Yes. I can do that. > > > > > > On SmartOS it may not be GCC 3.4.3 causing this. I see this > > on GCC 4.7.x > > > through 4.9.x. The paths to gcc on SmartOS also differ. I'll > > have to > > > verify that as part of checking this. > > > > This is misunderstanding. GCC 3.4.3 provides *correct* CPP > behavior, > > while all 4.x provides broken CPP. That means as a workaround > > when GCC > > 3.4.3 is installed I set it as GHC's CPP automatically on > > Solaris. When > > it is not available, then GHC behaves like you've seen when > > using CPP... > > > > Hopefully this is more clear now, > > > > Karel > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alain.odea at gmail.com Fri Jan 1 20:28:36 2016 From: alain.odea at gmail.com (Alain O'Dea) Date: Fri, 01 Jan 2016 20:28:36 +0000 Subject: Flag warnings show intermediate hscpp filenames on SmartOS In-Reply-To: References: <5684E713.4050503@centrum.cz> <87a8oq94xe.fsf@smart-cactus.org> <568547F8.1040209@centrum.cz> <56858E53.8010105@centrum.cz> <5686618A.30905@centrum.cz> Message-ID: Actually Karel, if "gcc -dumpspecs" shows you that same -P as I get you can override it with spec files as described here: https://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html I think this means that you could specify "gcc -specs=/path/to/overridecpp.spec" as --with-hs-cpp when building GHC. I'm trying that now. I've already gotten a strawman example based on your post to the GCC list working, and I'm going to try to expand on it. On Fri, Jan 1, 2016 at 3:08 PM Alain O'Dea wrote: > True, but I'd still like to find a mutual solution since we're both > somewhat at the edge of the supported landscape for GHC. > > Is installing cpphs and configuring GHC to use that an option on Solaris > 11? I haven't built cpphs successfully on SmartOS yet. Supplying a custom C > preprocessor may be your best bet and using GCC 3.4's works for you. If I > can get cpphs working that may be the common ground needed to keep Illumos > and Solaris support from diverging. > > On Fri, Jan 1, 2016 at 7:52 AM Karel Gardas > wrote: > >> >> Alain, >> >> indeed, on SmartOS you are free to modify the supplied GCC so the fix to >> remove -P is most natural one. On the other hand I'm not so lucky with >> binary Solaris 11.x distribution provided by Oracle so I need to use not >> so clean and nice workarounds... >> >> Karel >> >> On 01/ 1/16 12:17 AM, Alain O'Dea wrote: >> > cpphs isn't a direct option. It won't install on SmartOS with Cabal. >> > GCC 4.7 is the earliest GCC supported so I'll have to try something else >> > for SmartOS. >> > >> > It looks like the GCC Specs are the problem. >> > >> > On Ubuntu the Spec for cpp is: >> > >> > *cpp: >> > %{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT} >> > >> > On SmartOS the Spec for cpp is: >> > >> > *cpp: >> > %{,assembler-with-cpp:-P} %(cpp_subtarget) >> > >> > I think this is how the -P gets injected. I think this is correctable. >> > I had a similar issue with -std=c99 which is the default for C compiling >> > on Ubuntu but not on SmartOS leading to issues with compiling source >> > that isn't old school C (like persistent-sqlite). >> > >> > Anyways I must retire from this and entertain my guests. Happy New Year >> > folks. >> > >> > >> > On Thu, Dec 31, 2015 at 5:19 PM Alain O'Dea > > > wrote: >> > >> > Thanks for the clarification. I understand now. >> > On Thu, Dec 31, 2015 at 16:52 Karel Gardas > > > wrote: >> > >> > On 12/31/15 07:41 PM, Alain O'Dea wrote: >> > > Yes. I can do that. >> > > >> > > On SmartOS it may not be GCC 3.4.3 causing this. I see this >> > on GCC 4.7.x >> > > through 4.9.x. The paths to gcc on SmartOS also differ. I'll >> > have to >> > > verify that as part of checking this. >> > >> > This is misunderstanding. GCC 3.4.3 provides *correct* CPP >> behavior, >> > while all 4.x provides broken CPP. That means as a workaround >> > when GCC >> > 3.4.3 is installed I set it as GHC's CPP automatically on >> > Solaris. When >> > it is not available, then GHC behaves like you've seen when >> > using CPP... >> > >> > Hopefully this is more clear now, >> > >> > Karel >> > >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From alain.odea at gmail.com Fri Jan 1 21:02:04 2016 From: alain.odea at gmail.com (Alain O'Dea) Date: Fri, 01 Jan 2016 21:02:04 +0000 Subject: Flag warnings show intermediate hscpp filenames on SmartOS In-Reply-To: References: <5684E713.4050503@centrum.cz> <87a8oq94xe.fsf@smart-cactus.org> <568547F8.1040209@centrum.cz> <56858E53.8010105@centrum.cz> <5686618A.30905@centrum.cz> Message-ID: Okay Karel. I have a solution that works to make T2464 pass. Create overridecpp.spec: *cpp: %{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT} Create ghc-cpp and make it executable: #!/bin/bash gcc -spec=/path/to/overridecpp.spec $@ Configure and make GHC with ghc-cpp and run T2464: ./configure --with-hs-cpp=/path/to/ghc-cpp make -j8 make TEST=T2464 test This should work on Solaris 11 as well. So GHC could ship a GCC Specs file like this and that wrapper script as an interim solution. In the interim I'll include these as patches in PKGSRC and get a GHC 7.10.3 built with them applied. I'm going to hold off on PKGSRC stuff until I get fixes for more of the failing tests though. Does this seem like a reasonable solution to you? On Fri, Jan 1, 2016 at 4:58 PM Alain O'Dea wrote: > Actually Karel, if "gcc -dumpspecs" shows you that same -P as I get you > can override it with spec files as described here: > https://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html > > I think this means that you could specify "gcc > -specs=/path/to/overridecpp.spec" as --with-hs-cpp when building GHC. I'm > trying that now. I've already gotten a strawman example based on your post > to the GCC list working, and I'm going to try to expand on it. > > On Fri, Jan 1, 2016 at 3:08 PM Alain O'Dea wrote: > >> True, but I'd still like to find a mutual solution since we're both >> somewhat at the edge of the supported landscape for GHC. >> >> Is installing cpphs and configuring GHC to use that an option on Solaris >> 11? I haven't built cpphs successfully on SmartOS yet. Supplying a custom C >> preprocessor may be your best bet and using GCC 3.4's works for you. If I >> can get cpphs working that may be the common ground needed to keep Illumos >> and Solaris support from diverging. >> >> On Fri, Jan 1, 2016 at 7:52 AM Karel Gardas >> wrote: >> >>> >>> Alain, >>> >>> indeed, on SmartOS you are free to modify the supplied GCC so the fix to >>> remove -P is most natural one. On the other hand I'm not so lucky with >>> binary Solaris 11.x distribution provided by Oracle so I need to use not >>> so clean and nice workarounds... >>> >>> Karel >>> >>> On 01/ 1/16 12:17 AM, Alain O'Dea wrote: >>> > cpphs isn't a direct option. It won't install on SmartOS with Cabal. >>> > GCC 4.7 is the earliest GCC supported so I'll have to try something >>> else >>> > for SmartOS. >>> > >>> > It looks like the GCC Specs are the problem. >>> > >>> > On Ubuntu the Spec for cpp is: >>> > >>> > *cpp: >>> > %{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT} >>> > >>> > On SmartOS the Spec for cpp is: >>> > >>> > *cpp: >>> > %{,assembler-with-cpp:-P} %(cpp_subtarget) >>> > >>> > I think this is how the -P gets injected. I think this is correctable. >>> > I had a similar issue with -std=c99 which is the default for C >>> compiling >>> > on Ubuntu but not on SmartOS leading to issues with compiling source >>> > that isn't old school C (like persistent-sqlite). >>> > >>> > Anyways I must retire from this and entertain my guests. Happy New >>> Year >>> > folks. >>> > >>> > >>> > On Thu, Dec 31, 2015 at 5:19 PM Alain O'Dea >> > > wrote: >>> > >>> > Thanks for the clarification. I understand now. >>> > On Thu, Dec 31, 2015 at 16:52 Karel Gardas < >>> karel.gardas at centrum.cz >>> > > wrote: >>> > >>> > On 12/31/15 07:41 PM, Alain O'Dea wrote: >>> > > Yes. I can do that. >>> > > >>> > > On SmartOS it may not be GCC 3.4.3 causing this. I see this >>> > on GCC 4.7.x >>> > > through 4.9.x. The paths to gcc on SmartOS also differ. I'll >>> > have to >>> > > verify that as part of checking this. >>> > >>> > This is misunderstanding. GCC 3.4.3 provides *correct* CPP >>> behavior, >>> > while all 4.x provides broken CPP. That means as a workaround >>> > when GCC >>> > 3.4.3 is installed I set it as GHC's CPP automatically on >>> > Solaris. When >>> > it is not available, then GHC behaves like you've seen when >>> > using CPP... >>> > >>> > Hopefully this is more clear now, >>> > >>> > Karel >>> > >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.stolarek at p.lodz.pl Sun Jan 3 13:31:11 2016 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Sun, 3 Jan 2016 14:31:11 +0100 Subject: Open data kinds In-Reply-To: <22BB132B-D635-42A8-87B5-8AF24608EED8@cis.upenn.edu> References: <201512162021.27013.jan.stolarek@p.lodz.pl> <22BB132B-D635-42A8-87B5-8AF24608EED8@cis.upenn.edu> Message-ID: <201601031431.11586.jan.stolarek@p.lodz.pl> I rewrote the wiki page to include open data kinds proposal: https://ghc.haskell.org/trac/ghc/wiki/GhcKinds/KindsWithoutData It would be a Good Thing to agree on the syntax before it gets implemented. So if anyone wants to express their preference or have a constuctive argument for/against some particular proposal now is a good time. I would like to start working on the implementation sometime soonish. Janek Dnia czwartek, 17 grudnia 2015, Richard Eisenberg napisa?: > Janek and I discussed this issue this morning, and I would like to state my > opinion and state my case: > > * In `kind K = T`, `T` should live in the data-level namespace. > > Of course, if `T` is used in a term-level expression, an error should be > issued, because T logically lives only in types. > > To explain why I feel this way, it's helpful to reflect on the 4 namespaces > Haskell currently has. I will refer to these by number. > > 1. Term-level data constructors and pattern synonyms > 2. Types, classes, and type constructors > 3. Term-level variables and globals > 4. Type variables > > The debate at hand only involves 1 and 2. We are adding a new feature to > the language. Should it go in namespace 1 or namespace 2? To help decide, > it would be nice to have a general principle of what goes in 1 and what > goes in 2. Here is one possible principle: > > A. Namespace 1 contains runtime things; namespace 2 contains compile-time > things. > > Principle A has served us well for some time. But it's failing us now. With > DataKinds, we can use namespace-1 things at compile-time. And some of us > have been scheming for a way to use namespace-2 things at runtime. So > Principle A doesn't seem quite right. Instead, I propose > > B. Namespace 1 contains data constructors (and, closely related, pattern > synonyms); namespace 2 contains datatypes (and, closely related, classes). > > Up until DataKinds, Principles A and B have coincided. But now they have > diverged, and only Principle B serves to describe what's going on. > > (Aside: When you say True in a type, and it's in scope, that's because GHC > looks in namespace 2 first; failing that, it looks in namespace 1. > DataKinds never copies namespace-1 things into namespace 2.) > > If we thus adopt Principle B, then we indeed want `T` from the example to > live in namespace 1. It is a data constructor. One might argue that this is > a misnomer, because T lives only at compile time. T indeed does live only > at compile time, but it still is a data constructor -- it constructs > compile-time data. (Just like using 'True in a type doesn't make 'True any > less of a data constructor.) > > A noted drawback of Principle B is that it means that compile-time only > definitions "pollute" namespace 1. That's true. But it need be only local, > as you're free to make namespace-2 type synonyms that refer to namespace-1 > data constructors. And it's quite straightforward to ensure that `T` is > never present at runtime -- it's just a straightforward check in the > typechecker. > > Thus, according to general Principle B, `T` should be in namespace 1. > > What do you think? > > Richard > > On Dec 16, 2015, at 2:21 PM, Jan Stolarek wrote: > > Devs, > > > > I plan to work on implementing open data kinds (#11080). The idea is that > > users will be allowed to declare open kinds and then populate them with > > member types. Perhaps I will also implement closed data kinds. This is > > already possible using DataKinds, but the idea is to declare a data kind > > without corresponding data type - see #6024. > > > > Now, consider this declaration (syntax subject to bikeshedding): > > > > kind K = T > > > > In what namespace should T go: type namespace or data constructor > > namespace? If we put it in type namespace then it is possible for the > > user to declare a data constructor T that is completely unrelated to type > > T belonging to kind K. This might be confusing. If we put T in the data > > namespace then we miss the point of #6024. > > > > Thoughts? > > > > Janek > > > > --- > > Politechnika ??dzka > > Lodz University of Technology > > > > Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. > > Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez > > pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. > > > > This email contains information intended solely for the use of the > > individual to whom it is addressed. If you are not the intended recipient > > or if you have received this message in error, please notify the sender > > and delete it from your system. > > _______________________________________________ > > 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 matthewtpickering at gmail.com Sun Jan 3 14:03:27 2016 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Sun, 3 Jan 2016 14:03:27 +0000 Subject: Open data kinds In-Reply-To: <201601031431.11586.jan.stolarek@p.lodz.pl> References: <201512162021.27013.jan.stolarek@p.lodz.pl> <22BB132B-D635-42A8-87B5-8AF24608EED8@cis.upenn.edu> <201601031431.11586.jan.stolarek@p.lodz.pl> Message-ID: Jan, Is there a specific reason for implementing closed data kinds? The way I have been thinking about open data kinds is that they should be like defining types. There is no language support to define a "closed datatype" but it is possible to do so by not exporting any of the constructors used to make the datatype. To be clear, by doing so external modules can't create more values of the type, much like consumers can't 'extend' the kind if the library author has define a closed data kind. Is the same not possible here? Am I misunderstanding the proposal? Matt On Sun, Jan 3, 2016 at 1:31 PM, Jan Stolarek wrote: > I rewrote the wiki page to include open data kinds proposal: > > https://ghc.haskell.org/trac/ghc/wiki/GhcKinds/KindsWithoutData > > It would be a Good Thing to agree on the syntax before it gets implemented. So if anyone wants to > express their preference or have a constuctive argument for/against some particular proposal now > is a good time. > > I would like to start working on the implementation sometime soonish. > > Janek > > Dnia czwartek, 17 grudnia 2015, Richard Eisenberg napisa?: >> Janek and I discussed this issue this morning, and I would like to state my >> opinion and state my case: >> >> * In `kind K = T`, `T` should live in the data-level namespace. >> >> Of course, if `T` is used in a term-level expression, an error should be >> issued, because T logically lives only in types. >> >> To explain why I feel this way, it's helpful to reflect on the 4 namespaces >> Haskell currently has. I will refer to these by number. >> >> 1. Term-level data constructors and pattern synonyms >> 2. Types, classes, and type constructors >> 3. Term-level variables and globals >> 4. Type variables >> >> The debate at hand only involves 1 and 2. We are adding a new feature to >> the language. Should it go in namespace 1 or namespace 2? To help decide, >> it would be nice to have a general principle of what goes in 1 and what >> goes in 2. Here is one possible principle: >> >> A. Namespace 1 contains runtime things; namespace 2 contains compile-time >> things. >> >> Principle A has served us well for some time. But it's failing us now. With >> DataKinds, we can use namespace-1 things at compile-time. And some of us >> have been scheming for a way to use namespace-2 things at runtime. So >> Principle A doesn't seem quite right. Instead, I propose >> >> B. Namespace 1 contains data constructors (and, closely related, pattern >> synonyms); namespace 2 contains datatypes (and, closely related, classes). >> >> Up until DataKinds, Principles A and B have coincided. But now they have >> diverged, and only Principle B serves to describe what's going on. >> >> (Aside: When you say True in a type, and it's in scope, that's because GHC >> looks in namespace 2 first; failing that, it looks in namespace 1. >> DataKinds never copies namespace-1 things into namespace 2.) >> >> If we thus adopt Principle B, then we indeed want `T` from the example to >> live in namespace 1. It is a data constructor. One might argue that this is >> a misnomer, because T lives only at compile time. T indeed does live only >> at compile time, but it still is a data constructor -- it constructs >> compile-time data. (Just like using 'True in a type doesn't make 'True any >> less of a data constructor.) >> >> A noted drawback of Principle B is that it means that compile-time only >> definitions "pollute" namespace 1. That's true. But it need be only local, >> as you're free to make namespace-2 type synonyms that refer to namespace-1 >> data constructors. And it's quite straightforward to ensure that `T` is >> never present at runtime -- it's just a straightforward check in the >> typechecker. >> >> Thus, according to general Principle B, `T` should be in namespace 1. >> >> What do you think? >> >> Richard >> >> On Dec 16, 2015, at 2:21 PM, Jan Stolarek wrote: >> > Devs, >> > >> > I plan to work on implementing open data kinds (#11080). The idea is that >> > users will be allowed to declare open kinds and then populate them with >> > member types. Perhaps I will also implement closed data kinds. This is >> > already possible using DataKinds, but the idea is to declare a data kind >> > without corresponding data type - see #6024. >> > >> > Now, consider this declaration (syntax subject to bikeshedding): >> > >> > kind K = T >> > >> > In what namespace should T go: type namespace or data constructor >> > namespace? If we put it in type namespace then it is possible for the >> > user to declare a data constructor T that is completely unrelated to type >> > T belonging to kind K. This might be confusing. If we put T in the data >> > namespace then we miss the point of #6024. >> > >> > Thoughts? >> > >> > Janek >> > >> > --- >> > Politechnika ??dzka >> > Lodz University of Technology >> > >> > Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. >> > Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez >> > pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. >> > >> > This email contains information intended solely for the use of the >> > individual to whom it is addressed. If you are not the intended recipient >> > or if you have received this message in error, please notify the sender >> > and delete it from your system. >> > _______________________________________________ >> > 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. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From jan.stolarek at p.lodz.pl Sun Jan 3 17:31:21 2016 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Sun, 3 Jan 2016 18:31:21 +0100 Subject: Open data kinds In-Reply-To: References: <201512162021.27013.jan.stolarek@p.lodz.pl> <201601031431.11586.jan.stolarek@p.lodz.pl> Message-ID: <201601031831.21660.jan.stolarek@p.lodz.pl> > There is no language support to define a > "closed datatype" but it is possible to do so by not exporting any of > the constructors used to make the datatype. Data types are closed in a sense that if you define data Foo = MkFoo1 then you cannot add new data constructor, say MkFoo2, that will also create values of type Foo. So being open/closed is not about creating new values of a data type but about extending the definition with new constructors. Does that answer your question? Janek --- Politechnika ??dzka Lodz University of Technology Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system. From mail at joachim-breitner.de Mon Jan 4 23:10:15 2016 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 05 Jan 2016 00:10:15 +0100 Subject: latest symlink Message-ID: <1451949015.10759.1.camel@joachim-breitner.de> Hi, https://downloads.haskell.org/~ghc/latest/?still points to https://downloads.haskell.org/~ghc/7.10.2/?and not https://downloads.haskell.org/~ghc/7.10.3/ Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From ben at smart-cactus.org Mon Jan 4 23:32:12 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Tue, 05 Jan 2016 00:32:12 +0100 Subject: latest symlink In-Reply-To: <1451949015.10759.1.camel@joachim-breitner.de> References: <1451949015.10759.1.camel@joachim-breitner.de> Message-ID: <87poxgrkeb.fsf@smart-cactus.org> Joachim Breitner writes: > Hi, > > https://downloads.haskell.org/~ghc/latest/?still points to > https://downloads.haskell.org/~ghc/7.10.2/?and not > https://downloads.haskell.org/~ghc/7.10.3/ > So you are right. It should be fixed now. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From omeragacan at gmail.com Tue Jan 5 16:05:24 2016 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Tue, 5 Jan 2016 11:05:24 -0500 Subject: Implementation idea for unboxed polymorphic types In-Reply-To: References: <1194C002-769A-4232-A2BC-632875496F37@mazzo.li> Message-ID: That's a really good question, I think. I tried to make it working here: https://gist.github.com/osa1/00597c24a79816c7ef90/ In that code, just assume whenever you see a type or constructor with Ubx prefix it's just magically get unboxed. I added lots of inline comments about problems and results etc. but in short, we have a problem that this idea doesn't solve: GHC doesn't generate specialized functions at all. So if I have a function that's too big to inline or if I simply don't want to inline for some reason, we're out of luck. (I don't understand this restriction, specialization without inlining would be very useful in lots of cases, I think) Second thing is ideally we shouldn't be using unboxed types in the code manually. For example, in the `distance` functions we should really write `distance :: Point a => Point a -> a`. But this means that `Unbox` typeclass needs to be magical, GHC should recognize it and specialize functions using Unbox dictionaries. 2015-11-17 10:54 GMT-05:00 Alexey Vagarenko : > At the moment, GHC does not support type families over kind #, > but if it did, would this code do the trick > https://gist.github.com/vagarenko/077c6dd73cd610269aa9 ? > > 2015-11-16 22:32 GMT+05:00 ?mer Sinan A?acan : >> >> > But I don't see why you'd need quoting at constructor calls. Couldn't >> > you >> > just have a type class like `PointFamily`? >> >> This is exactly right, my memory has failed me. My initial implementation >> didn't use the type family trick, I had further attempts that use type >> families >> but honestly I don't remember how good it worked. This was quite a while >> ago. >> >> 2015-11-15 19:41 GMT-05:00 Richard Eisenberg : >> > After reading Francesco's original post, I immediately thought of ?mer's >> > proposed approach, of using Template Haskell to produce the right data >> > family instances. But I don't see why you'd need quoting at constructor >> > calls. Couldn't you just have a type class like `PointFamily`? I'd be more >> > interested to see client code in ?mer's version than the TH generation code. >> > >> > The TH approach would seem to require having a fixed set of >> > specializations, which is a downside. But I'm not sure it's so much of a >> > downside that the approach is unusable. >> > >> > Richard >> > >> > On Nov 15, 2015, at 10:08 AM, ?mer Sinan A?acan >> > wrote: >> > >> >> I had started working on exactly the same thing at some point. I had a >> >> TemplateHaskell-based implementation which _almost_ worked. >> >> >> >> The problem was that the syntax was very, very heavy. Because I had to >> >> use >> >> quotes for _every_ constructor application(with explicitly passed >> >> types). >> >> (because I had a specialized constructor for every instantiation of >> >> this >> >> generic type) >> >> >> >> Another problem was that because of how TemplateHaskell quotes >> >> evaluated, I >> >> couldn't use a `List Int` where `List` is a template without first >> >> manually >> >> adding a line for generating specialized version of `List` on `Int`. >> >> >> >> When all of these combined it became very hard to use. But it was a >> >> proof-of-concept and I think it worked. >> >> >> >> (Code is horrible so I won't share it here :) I had to maintain a state >> >> shared >> >> with different TH quote evaluations etc.) >> >> >> >> 2015-11-15 5:26 GMT-05:00 Francesco Mazzoli : >> >>> (A nicely rendered version of this email can be found at >> >>> ) >> >>> >> >>> ## Macro types >> >>> >> >>> I very often find myself wanting unboxed polymorphic types >> >>> (e.g. types that contain `UNPACK`ed type variables). I find >> >>> it extremely frustrating that it's easier to write fast _and_ >> >>> generic code in C++ than in Haskell. >> >>> >> >>> I'd like to submit to the mailing list a very rough proposal >> >>> on how this could be achieved in a pretty straightforward way >> >>> in GHC. >> >>> >> >>> The proposal is meant to be a proof of concept, just to show that >> >>> this could be done rather easily. I did not think about a nice >> >>> interface or the implementation details in GHC. My goal is to >> >>> check the feasibility of this plan with GHC developers. >> >>> >> >>> I'll call such types "macro types", since their effect is similar >> >>> to defining a macro that defines a new type for each type >> >>> variable instantiation. >> >>> >> >>> Consider >> >>> >> >>> ``` >> >>> data #Point a = Point >> >>> { x :: {-# UNPACK #-} !a >> >>> , y :: {-# UNPACK #-} !a >> >>> } >> >>> ``` >> >>> >> >>> This definition defines the macro type `#Point`, with one parameter >> >>> `a`. >> >>> >> >>> Macro types definition would be allowed only for single-constructor >> >>> records. The intent is that if we mention `#Point Double`, it will >> >>> be equivalent to >> >>> >> >>> ``` >> >>> data PointDouble = PointDouble >> >>> { x :: {-# UNPACK #-} !Double >> >>> , y :: {-# UNPACK #-} !Double >> >>> } >> >>> ``` >> >>> >> >>> To use `#Point` generically, the following type class would be >> >>> generated: >> >>> >> >>> ``` >> >>> class PointFamily a where >> >>> data #Point a :: * -- Family of types generated by @data #Point a at . >> >>> #Point :: a -> a -> #Point a -- Constructor. >> >>> #x :: #Point a -> a -- Projection @x at . >> >>> #y :: #Point a -> a -- Projection @y at . >> >>> ``` >> >>> >> >>> Thi type class lets us work with `#Point`s generically, for example >> >>> >> >>> ``` >> >>> distance :: (PointFamily a, Fractional a) => #Point a -> #Point a -> a >> >>> distance p1 p2 = >> >>> let dx = #x p1 - #x p2 >> >>> dy = #y p1 - #y p2 >> >>> in sqrt (dx*dx + dy*dy) >> >>> ``` >> >>> >> >>> Internally, for every type appearing for `a`, e.g. `#Point Double`, >> >>> a new type equivalent to the `PointDouble` above would be generated >> >>> by GHC, with the corresponding instance >> >>> >> >>> ``` >> >>> instance PointFamily Double where >> >>> data #Point Double = PointDouble >> >>> #x = x >> >>> #y = x >> >>> ``` >> >>> >> >>> If it's not possible to instantiate `#Point` with the provided type >> >>> (for example because the type is not `UNPACK`able, e.g. >> >>> `#Point (Maybe A)`), GHC would throw an error. >> >>> >> >>> Note that we can compile `distance` in its polymorphic version >> >>> (as opposed to C++ templates, where template functions _must_ be >> >>> instantiated at every use). The polymorphic `distance` would >> >>> require a call to "virtual functions" `#x` and `#y`, as provided by >> >>> the `PointFamily` dictionary. But if we use >> >>> `INLINE` or `SPECIALIZE` pragmas the virtual calls to `#x` and `#y` >> >>> would disappear, making this as efficient as if we were to define >> >>> `distance` on the manually defined `PointDouble`. Compiler hints >> >>> would be put in place to always inline functions using macro types, >> >>> if possible. >> >>> >> >>> Note that the inlining is only important so that the `PointFamily` >> >>> dictionary disappears, e.g. functions containing recursive >> >>> helpers are fine, such as >> >>> >> >>> ``` >> >>> {-# INLINE leftmost #-} >> >>> leftmost :: forall a. (PointFamily a, Ord a) => [#Point a] -> #Point a >> >>> leftmost [] = error "leftmost: no points" >> >>> leftmost (p0 : ps0) = go p0 ps0 >> >>> where >> >>> go :: #Point a -> [#Point a] -> Point# a >> >>> go candidate (p : ps) = >> >>> if #x p < #x candidate >> >>> then go p ps >> >>> else go candidate ps >> >>> ``` >> >>> >> >>> It might be worth considering throwing a warning when a top-level >> >>> definition whose type contains a macro type cannot be inlined, since >> >>> the main performance benefit of using macro types would be lost. >> >>> >> >>> We can define instances for these types as normal, for instance >> >>> >> >>> ``` >> >>> instance (Show a, PointFamily a) => Show (#Point a) where >> >>> {-# INLINE show #-} >> >>> show pt = "Point{x = " ++ #x pt ++ ", y = " ++ #y pt ++ "}" >> >>> ``` >> >>> >> >>> `deriving` support could also be added. >> >>> >> >>> ## Further ideas >> >>> >> >>> ### Hide or remove `PointFamily` from the user >> >>> >> >>> In the examples above `PointFamily` is manipulated explicitely >> >>> (e.g. in the type signature for `distance`). >> >>> In most cases the right constraint could be generated >> >>> automatically by GHC, although I think direct access to the >> >>> type class would be beneficial (history shows that direct >> >>> access to these facilities is good, see upcoming explicit >> >>> type applications). >> >>> >> >>> Maybe the type class associated to a macro type should not even >> >>> exist -- for example we could simply represent `#Point` as a type >> >>> family and treat construction and destruction as built-in syntax >> >>> (the `#` prefix). >> >>> >> >>> ### Pattern matching >> >>> >> >>> Sugar could be added to pattern match, e.g. >> >>> >> >>> ``` >> >>> foo :: Point# a -> ... >> >>> distance (Point# x1 y1) = ... >> >>> or >> >>> dinstance Point#{..} = ... -- #x and #y are available >> >>> ``` >> >>> >> >>> ### No "record types" limitation >> >>> >> >>> Instead of restricting ourselves to single-constructor records, >> >>> we could simply generate >> >>> >> >>> ``` >> >>> data Point a = Point a >> >>> { x :: !a >> >>> , y :: !a >> >>> } >> >>> >> >>> class PointFamily a where >> >>> data Point# a :: * >> >>> destruct :: Point# a -> Point a >> >>> construct :: Point a -> Point# a >> >>> ``` >> >>> >> >>> However, I think it would be harder to guarantee the well-behavedness >> >>> of the inlined functions if we had this intermediate type. I also >> >>> don't think macro types would be very useful beyond polymorphic >> >>> unboxed types. >> >>> _______________________________________________ >> >>> ghc-devs mailing list >> >>> ghc-devs at haskell.org >> >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> _______________________________________________ >> >> ghc-devs mailing list >> >> ghc-devs at haskell.org >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > From simonpj at microsoft.com Tue Jan 5 17:29:54 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 5 Jan 2016 17:29:54 +0000 Subject: Generics Message-ID: Hi Ryan In a fit of housekeeping I added a ?Generics? keyword to the generics-related tickets that you are now masterminding, so that we can have an auto-generated list on the Generics home page https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/GenericDeriving Any progress you can make would be great! Thanks Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From niteria at gmail.com Tue Jan 5 17:39:54 2016 From: niteria at gmail.com (Bartosz Nitka) Date: Tue, 5 Jan 2016 17:39:54 +0000 Subject: uniqAway and collisions Message-ID: Hi, I'm running into core lint issues [1] with my determinism patch [2] and they appear to come down to uniqAway coming up with a Unique that's already used in the expression. That creates a collision, making next substitution substitute more than it needs. I have 2 questions: 1. When is it safe to use uniqAway? 2. Is my conclusion reasonable given this trace: (full trace here [3])? I. We start out with (line 123): CallStack (from ImplicitParams): pprSTrace, called at compiler/coreSyn/CoreLint.hs:659:12 in ghc:CoreLint e: EqConstr @ (s_Xpw a_Xpz) @ (s_Xpw b_Xpy) @ s_Xpw @ b_Xpy @ a_Xpz @~ (_N :: s_Xpw a_Xpz ~# s_Xpw a_Xpz) @~ (_N :: s_Xpw b_Xpy ~# s_Xpw b_Xpy) dt_aq3 fun: EqConstr args: [TYPE: s_Xpw a_Xpz, TYPE: s_Xpw b_Xpy, TYPE: s_Xpw, TYPE: b_Xpy, TYPE: a_Xpz, CO: _N, CO: _N, dt_aq3] fun_ty: forall a_apr b_aps (s_Xpw :: * -> *) b_Xpy a_Xpz. (a_apr ~# s_Xpw a_Xpz, b_aps ~# s_Xpw b_Xpy) => EqTypes a_Xpz b_Xpy -> EqTypes a_apr b_aps II. Then we create s_Xpz with uniqAway (line 499) which has the same unique as a_Xpz above CallStack (from ImplicitParams): pprSTrace, called at compiler/types/TyCoRep.hs:1947:5 in ghc:TyCoRep old_var: s_Xpy new_var: s_Xpz III. Which causes trouble when we want to substitute s_Xpw for s_Xpz and we substitute a_Xpz as well (line 733): CallStack (from ImplicitParams): pprSTrace, called at compiler/coreSyn/CoreLint.hs:813:11 in ghc:CoreLint substTyWith [tv] [arg_ty] body_ty forall b_XpB a_XpD. (s_Xpw s_Xpw ~# s_Xpw a_XpD, s_Xpw b_Xpy ~# s_Xpw b_XpB) => EqTypes a_XpD b_XpB -> EqTypes (s_Xpw s_Xpw) (s_Xpw b_Xpy) The uniqAway comes from substTyVarBndrCallback which blames to nokinds patch. Thanks, Bartosz [1] https://phabricator.haskell.org/P77 [2] https://phabricator.haskell.org/P76 [3] https://phabricator.haskell.org/P78 -------------- next part -------------- An HTML attachment was scrubbed... URL: From xichekolas at gmail.com Tue Jan 5 18:49:13 2016 From: xichekolas at gmail.com (Andrew Farmer) Date: Tue, 5 Jan 2016 12:49:13 -0600 Subject: latest symlink In-Reply-To: <87poxgrkeb.fsf@smart-cactus.org> References: <1451949015.10759.1.camel@joachim-breitner.de> <87poxgrkeb.fsf@smart-cactus.org> Message-ID: Possibly related, when I use hoogle to look up GHC things ("+ghc Unique", for instance) and try to click through to the haddocks, it always 404s. If I change the link from: https://downloads.haskell.org/~ghc/latest/docs/html/libraries/ghc/Unique.html#t:Unique to: https://downloads.haskell.org/~ghc/latest/docs/html/libraries/ghc-7.10.3/Unique.html#t:Unique Then it works. So, is there a way to point: https://downloads.haskell.org/~ghc/latest/docs/html/libraries/ghc to: https://downloads.haskell.org/~ghc/latest/docs/html/libraries/ghc-7.10.3 ? On Mon, Jan 4, 2016 at 5:32 PM, Ben Gamari wrote: > Joachim Breitner writes: > >> Hi, >> >> https://downloads.haskell.org/~ghc/latest/ still points to >> https://downloads.haskell.org/~ghc/7.10.2/ and not >> https://downloads.haskell.org/~ghc/7.10.3/ >> > So you are right. It should be fixed now. > > Cheers, > > - Ben > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From ben at well-typed.com Tue Jan 5 20:48:05 2016 From: ben at well-typed.com (Ben Gamari) Date: Tue, 05 Jan 2016 21:48:05 +0100 Subject: latest symlink In-Reply-To: References: <1451949015.10759.1.camel@joachim-breitner.de> <87poxgrkeb.fsf@smart-cactus.org> Message-ID: <87io3792ii.fsf@smart-cactus.org> Andrew Farmer writes: > Possibly related, when I use hoogle to look up GHC things ("+ghc > Unique", for instance) and try to click through to the haddocks, it > always 404s. > I've gone ahead and created a symlink for now. That being said, this seems like a very hacky solution. Moreover, I doubt that the database that the haskell.org Hoogle instance is using matches the current state of the code. We should probably try to update it. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From xichekolas at gmail.com Tue Jan 5 21:05:53 2016 From: xichekolas at gmail.com (Andrew Farmer) Date: Tue, 5 Jan 2016 15:05:53 -0600 Subject: latest symlink In-Reply-To: <87io3792ii.fsf@smart-cactus.org> References: <1451949015.10759.1.camel@joachim-breitner.de> <87poxgrkeb.fsf@smart-cactus.org> <87io3792ii.fsf@smart-cactus.org> Message-ID: Yeah, I had to ask for this once before and it broke again with a new GHC version, so I figured it wasn't the right solution. I take it most people don't use hoogle on the GHC codebase... but I find it useful to search by type signature. Thanks for the temporary fix though! On Tue, Jan 5, 2016 at 2:48 PM, Ben Gamari wrote: > Andrew Farmer writes: > >> Possibly related, when I use hoogle to look up GHC things ("+ghc >> Unique", for instance) and try to click through to the haddocks, it >> always 404s. >> > I've gone ahead and created a symlink for now. That being said, this > seems like a very hacky solution. > > Moreover, I doubt that the database that the haskell.org Hoogle instance > is using matches the current state of the code. We should probably try > to update it. > > Cheers, > > - Ben > From ezyang at mit.edu Wed Jan 6 00:49:48 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Tue, 05 Jan 2016 16:49:48 -0800 Subject: uniqAway and collisions In-Reply-To: References: Message-ID: <1452041269-sup-5491@sabre> Hello Bartosz, The principle between uniqAway is described in the "Secrets of the GHC Inliner" paper http://research.microsoft.com/en-us/um/people/simonpj/Papers/inlining/ I doubt there's a bug in uniqAway; it's more likely the in scope set is not correct. Edward Excerpts from Bartosz Nitka's message of 2016-01-05 09:39:54 -0800: > Hi, > > I'm running into core lint issues [1] with my determinism patch [2] and > they appear to come down to uniqAway coming up with a Unique that's already > used in the expression. That creates a collision, making next substitution > substitute more than it needs. > > I have 2 questions: > > 1. When is it safe to use uniqAway? > > 2. Is my conclusion reasonable given this trace: (full trace here [3])? > > I. We start out with (line 123): > > CallStack (from ImplicitParams): > pprSTrace, called at compiler/coreSyn/CoreLint.hs:659:12 in ghc:CoreLint > e: EqConstr > @ (s_Xpw a_Xpz) > @ (s_Xpw b_Xpy) > @ s_Xpw > @ b_Xpy > @ a_Xpz > @~ (_N :: s_Xpw a_Xpz ~# s_Xpw a_Xpz) > @~ (_N :: s_Xpw b_Xpy ~# s_Xpw b_Xpy) > dt_aq3 > fun: EqConstr > args: [TYPE: s_Xpw a_Xpz, TYPE: s_Xpw b_Xpy, TYPE: s_Xpw, > TYPE: b_Xpy, TYPE: a_Xpz, CO: _N, CO: _N, > dt_aq3] > fun_ty: forall a_apr b_aps (s_Xpw :: * -> *) b_Xpy a_Xpz. > (a_apr ~# s_Xpw a_Xpz, b_aps ~# s_Xpw b_Xpy) => > EqTypes a_Xpz b_Xpy -> EqTypes a_apr b_aps > > II. Then we create s_Xpz with uniqAway (line 499) which has the same unique > as a_Xpz above > > CallStack (from ImplicitParams): > pprSTrace, called at compiler/types/TyCoRep.hs:1947:5 in ghc:TyCoRep > old_var: s_Xpy > new_var: s_Xpz > > III. Which causes trouble when we want to substitute s_Xpw for s_Xpz and we > substitute a_Xpz as well (line 733): > > CallStack (from ImplicitParams): > pprSTrace, called at compiler/coreSyn/CoreLint.hs:813:11 in ghc:CoreLint > substTyWith [tv] [arg_ty] body_ty forall b_XpB a_XpD. > (s_Xpw s_Xpw ~# s_Xpw a_XpD, s_Xpw > b_Xpy ~# s_Xpw b_XpB) => > EqTypes a_XpD b_XpB -> EqTypes (s_Xpw > s_Xpw) (s_Xpw b_Xpy) > > The uniqAway comes from substTyVarBndrCallback which blames to nokinds > patch. > > Thanks, > Bartosz > [1] https://phabricator.haskell.org/P77 > [2] https://phabricator.haskell.org/P76 > [3] https://phabricator.haskell.org/P78 From conal at conal.net Wed Jan 6 05:38:20 2016 From: conal at conal.net (Conal Elliott) Date: Tue, 5 Jan 2016 21:38:20 -0800 Subject: Inlining of methods (dictionary accessors) in GHC 7.10? Message-ID: Did something about change with method inlining between GHC 7.8.2 and 7.10.3? I don't mean methods attached to instances, but rather the method name itself, which I understand is defined as simple field accessors into a dictionary. I do inlining indirectly via HERMIT, and the method names are no longer successfully inlining to the accessors. The dictionaries themselves inline fine, as do field accessors for algebraic types with named fields. -- Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: From conal at conal.net Wed Jan 6 05:39:51 2016 From: conal at conal.net (Conal Elliott) Date: Tue, 5 Jan 2016 21:39:51 -0800 Subject: Inlining of methods (dictionary accessors) in GHC 7.10? In-Reply-To: References: Message-ID: Sorry for the editing error. I meant "Did something about change with ...". On Tue, Jan 5, 2016 at 9:38 PM, Conal Elliott wrote: > Did something about change with method inlining between GHC 7.8.2 and > 7.10.3? I don't mean methods attached to instances, but rather the method > name itself, which I understand is defined as simple field accessors into a > dictionary. I do inlining indirectly via HERMIT, and the method names are > no longer successfully inlining to the accessors. The dictionaries > themselves inline fine, as do field accessors for algebraic types with > named fields. > > -- Conal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xichekolas at gmail.com Wed Jan 6 06:15:29 2016 From: xichekolas at gmail.com (Andrew Farmer) Date: Tue, 5 Jan 2016 22:15:29 -0800 Subject: Inlining of methods (dictionary accessors) in GHC 7.10? In-Reply-To: References: Message-ID: I *think* we found our answer here: https://github.com/ghc/ghc/blob/2db18b8135335da2da9918b722699df684097be9/compiler/typecheck/TcInstDcls.hs#L158 On Tue, Jan 5, 2016 at 9:39 PM, Conal Elliott wrote: > Sorry for the editing error. I meant "Did something about change with ...". > > On Tue, Jan 5, 2016 at 9:38 PM, Conal Elliott wrote: >> >> Did something about change with method inlining between GHC 7.8.2 and >> 7.10.3? I don't mean methods attached to instances, but rather the method >> name itself, which I understand is defined as simple field accessors into a >> dictionary. I do inlining indirectly via HERMIT, and the method names are no >> longer successfully inlining to the accessors. The dictionaries themselves >> inline fine, as do field accessors for algebraic types with named fields. >> >> -- Conal > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From simonpj at microsoft.com Wed Jan 6 08:42:18 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 6 Jan 2016 08:42:18 +0000 Subject: uniqAway and collisions In-Reply-To: <1452041269-sup-5491@sabre> References: <1452041269-sup-5491@sabre> Message-ID: <7a049ab7194244ef9c88b48cdaba7306@DB4PR30MB030.064d.mgd.msft.net> | I doubt there's a bug in uniqAway; it's more likely the in scope set | is not correct. I think Edward is probably right here. | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | Edward Z. Yang | Sent: 06 January 2016 00:50 | To: Bartosz Nitka | Cc: ghc-devs Devs | Subject: Re: uniqAway and collisions | | Hello Bartosz, | | The principle between uniqAway is described in the "Secrets of the GHC | Inliner" paper | | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fresear | ch.microsoft.com%2fen- | us%2fum%2fpeople%2fsimonpj%2fPapers%2finlining%2f&data=01%7c01%7csimon | pj%40064d.mgd.microsoft.com%7c9562a48ea0714da096be08d316334bef%7c72f98 | 8bf86f141af91ab2d7cd011db47%7c1&sdata=D0h2%2btGYDNVaqU8wiKWvq3QA%2bLbz | 6q2BY%2f0IZA9nq%2bk%3d | | I doubt there's a bug in uniqAway; it's more likely the in scope set | is not correct. | | Edward | | Excerpts from Bartosz Nitka's message of 2016-01-05 09:39:54 -0800: | > Hi, | > | > I'm running into core lint issues [1] with my determinism patch [2] | > and they appear to come down to uniqAway coming up with a Unique | > that's already used in the expression. That creates a collision, | > making next substitution substitute more than it needs. | > | > I have 2 questions: | > | > 1. When is it safe to use uniqAway? | > | > 2. Is my conclusion reasonable given this trace: (full trace here | [3])? | > | > I. We start out with (line 123): | > | > CallStack (from ImplicitParams): | > pprSTrace, called at compiler/coreSyn/CoreLint.hs:659:12 in | ghc:CoreLint | > e: EqConstr | > @ (s_Xpw a_Xpz) | > @ (s_Xpw b_Xpy) | > @ s_Xpw | > @ b_Xpy | > @ a_Xpz | > @~ (_N :: s_Xpw a_Xpz ~# s_Xpw a_Xpz) | > @~ (_N :: s_Xpw b_Xpy ~# s_Xpw b_Xpy) | > dt_aq3 | > fun: EqConstr | > args: [TYPE: s_Xpw a_Xpz, TYPE: s_Xpw b_Xpy, TYPE: s_Xpw, | > TYPE: b_Xpy, TYPE: a_Xpz, CO: _N, CO: _N, | > dt_aq3] | > fun_ty: forall a_apr b_aps (s_Xpw :: * -> *) b_Xpy a_Xpz. | > (a_apr ~# s_Xpw a_Xpz, b_aps ~# s_Xpw b_Xpy) => | > EqTypes a_Xpz b_Xpy -> EqTypes a_apr b_aps | > | > II. Then we create s_Xpz with uniqAway (line 499) which has the same | > unique as a_Xpz above | > | > CallStack (from ImplicitParams): | > pprSTrace, called at compiler/types/TyCoRep.hs:1947:5 in | ghc:TyCoRep | > old_var: s_Xpy | > new_var: s_Xpz | > | > III. Which causes trouble when we want to substitute s_Xpw for s_Xpz | > and we substitute a_Xpz as well (line 733): | > | > CallStack (from ImplicitParams): | > pprSTrace, called at compiler/coreSyn/CoreLint.hs:813:11 in | ghc:CoreLint | > substTyWith [tv] [arg_ty] body_ty forall b_XpB a_XpD. | > (s_Xpw s_Xpw ~# s_Xpw a_XpD, | s_Xpw | > b_Xpy ~# s_Xpw b_XpB) => | > EqTypes a_XpD b_XpB -> EqTypes | > (s_Xpw | > s_Xpw) (s_Xpw b_Xpy) | > | > The uniqAway comes from substTyVarBndrCallback which blames to | nokinds | > patch. | > | > Thanks, | > Bartosz | > [1] https://phabricator.haskell.org/P77 | > [2] https://phabricator.haskell.org/P76 | > [3] https://phabricator.haskell.org/P78 | _______________________________________________ | 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%7c9562a48ea0714da | 096be08d316334bef%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=GEAnP46 | gF85287E%2bovF9vH6KmZqqeWGKNjeKvfMXcjA%3d From simonpj at microsoft.com Wed Jan 6 09:25:53 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 6 Jan 2016 09:25:53 +0000 Subject: Inlining of methods (dictionary accessors) in GHC 7.10? In-Reply-To: References: Message-ID: Quite possibly. Maybe you can give a tiny concrete example? From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Conal Elliott Sent: 06 January 2016 05:38 To: ghc-devs at haskell.org Subject: Inlining of methods (dictionary accessors) in GHC 7.10? Did something about change with method inlining between GHC 7.8.2 and 7.10.3? I don't mean methods attached to instances, but rather the method name itself, which I understand is defined as simple field accessors into a dictionary. I do inlining indirectly via HERMIT, and the method names are no longer successfully inlining to the accessors. The dictionaries themselves inline fine, as do field accessors for algebraic types with named fields. -- Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: From niteria at gmail.com Wed Jan 6 14:56:49 2016 From: niteria at gmail.com (Bartosz Nitka) Date: Wed, 6 Jan 2016 14:56:49 +0000 Subject: uniqAway and collisions In-Reply-To: <7a049ab7194244ef9c88b48cdaba7306@DB4PR30MB030.064d.mgd.msft.net> References: <1452041269-sup-5491@sabre> <7a049ab7194244ef9c88b48cdaba7306@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Hello, Thank you for the paper, it helped with my understanding of how it's supposed to work. Simon, could my issue be related to your comment here: [1]? -- Note [Generating the in-scope set for a substitution] -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- If we want to substitute [a -> ty1, b -> ty2] I used to -- think it was enough to generate an in-scope set that includes -- fv(ty1,ty2). But that's not enough; we really should also take the -- free vars of the type we are substituting into! Example: -- (forall b. (a,b,x)) [a -> List b] -- Then if we use the in-scope set {b}, there is a danger we will rename -- the forall'd variable to 'x' by mistake, getting this: -- (forall x. (List b, x, x) -- Urk! This means looking at all the calls to mkOpenTvSubst.... Currently the InScope set only contains the free variables of the arguments when linting type application [2][3][4] and doesn't contain the free variables of the body that it's substituting in. The definition of substTyWith is: substTyWith :: [TyVar] -> [Type] -> Type -> Type substTyWith tvs tys = ASSERT( length tvs == length tys ) substTy (zipOpenTCvSubst tvs tys) When I changed it to include the free variables of the body my core lint error went away: substTyWith :: [TyVar] -> [Type] -> Type -> Type substTyWith tvs tys ty = ASSERT( length tvs == length tys ) substTy (extendTCvInScopeList (zipOpenTCvSubst tvs tys) (tyCoVarsOfTypeList ty)) ty It seems unlikely to me that this is the issue, since this code is very old, but I don't have a better explanation for this and a second pair of eyes would help. Thank you, Bartosz [1] https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/types/TyCoRep.hs;cac0795af33d622e4c6ebae6ae1f206969287088$1591-1601 [2] https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/coreSyn/CoreLint.hs;cac0795af33d622e4c6ebae6ae1f206969287088$788 [3] https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/types/TyCoRep.hs;cac0795af33d622e4c6ebae6ae1f206969287088$1756 [4] https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/types/TyCoRep.hs;cac0795af33d622e4c6ebae6ae1f206969287088$1623 2016-01-06 8:42 GMT+00:00 Simon Peyton Jones : > | I doubt there's a bug in uniqAway; it's more likely the in scope set > | is not correct. > > I think Edward is probably right here. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From omeragacan at gmail.com Wed Jan 6 16:33:50 2016 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Wed, 6 Jan 2016 11:33:50 -0500 Subject: expandTypeSynonyms panics after kind equality patch Message-ID: My branch panicking during stage 2 build and when I tried to debug I realized the panicking function is `unionTCvSubst`, when called by `expandTypeSynonyms`. In my branch I'm doing some type-based transformations and I'm using `expandTypeSynonyms` on type of identifiers for that. According to git blame logs, the function `unionTCvSubst` was added with kind equality patch. The patch made this change in `expandTypeSynonyms`: - = go (mkAppTys (substTy (mkTopTvSubst tenv) rhs) tys') + = let subst' = unionTCvSubst subst (mkTopTCvSubst tenv) in + go subst' (mkAppTys rhs tys') Which is what's causing the panic. The exact place it's panicking during the stage2 build is when I call `expandTypeSynonyms` on type `TvSubstEnv` (i.e. in my transformation I get type of an id and it turns out to be TvSubstEnv, when I call `expandTypeSynonyms` on this type it panics) I figured this much but I don't understand type system details, so, does anyone here have any ideas what's going wrong here? Richard? Note that this panic happens even though I don't do any changes in types - I'm just looking at the types for some transformations but no changes on the types are done. From facundo.dominguez at tweag.io Wed Jan 6 18:39:40 2016 From: facundo.dominguez at tweag.io (=?UTF-8?Q?Facundo_Dom=C3=ADnguez?=) Date: Wed, 6 Jan 2016 16:39:40 -0200 Subject: Slowdown in concurrent program Message-ID: Dear devs, The following program shows worse measures when compiled with -O with both ghc-7.10.2 and ghc-7.8.3. Am I hitting a known bug? Or may someone point a mistake in the code? It also shows worse measures when using anything other than -N1. Thanks in advance, Facundo -- /opt/ghc-7.8.3/bin/ghc --make -threaded -fforce-recomp test.hs -- time ./test: 10 seconds -- -- /opt/ghc-7.8.3/bin/ghc --make -threaded -O -fforce-recomp test.hs -- time ./test: 48 seconds -- -- /opt/ghc-7.10.2/bin/ghc --make -threaded -fforce-recomp test.hs -- time ./test: 23 seconds -- -- /opt/ghc-7.10.2/bin/ghc --make -threaded -O -fforce-recomp test.hs -- time ./test: 57 seconds -- import Control.Concurrent import Control.Monad import Data.List main :: IO () main = do let xs = [ 1 .. 400000000] mv <- newEmptyMVar replicateM_ 4 $ forkIO $ putMVar mv $! foldl' (+) 0 xs nums <- replicateM 4 $ takeMVar mv print (nums :: [Integer]) From ben at smart-cactus.org Wed Jan 6 18:44:24 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Wed, 06 Jan 2016 19:44:24 +0100 Subject: Improving trac notifications In-Reply-To: <87twn297mm.fsf@smart-cactus.org> References: <87twn297mm.fsf@smart-cactus.org> Message-ID: <874meq8s53.fsf@smart-cactus.org> Ben Gamari writes: > Matthew Pickering writes: > >> I subscribe to the ghc-tickets[1] mailing list which provides updates >> to all trac tickets. This is very useful, however when a ticket >> description is updated the whole description is included in the email >> which makes it hard to see what actually changed. The web interface >> shows a nice diff[2] of the changes, I think it would be good if >> emails could also include a diff rather than the current quite useless >> output. >> > I think this would be a great improvement. I, for one, am quite guilty > of incrementally editing ticket descriptions and the current email > notifications are nearly useless in this case. > >> After a bit of investigation, it appears that the easiest way to >> achieve this is apply a simple patch to our copy of trac. The current >> format is hard coded on line 558 in this module, it seems easy to >> modify this section to instead provide a diff. >> > Herbert, perhaps we could do something along these lines? > Ping. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From simonpj at microsoft.com Wed Jan 6 19:59:11 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 6 Jan 2016 19:59:11 +0000 Subject: Slowdown in concurrent program In-Reply-To: References: Message-ID: That sounds bad. What happens with 8.0? Big CAFs like [1..40000000] can be problematic... does it happen in the more realistic situation where the bounds are data dependent? Open a ticket? Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Facundo | Dom?nguez | Sent: 06 January 2016 18:40 | To: ghc-devs at haskell.org | Subject: Slowdown in concurrent program | | Dear devs, | The following program shows worse measures when compiled with -O | with both ghc-7.10.2 and ghc-7.8.3. | | Am I hitting a known bug? Or may someone point a mistake in the code? | | It also shows worse measures when using anything other than -N1. | | Thanks in advance, | Facundo | | -- /opt/ghc-7.8.3/bin/ghc --make -threaded -fforce-recomp test.hs | -- time ./test: 10 seconds | -- | -- /opt/ghc-7.8.3/bin/ghc --make -threaded -O -fforce-recomp test.hs | -- time ./test: 48 seconds | -- | -- /opt/ghc-7.10.2/bin/ghc --make -threaded -fforce-recomp test.hs | -- time ./test: 23 seconds | -- | -- /opt/ghc-7.10.2/bin/ghc --make -threaded -O -fforce-recomp test.hs | -- time ./test: 57 seconds | -- | | import Control.Concurrent | import Control.Monad | import Data.List | | | main :: IO () | main = do | let xs = [ 1 .. 400000000] | mv <- newEmptyMVar | replicateM_ 4 $ forkIO $ putMVar mv $! foldl' (+) 0 xs | nums <- replicateM 4 $ takeMVar mv | print (nums :: [Integer]) | _______________________________________________ | 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%7cc87535716ced49a12e3308 | d316c8c028%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=4W%2b0W36E1O%2bZtxzEX | Besrv%2fUk6fwsvNGc5RqUAwMHDk%3d From ben at smart-cactus.org Wed Jan 6 20:21:18 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Wed, 06 Jan 2016 21:21:18 +0100 Subject: Slowdown in concurrent program In-Reply-To: References: Message-ID: <87wprm7935.fsf@smart-cactus.org> Simon Peyton Jones writes: > That sounds bad. What happens with 8.0? > Same behavior, runtime increases from ~10 seconds on my laptop to ~30 seconds. I haven't looked any deeper yet. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From facundo.dominguez at tweag.io Wed Jan 6 22:32:47 2016 From: facundo.dominguez at tweag.io (=?UTF-8?Q?Facundo_Dom=C3=ADnguez?=) Date: Wed, 6 Jan 2016 20:32:47 -0200 Subject: Slowdown in concurrent program In-Reply-To: <87wprm7935.fsf@smart-cactus.org> References: <87wprm7935.fsf@smart-cactus.org> Message-ID: Opened a ticket https://ghc.haskell.org/trac/ghc/ticket/11365 Facundo On Wed, Jan 6, 2016 at 5:21 PM, Ben Gamari wrote: > Simon Peyton Jones writes: > >> That sounds bad. What happens with 8.0? >> > Same behavior, runtime increases from ~10 seconds on my laptop to ~30 > seconds. > > I haven't looked any deeper yet. > > Cheers, > > - Ben > From simonpj at microsoft.com Thu Jan 7 11:31:56 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 7 Jan 2016 11:31:56 +0000 Subject: expandTypeSynonyms panics after kind equality patch In-Reply-To: References: Message-ID: Richard I'm confused too. The 'go' function in 'expandTypeSynonyms' didn't use to take a substitution, but now it does. I think you intend that go subst ty = expand (substTy subst ty) where 'go' is the new 'go' and 'expand' is 'expandTypeSynonyms'. Correct? So you are avoiding repeated traversal by carrying a substitution in with you. It would be good to write down this invariant. OK so suppose we have new_go subst (T ty1 ty2) where type T a = rhs. (Notice T has arity 1 but is applied to two args.) Then we this should be equivalent to expand (T (subst(ty1)) (subst(ty2)) which is expand (rhs[a -> subst ty1] subst(ty2)) So instead of go subst (TyConApp tc tys) | Just (tenv, rhs, tys') <- expandSynTyCon_maybe tc tys = let subst' = unionTCvSubst subst (mkTopTCvSubst tenv) in go subst' (mkAppTys rhs tys') I'd expect to see go subst (TyConApp tc tys) | Just (tenv, rhs, tys') <- expandSynTyCon_maybe tc (map (go subst) tys) = mkAppTys (go (mkTopTCvSubst tenv) rhs) tys' Notice that I'm applying 'go subst' to 'tys' before giving the args to 'expandSynTyCon_maybe'. Does that look right? What you have looks entirely inexplicable. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of ?mer | Sinan Agacan | Sent: 06 January 2016 16:34 | To: ghc-devs | Subject: expandTypeSynonyms panics after kind equality patch | | My branch panicking during stage 2 build and when I tried to debug I | realized the panicking function is `unionTCvSubst`, when called by | `expandTypeSynonyms`. | In my branch I'm doing some type-based transformations and I'm using | `expandTypeSynonyms` on type of identifiers for that. | | According to git blame logs, the function `unionTCvSubst` was added | with kind equality patch. The patch made this change in | `expandTypeSynonyms`: | | - = go (mkAppTys (substTy (mkTopTvSubst tenv) rhs) tys') | + = let subst' = unionTCvSubst subst (mkTopTCvSubst tenv) in | + go subst' (mkAppTys rhs tys') | | Which is what's causing the panic. The exact place it's panicking | during the | stage2 build is when I call `expandTypeSynonyms` on type `TvSubstEnv` | (i.e. in my transformation I get type of an id and it turns out to be | TvSubstEnv, when I call `expandTypeSynonyms` on this type it panics) | | I figured this much but I don't understand type system details, so, | does anyone here have any ideas what's going wrong here? Richard? | | Note that this panic happens even though I don't do any changes in | types - I'm just looking at the types for some transformations but no | changes on the types are done. | _______________________________________________ | 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%7c2d9763ba60bc4a7 | 845d608d316b74402%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=hRlHPbg | girbpZXO1Ei6jN%2bRV7UUl98pFg%2bMHGVzxtmU%3d From ben at well-typed.com Thu Jan 7 13:42:12 2016 From: ben at well-typed.com (Ben Gamari) Date: Thu, 07 Jan 2016 14:42:12 +0100 Subject: latest symlink In-Reply-To: References: <1451949015.10759.1.camel@joachim-breitner.de> <87poxgrkeb.fsf@smart-cactus.org> <87io3792ii.fsf@smart-cactus.org> Message-ID: <87vb757bgr.fsf@smart-cactus.org> Andrew Farmer writes: > Yeah, I had to ask for this once before and it broke again with a new > GHC version, so I figured it wasn't the right solution. I take it most > people don't use hoogle on the GHC codebase... but I find it useful to > search by type signature. > I typically use hoogle (with hoogle-index [1]) locally, since then I know I have my entire local package database indexed. In principle GHC's build system should be generating hoogle files for the packages which we build. That being said, I'm having some difficulty finding them. I'll need to look into this. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From simonpj at microsoft.com Thu Jan 7 14:19:21 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 7 Jan 2016 14:19:21 +0000 Subject: uniqAway and collisions In-Reply-To: References: <1452041269-sup-5491@sabre> <7a049ab7194244ef9c88b48cdaba7306@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <5b4e15fcad3e4c18a38f67de722839c7@DB4PR30MB030.064d.mgd.msft.net> Bartosz Well, I?m glad I wrote that Note. I think you are right on: it looks to me like an outright bug, correctly identified by the Note, that just so happens not to occur in actual code. I?ve elaborated in this new ticket: https://ghc.haskell.org/trac/ghc/ticket/11371 Would you like to work on this? Simon From: Bartosz Nitka [mailto:niteria at gmail.com] Sent: 06 January 2016 14:57 To: Simon Peyton Jones Cc: Edward Z. Yang ; ghc-devs Devs Subject: Re: uniqAway and collisions Hello, Thank you for the paper, it helped with my understanding of how it's supposed to work. Simon, could my issue be related to your comment here: [1]? -- Note [Generating the in-scope set for a substitution] -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- If we want to substitute [a -> ty1, b -> ty2] I used to -- think it was enough to generate an in-scope set that includes -- fv(ty1,ty2). But that's not enough; we really should also take the -- free vars of the type we are substituting into! Example: -- (forall b. (a,b,x)) [a -> List b] -- Then if we use the in-scope set {b}, there is a danger we will rename -- the forall'd variable to 'x' by mistake, getting this: -- (forall x. (List b, x, x) -- Urk! This means looking at all the calls to mkOpenTvSubst.... Currently the InScope set only contains the free variables of the arguments when linting type application [2][3][4] and doesn't contain the free variables of the body that it's substituting in. The definition of substTyWith is: substTyWith :: [TyVar] -> [Type] -> Type -> Type substTyWith tvs tys = ASSERT( length tvs == length tys ) substTy (zipOpenTCvSubst tvs tys) When I changed it to include the free variables of the body my core lint error went away: substTyWith :: [TyVar] -> [Type] -> Type -> Type substTyWith tvs tys ty = ASSERT( length tvs == length tys ) substTy (extendTCvInScopeList (zipOpenTCvSubst tvs tys) (tyCoVarsOfTypeList ty)) ty It seems unlikely to me that this is the issue, since this code is very old, but I don't have a better explanation for this and a second pair of eyes would help. Thank you, Bartosz [1] https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/types/TyCoRep.hs;cac0795af33d622e4c6ebae6ae1f206969287088$1591-1601 [2] https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/coreSyn/CoreLint.hs;cac0795af33d622e4c6ebae6ae1f206969287088$788 [3] https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/types/TyCoRep.hs;cac0795af33d622e4c6ebae6ae1f206969287088$1756 [4] https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/types/TyCoRep.hs;cac0795af33d622e4c6ebae6ae1f206969287088$1623 2016-01-06 8:42 GMT+00:00 Simon Peyton Jones >: | I doubt there's a bug in uniqAway; it's more likely the in scope set | is not correct. I think Edward is probably right here. -------------- next part -------------- An HTML attachment was scrubbed... URL: From niteria at gmail.com Thu Jan 7 15:29:31 2016 From: niteria at gmail.com (Bartosz Nitka) Date: Thu, 7 Jan 2016 15:29:31 +0000 Subject: uniqAway and collisions In-Reply-To: <5b4e15fcad3e4c18a38f67de722839c7@DB4PR30MB030.064d.mgd.msft.net> References: <1452041269-sup-5491@sabre> <7a049ab7194244ef9c88b48cdaba7306@DB4PR30MB030.064d.mgd.msft.net> <5b4e15fcad3e4c18a38f67de722839c7@DB4PR30MB030.064d.mgd.msft.net> Message-ID: > Would you like to work on this? Sure, I can take it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Thu Jan 7 16:29:55 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Thu, 07 Jan 2016 08:29:55 -0800 Subject: How does TH know to load non-profiled object code when compiling profiled? Message-ID: <1452184181-sup-2337@sabre> I've been looking for the code that implements this logic, but I can't seem to find it. (For what it's worth, compiler plugins *incorrectly* load the profiling interface when compiling profiled, which is wrong and something I'd like to fix.) Simon Marlow, do you happen to know? Edward From marlowsd at gmail.com Thu Jan 7 17:42:27 2016 From: marlowsd at gmail.com (Simon Marlow) Date: Thu, 7 Jan 2016 17:42:27 +0000 Subject: How does TH know to load non-profiled object code when compiling profiled? In-Reply-To: <1452184005-sup-680@sabre> References: <1452184005-sup-680@sabre> Message-ID: <568EA383.3000708@gmail.com> On 07/01/2016 16:28, Edward Z. Yang wrote: > I've been looking for the code that implements this logic, but I can't > seem to find it. (For what it's worth, compiler plugins *incorrectly* > load the profiling interface when compiling profiled, which is wrong > and something I'd like to fix.) Simon Marlow, do you happen to know? Yeah, I've been fiddling with this lately. It's this function here: https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/ghci/Linker.hs;c78fedde7055490ca6f6210ada797190f3c35d87$520-539 Cheers, Simon From ryan.gl.scott at gmail.com Thu Jan 7 17:54:59 2016 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Thu, 7 Jan 2016 12:54:59 -0500 Subject: Confused about specified type variables using -XTypeApplications Message-ID: I read in the Visible Type Applications paper [1] that you can only apply types to "specified" type variables. However, after trying out -XTypeApplications, I'm confused as to what exactly that means: $ /opt/ghc/head/bin/ghci GHCi, version 8.1.20160106: http://www.haskell.org/ghc/ :? for help ?> :set -XTypeInType -XTypeApplications ?> data Prox a = Prox ?> let prox :: Prox a; prox = Prox ?> :t prox @Int prox @Int :: Prox Int ?> :t Prox @Int Prox @Int :: Prox a Huh? For some reason, I'm getting different types for prox @Int and Prox @Int! I think what's happening here is that in Prox @Int, the Int is being applied to a kind variable. That is, it's being applied to the k variable in: Prox :: forall k (t :: k). Prox t But why is this? After all, I don't think I "specified" k anywhere in the definition of Prox, and to make things more confusing, Int gets applied differently in prox @Int (and the definition of prox also doesn't mention k). Is this a bug, or am I misunderstanding something about -XTypeApplications? Ryan S. ----- [1] http://www.cis.upenn.edu/~eir/papers/2016/type-app/visible-type-app.pdf From mail at andres-loeh.de Thu Jan 7 18:39:40 2016 From: mail at andres-loeh.de (Andres Loeh) Date: Thu, 7 Jan 2016 19:39:40 +0100 Subject: Confused about specified type variables using -XTypeApplications In-Reply-To: References: Message-ID: Hi. I just today had a very similar problem with a kind-polymorphic class definition. Simplified example (with ScopedTypeVariables, TypeInType, TypeApplications): GHCi> class C a where c :: () GHCi> :t c c :: forall k (a :: k). C a => () GHCi> :t c @Int c @Int :: C a => () GHCi> :t c @_ @Int c @_ @Int :: C Int => () GHCi> let d :: forall a . C a => (); d = c @_ @a GHCi> :t d d :: forall k (a :: k). C a => () GHCi> :t d @Int d @Int :: C Int => () I find it particularly confusing that GHCi prints the types of c and d in exactly the same way, yet treats explicit type application on them differently. Cheers, Andres On Thu, Jan 7, 2016 at 6:54 PM, Ryan Scott wrote: > I read in the Visible Type Applications paper [1] that you can only > apply types to "specified" type variables. However, after trying out > -XTypeApplications, I'm confused as to what exactly that means: > > $ /opt/ghc/head/bin/ghci > GHCi, version 8.1.20160106: http://www.haskell.org/ghc/ :? for help > ?> :set -XTypeInType -XTypeApplications > ?> data Prox a = Prox > ?> let prox :: Prox a; prox = Prox > ?> :t prox @Int > prox @Int :: Prox Int > ?> :t Prox @Int > Prox @Int :: Prox a > > Huh? For some reason, I'm getting different types for prox @Int and > Prox @Int! I think what's happening here is that in Prox @Int, the Int > is being applied to a kind variable. That is, it's being applied to > the k variable in: > > Prox :: forall k (t :: k). Prox t > > But why is this? After all, I don't think I "specified" k anywhere in > the definition of Prox, and to make things more confusing, Int gets > applied differently in prox @Int (and the definition of prox also > doesn't mention k). Is this a bug, or am I misunderstanding something > about -XTypeApplications? > > Ryan S. > ----- > [1] http://www.cis.upenn.edu/~eir/papers/2016/type-app/visible-type-app.pdf > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From rwbarton at gmail.com Thu Jan 7 18:43:35 2016 From: rwbarton at gmail.com (Reid Barton) Date: Thu, 7 Jan 2016 13:43:35 -0500 Subject: Confused about specified type variables using -XTypeApplications In-Reply-To: References: Message-ID: On Thu, Jan 7, 2016 at 1:39 PM, Andres Loeh wrote: > I find it particularly confusing that GHCi prints the types of c and d > in exactly the same way, yet treats explicit type application on them > differently. > Try with :set -fprint-explicit-foralls. Maybe it should be the default when TypeApplications is enabled? Regards, Reid Barton -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at andres-loeh.de Thu Jan 7 18:59:32 2016 From: mail at andres-loeh.de (Andres Loeh) Date: Thu, 7 Jan 2016 19:59:32 +0100 Subject: Confused about specified type variables using -XTypeApplications In-Reply-To: References: Message-ID: > Try with :set -fprint-explicit-foralls. Maybe it should be the default when > TypeApplications is enabled? That's indeed helpful to see the difference. Still not sure if the (original) datatype and class-versions should have an explicit rather than an implicit kind quantification ... Cheers, Andres From simonpj at microsoft.com Thu Jan 7 22:32:02 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 7 Jan 2016 22:32:02 +0000 Subject: Confused about specified type variables using -XTypeApplications In-Reply-To: References: Message-ID: Make a ticket? This would be worth capturing. I'm sure Richard will want to look at it when he gets back, and a ticket is a useful workflow organiser. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Ryan Scott | Sent: 07 January 2016 17:55 | To: GHC developers | Subject: Confused about specified type variables using -XTypeApplications | | I read in the Visible Type Applications paper [1] that you can only | apply types to "specified" type variables. However, after trying out | -XTypeApplications, I'm confused as to what exactly that means: | | $ /opt/ghc/head/bin/ghci | GHCi, version 8.1.20160106: | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.haskell.o | rg%2fghc%2f&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7caa1fba8c2743424 | c1fb008d3178bb622%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=2B1fES1XwoQb8T | MRj7oOkfdfoGo37oXhjnHFeqgOXAI%3d :? for help | ?> :set -XTypeInType -XTypeApplications | ?> data Prox a = Prox | ?> let prox :: Prox a; prox = Prox | ?> :t prox @Int | prox @Int :: Prox Int | ?> :t Prox @Int | Prox @Int :: Prox a | | Huh? For some reason, I'm getting different types for prox @Int and | Prox @Int! I think what's happening here is that in Prox @Int, the Int | is being applied to a kind variable. That is, it's being applied to | the k variable in: | | Prox :: forall k (t :: k). Prox t | | But why is this? After all, I don't think I "specified" k anywhere in | the definition of Prox, and to make things more confusing, Int gets | applied differently in prox @Int (and the definition of prox also | doesn't mention k). Is this a bug, or am I misunderstanding something | about -XTypeApplications? | | Ryan S. | ----- | [1] | https://na01.safelinks.protection.outlook.com/?url=http:%2f%2fwww.cis.upenn.e | du%2f~eir%2fpapers%2f2016%2ftype-app%2fvisible-type- | app.pdf&data=01%7C01%7Csimonpj%40064d.mgd.microsoft.com%7Caa1fba8c2743424c1fb | 008d3178bb622%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=PKUXsuMdixF76cVq0y | yaCW8NZbIO5hOJpXwABfUkYZw%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%0a&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7caa1fba8c2743424c1fb | 008d3178bb622%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=hV%2f3yHwiH36Qgegu | hepSlx7JaZP0evwpGTTdK%2f3I3Po%3d From ryan.gl.scott at gmail.com Fri Jan 8 00:04:35 2016 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Thu, 7 Jan 2016 19:04:35 -0500 Subject: Confused about specified type variables using -XTypeApplications In-Reply-To: References: Message-ID: I've opened Trac #11376 for this: https://ghc.haskell.org/trac/ghc/ticket/11376 Ryan S. On Thu, Jan 7, 2016 at 5:32 PM, Simon Peyton Jones wrote: > Make a ticket? This would be worth capturing. > > I'm sure Richard will want to look at it when he gets back, and a ticket is a useful workflow organiser. > > Simon > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Ryan Scott > | Sent: 07 January 2016 17:55 > | To: GHC developers > | Subject: Confused about specified type variables using -XTypeApplications > | > | I read in the Visible Type Applications paper [1] that you can only > | apply types to "specified" type variables. However, after trying out > | -XTypeApplications, I'm confused as to what exactly that means: > | > | $ /opt/ghc/head/bin/ghci > | GHCi, version 8.1.20160106: > | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.haskell.o > | rg%2fghc%2f&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7caa1fba8c2743424 > | c1fb008d3178bb622%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=2B1fES1XwoQb8T > | MRj7oOkfdfoGo37oXhjnHFeqgOXAI%3d :? for help > | ?> :set -XTypeInType -XTypeApplications > | ?> data Prox a = Prox > | ?> let prox :: Prox a; prox = Prox > | ?> :t prox @Int > | prox @Int :: Prox Int > | ?> :t Prox @Int > | Prox @Int :: Prox a > | > | Huh? For some reason, I'm getting different types for prox @Int and > | Prox @Int! I think what's happening here is that in Prox @Int, the Int > | is being applied to a kind variable. That is, it's being applied to > | the k variable in: > | > | Prox :: forall k (t :: k). Prox t > | > | But why is this? After all, I don't think I "specified" k anywhere in > | the definition of Prox, and to make things more confusing, Int gets > | applied differently in prox @Int (and the definition of prox also > | doesn't mention k). Is this a bug, or am I misunderstanding something > | about -XTypeApplications? > | > | Ryan S. > | ----- > | [1] > | https://na01.safelinks.protection.outlook.com/?url=http:%2f%2fwww.cis.upenn.e > | du%2f~eir%2fpapers%2f2016%2ftype-app%2fvisible-type- > | app.pdf&data=01%7C01%7Csimonpj%40064d.mgd.microsoft.com%7Caa1fba8c2743424c1fb > | 008d3178bb622%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=PKUXsuMdixF76cVq0y > | yaCW8NZbIO5hOJpXwABfUkYZw%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%0a&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7caa1fba8c2743424c1fb > | 008d3178bb622%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=hV%2f3yHwiH36Qgegu > | hepSlx7JaZP0evwpGTTdK%2f3I3Po%3d From ezyang at mit.edu Fri Jan 8 05:21:39 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Thu, 07 Jan 2016 21:21:39 -0800 Subject: How does TH know to load non-profiled object code when compiling profiled? In-Reply-To: <1452227892-sup-205@sabre> References: <1452184005-sup-680@sabre> <568EA383.3000708@gmail.com> <1452227892-sup-205@sabre> Message-ID: <1452230484-sup-4156@sabre> Thanks! In fact, I have just realized that Template Haskell does something very dodgy when it is loading profiled code: it will use the *profiled* interface files (things that are used in splices are brought into scope with import) to figure out what is going on with the *non-profiled* object files. I'm a bit surprised that we haven't had any terrifying bugs related to this. (It should be relatively easy to trigger horrible brokenness; just compile hi and p_hi with different code so that they are inconsistent.) Edward Excerpts from Simon Marlow's message of 2016-01-07 09:42:27 -0800: > On 07/01/2016 16:28, Edward Z. Yang wrote: > > I've been looking for the code that implements this logic, but I can't > > seem to find it. (For what it's worth, compiler plugins *incorrectly* > > load the profiling interface when compiling profiled, which is wrong > > and something I'd like to fix.) Simon Marlow, do you happen to know? > > Yeah, I've been fiddling with this lately. It's this function here: > https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/ghci/Linker.hs;c78fedde7055490ca6f6210ada797190f3c35d87$520-539 > > Cheers, > Simon From ezyang at mit.edu Fri Jan 8 06:01:44 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Thu, 07 Jan 2016 22:01:44 -0800 Subject: Remote GHCi In-Reply-To: <564AFD2F.6020305@gmail.com> References: <564AFD2F.6020305@gmail.com> Message-ID: <1452232684-sup-4135@sabre> I was reviewing some history here, and I realized that the GHCJS folks had previous implemented this: https://mail.haskell.org/pipermail/ghc-devs/2015-November/010478.html What ever happened to this line of work? Does remote GHCi subsume it? Edward Excerpts from Simon Marlow's message of 2015-11-17 02:10:55 -0800: > Hi folks - I've been thinking about changing the way we run interpreted > code so that it would be run in a separate process. It turns out this > has quite a few benefits, and would let us kill some of the really > awkward hacks we have in GHC to work around problems that arise because > we're running interpreted code and the compiler on the same runtime. > > I summarised the idea here: https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi > > I'd be interested to hear if anyone has any thoughts around this, > particularly if doing this would make your life difficult in some way. > Are people relying on dynCompileExpr for anything? > > Cheers, > Simon From moritz at lichtzwerge.de Fri Jan 8 07:18:57 2016 From: moritz at lichtzwerge.de (Moritz Angermann) Date: Fri, 8 Jan 2016 15:18:57 +0800 Subject: Remote GHCi In-Reply-To: <1452232684-sup-4135@sabre> References: <564AFD2F.6020305@gmail.com> <1452232684-sup-4135@sabre> Message-ID: <14D28196-262F-45DA-80D5-E182ED8D7433@lichtzwerge.de> I?m not sure how much I can actually contribute to this, but I?ll just add a few pointers to nothing gets lost. I?m not very familiar with remote ghci, but I think that there is some overlap between remote ghci and out of process template haskell compilation[1][2]. Most of ghcjs?s TH code is in src/Gen2/TH.hs. To be honest, I haven?t had much time last year to do anything for the out of process th stuff. I?m planing to get back at oopth, once we got shaking-up-ghc[3] to build cross compilers properly. From the looks of it, that could be soon :) I only know about the ghcjs repl[4] through twitter. I?m certain luite can share a lot more here. With respect to remote ghci, I haven?t had much time to look into it. The main focus of out of process th (for me) was getting TH to work for cross compiler, which means shipping code to a remote process through some kind of channel that the remote allows*. Hope this might help in some way. Cheers, Moritz [1]: https://github.com/ghcjs/ghcjs/wiki/Porting-GHCJS-Template-Haskell-to-GHC [2]: https://github.com/angerman/oopth [3]: https://github.com/snowleopard/shaking-up-ghc [4]: https://twitter.com/acid2/status/614076905990582272/photo/1 [*]: E.g. getting this to work for iOS. > On Jan 8, 2016, at 2:01 PM, Edward Z. Yang wrote: > > I was reviewing some history here, and I realized > that the GHCJS folks had previous implemented this: > > https://mail.haskell.org/pipermail/ghc-devs/2015-November/010478.html > > What ever happened to this line of work? Does remote GHCi > subsume it? > > Edward > > Excerpts from Simon Marlow's message of 2015-11-17 02:10:55 -0800: >> Hi folks - I've been thinking about changing the way we run interpreted >> code so that it would be run in a separate process. It turns out this >> has quite a few benefits, and would let us kill some of the really >> awkward hacks we have in GHC to work around problems that arise because >> we're running interpreted code and the compiler on the same runtime. >> >> I summarised the idea here: https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi >> >> I'd be interested to hear if anyone has any thoughts around this, >> particularly if doing this would make your life difficult in some way. >> Are people relying on dynCompileExpr for anything? >> >> Cheers, >> Simon From marlowsd at gmail.com Fri Jan 8 08:42:45 2016 From: marlowsd at gmail.com (Simon Marlow) Date: Fri, 8 Jan 2016 08:42:45 +0000 Subject: Remote GHCi In-Reply-To: <14D28196-262F-45DA-80D5-E182ED8D7433@lichtzwerge.de> References: <564AFD2F.6020305@gmail.com> <1452232684-sup-4135@sabre> <14D28196-262F-45DA-80D5-E182ED8D7433@lichtzwerge.de> Message-ID: <568F7685.2080802@gmail.com> Yes, I used the GHCJS code as a starting point for Remote GHCi - the implementation of TH in Remote GHCi is very similar to GHCJS. Luite and I have chatted about this in person, and I believe he intends to try to merge them at some point. Remote GHCi should make it possible to do TH with a cross-compiler, though you still need to be able to run code on the target platform at compile-time, like GHCJS does with nodejs. Cheers, Simon On 08/01/2016 07:18, Moritz Angermann wrote: > I?m not sure how much I can actually contribute to this, but I?ll just add a > few pointers to nothing gets lost. I?m not very familiar with remote ghci, but I > think that there is some overlap between remote ghci and out of process template > haskell compilation[1][2]. Most of ghcjs?s TH code is in src/Gen2/TH.hs. > > To be honest, I haven?t had much time last year to do anything for the out of > process th stuff. I?m planing to get back at oopth, once we got shaking-up-ghc[3] > to build cross compilers properly. From the looks of it, that could be soon :) > > I only know about the ghcjs repl[4] through twitter. I?m certain luite can share a > lot more here. > > With respect to remote ghci, I haven?t had much time to look into it. The main focus > of out of process th (for me) was getting TH to work for cross compiler, which means > shipping code to a remote process through some kind of channel that the remote allows*. > > Hope this might help in some way. > > Cheers, > Moritz > > [1]: https://github.com/ghcjs/ghcjs/wiki/Porting-GHCJS-Template-Haskell-to-GHC > [2]: https://github.com/angerman/oopth > [3]: https://github.com/snowleopard/shaking-up-ghc > [4]: https://twitter.com/acid2/status/614076905990582272/photo/1 > [*]: E.g. getting this to work for iOS. > >> On Jan 8, 2016, at 2:01 PM, Edward Z. Yang wrote: >> >> I was reviewing some history here, and I realized >> that the GHCJS folks had previous implemented this: >> >> https://mail.haskell.org/pipermail/ghc-devs/2015-November/010478.html >> >> What ever happened to this line of work? Does remote GHCi >> subsume it? >> >> Edward >> >> Excerpts from Simon Marlow's message of 2015-11-17 02:10:55 -0800: >>> Hi folks - I've been thinking about changing the way we run interpreted >>> code so that it would be run in a separate process. It turns out this >>> has quite a few benefits, and would let us kill some of the really >>> awkward hacks we have in GHC to work around problems that arise because >>> we're running interpreted code and the compiler on the same runtime. >>> >>> I summarised the idea here: https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi >>> >>> I'd be interested to hear if anyone has any thoughts around this, >>> particularly if doing this would make your life difficult in some way. >>> Are people relying on dynCompileExpr for anything? >>> >>> Cheers, >>> Simon > From marlowsd at gmail.com Fri Jan 8 08:45:35 2016 From: marlowsd at gmail.com (Simon Marlow) Date: Fri, 8 Jan 2016 08:45:35 +0000 Subject: How does TH know to load non-profiled object code when compiling profiled? In-Reply-To: <1452230484-sup-4156@sabre> References: <1452184005-sup-680@sabre> <568EA383.3000708@gmail.com> <1452227892-sup-205@sabre> <1452230484-sup-4156@sabre> Message-ID: <568F772F.9040605@gmail.com> Correct, it's entirely dodgy. (I seem to remember a Note about this somewhere, but I can't find it right now) In any case, -fexternal-interpreter fixes this properly. Cheers, Simon On 08/01/2016 05:21, Edward Z. Yang wrote: > Thanks! > > In fact, I have just realized that Template Haskell does something > very dodgy when it is loading profiled code: it will use the > *profiled* interface files (things that are used in splices > are brought into scope with import) to figure out what is going on with > the *non-profiled* object files. I'm a bit surprised that we haven't > had any terrifying bugs related to this. (It should be relatively > easy to trigger horrible brokenness; just compile hi and p_hi with > different code so that they are inconsistent.) > > Edward > > Excerpts from Simon Marlow's message of 2016-01-07 09:42:27 -0800: >> On 07/01/2016 16:28, Edward Z. Yang wrote: >>> I've been looking for the code that implements this logic, but I can't >>> seem to find it. (For what it's worth, compiler plugins *incorrectly* >>> load the profiling interface when compiling profiled, which is wrong >>> and something I'd like to fix.) Simon Marlow, do you happen to know? >> >> Yeah, I've been fiddling with this lately. It's this function here: >> https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/ghci/Linker.hs;c78fedde7055490ca6f6210ada797190f3c35d87$520-539 >> >> Cheers, >> Simon From ben at well-typed.com Fri Jan 8 09:59:08 2016 From: ben at well-typed.com (Ben Gamari) Date: Fri, 08 Jan 2016 10:59:08 +0100 Subject: Injective type families Message-ID: <87poxc75oz.fsf@smart-cactus.org> Hi Jan, A few questions came up this morning while speaking Andres Loeh about injective type families: 1. Should this feature be placed behind a LANGUAGE pragma? Afterall, functional dependencies feel very similar and in this case we require a pragma. Now would be the last opportunity to change this. 2. Could you perhaps add some text to better motivate the feature in the users guide? Referring to the paper for the details of semantics of the feature and its implementation is fine, but expecting a new user to refer to the paper to even know *why* they might want to use it seems a bit unfriendly. Thanks! Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From jan.stolarek at p.lodz.pl Fri Jan 8 10:45:20 2016 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Fri, 8 Jan 2016 11:45:20 +0100 Subject: Injective type families In-Reply-To: <87poxc75oz.fsf@smart-cactus.org> References: <87poxc75oz.fsf@smart-cactus.org> Message-ID: <201601081145.20443.jan.stolarek@p.lodz.pl> Ben, > 1. Should this feature be placed behind a LANGUAGE pragma? No, I don't think it should. I consider it a tiny addition to TypeFamilies that is not worth having its separate pragma. Injective TFs are fully backwards compatible, so no existing code will be broken. > 2. Could you perhaps add some text to better motivate the feature in > the users guide? Done. Tell me whether you like the new version. BTW do we still have nightly builds of User's Guide? Janek > Referring to the paper for the details of > semantics of the feature and its implementation is fine, but > expecting a new user to refer to the paper to even know *why* they > might want to use it seems a bit unfriendly. > > Thanks! > > 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 ben at well-typed.com Fri Jan 8 11:10:18 2016 From: ben at well-typed.com (Ben Gamari) Date: Fri, 08 Jan 2016 12:10:18 +0100 Subject: Injective type families In-Reply-To: <201601081145.20443.jan.stolarek@p.lodz.pl> References: <87poxc75oz.fsf@smart-cactus.org> <201601081145.20443.jan.stolarek@p.lodz.pl> Message-ID: <87lh8072ed.fsf@smart-cactus.org> Jan Stolarek writes: > Ben, > >> 1. Should this feature be placed behind a LANGUAGE pragma? > > No, I don't think it should. I consider it a tiny addition to > TypeFamilies that is not worth having its separate pragma. Injective > TFs are fully backwards compatible, so no existing code > will be broken. > That being said, it does claim new syntax and consequently would be rather difficult to back out if we realize that this implementation isn't the right direction. I don't have a strong opinion here, just playing devil's advocate. >> 2. Could you perhaps add some text to better motivate the feature in >> the users guide? > Done. Tell me whether you like the new version. > Definitely better. Thanks for the quick turnaround! > BTW do we still have nightly builds of User's Guide? > I have a script that I periodically run to push the documentation from my test builds here: http://downloads.haskell.org/~ghc/master/users-guide// It's updated pretty close to daily. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From andres.loeh at gmail.com Fri Jan 8 11:17:17 2016 From: andres.loeh at gmail.com (=?UTF-8?Q?Andres_L=C3=B6h?=) Date: Fri, 8 Jan 2016 12:17:17 +0100 Subject: Injective type families In-Reply-To: <87lh8072ed.fsf@smart-cactus.org> References: <87poxc75oz.fsf@smart-cactus.org> <201601081145.20443.jan.stolarek@p.lodz.pl> <87lh8072ed.fsf@smart-cactus.org> Message-ID: Hi. >> No, I don't think it should. I consider it a tiny addition to >> TypeFamilies that is not worth having its separate pragma. Injective >> TFs are fully backwards compatible, so no existing code >> will be broken. >> > That being said, it does claim new syntax and consequently would be > rather difficult to back out if we realize that this implementation > isn't the right direction. I don't have a strong opinion here, just > playing devil's advocate. I think it should be a new language extension. Forward compatibility on its own is not a sufficient argument. Aren't e.g. GADTs forward compatible? Or functional dependencies? Or flexible instances? Yet all of these also have separate language extensions. If I actually want to write backward-compatible type family code using GHC-8.0, I'd prefer to be able to enable TypeFamilies yet not InjectiveTypeFamilies, and have GHC check that I am in the common subset. Also, I think it would be nice to be able to track how many packages will make use of TypeFamilies and InjectiveTypeFamilies separately from each other. Cheers, Andres From jan.stolarek at p.lodz.pl Fri Jan 8 11:25:24 2016 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Fri, 8 Jan 2016 12:25:24 +0100 Subject: Injective type families In-Reply-To: References: <87poxc75oz.fsf@smart-cactus.org> <87lh8072ed.fsf@smart-cactus.org> Message-ID: <201601081225.25002.jan.stolarek@p.lodz.pl> > If I actually want to write backward-compatible type family code using GHC-8.0, I'd prefer > to be able to enable TypeFamilies yet not InjectiveTypeFamilies, and have GHC check that I am in > the common subset. Good point. I wonder if others agree. Janek --- Politechnika ??dzka Lodz University of Technology Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system. From simonpj at microsoft.com Fri Jan 8 11:39:44 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 8 Jan 2016 11:39:44 +0000 Subject: Injective type families In-Reply-To: <87lh8072ed.fsf@smart-cactus.org> References: <87poxc75oz.fsf@smart-cactus.org> <201601081145.20443.jan.stolarek@p.lodz.pl> <87lh8072ed.fsf@smart-cactus.org> Message-ID: | >> 1. Should this feature be placed behind a LANGUAGE pragma? | > | > No, I don't think it should. I consider it a tiny addition to | > TypeFamilies that is not worth having its separate pragma. Injective | > TFs are fully backwards compatible, so no existing code will be | > broken. | > | That being said, it does claim new syntax and consequently would be | rather difficult to back out if we realize that this implementation | isn't the right direction. I don't have a strong opinion here, just | playing devil's advocate. On a branch we are working on a fundep-like extension of injectivity, which is a rather bigger feature. Personally I think it might be better for there to be a LANGUAGE pragma to signal that we are using it (both the current r -> a form, and the new piece). Simon From simonpj at microsoft.com Fri Jan 8 11:41:42 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 8 Jan 2016 11:41:42 +0000 Subject: Injective type families In-Reply-To: <201601081225.25002.jan.stolarek@p.lodz.pl> References: <87poxc75oz.fsf@smart-cactus.org> <87lh8072ed.fsf@smart-cactus.org> <201601081225.25002.jan.stolarek@p.lodz.pl> Message-ID: <9be5e63cca3447eaaeafff6891f8ff21@DB4PR30MB030.064d.mgd.msft.net> | > If I actually want to write backward-compatible type family code | using | > GHC-8.0, I'd prefer to be able to enable TypeFamilies yet not | > InjectiveTypeFamilies, and have GHC check that I am in the common | subset. | Good point. I wonder if others agree. Yes I agree (see my last email). But I think the same flag should deal with the richer form of improvement in the new branch, eg type family F a b = r | r a -> b, r b -> a Is "InjectiveTypeFamilies" a good name for this? Or "TypeFamilyDependencies"? Or what? Simon From jan.stolarek at p.lodz.pl Fri Jan 8 11:43:50 2016 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Fri, 8 Jan 2016 12:43:50 +0100 Subject: Injective type families In-Reply-To: <9be5e63cca3447eaaeafff6891f8ff21@DB4PR30MB030.064d.mgd.msft.net> References: <87poxc75oz.fsf@smart-cactus.org> <201601081225.25002.jan.stolarek@p.lodz.pl> <9be5e63cca3447eaaeafff6891f8ff21@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <201601081243.50703.jan.stolarek@p.lodz.pl> > Is "InjectiveTypeFamilies" a good name for this? Or "TypeFamilyDependencies"? Or what? My vote for "InjectiveTypeFamilies". Janek --- Politechnika ??dzka Lodz University of Technology Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system. From ezyang at mit.edu Fri Jan 8 19:40:21 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Fri, 08 Jan 2016 11:40:21 -0800 Subject: Reify and separating renamer+TH from type-checking Message-ID: <1452281795-sup-9445@sabre> I implemented the refactoring to run the renamer and TH splices all first before doing any type-checking, but actually there's a problem: Template Haskell splices can call 'reify', which needs the type information in order to supply the information about the identifiers in question. I can't think of any good way around this problem. Edward From kane at kane.cx Fri Jan 8 20:15:01 2016 From: kane at kane.cx (David Kraeutmann) Date: Fri, 8 Jan 2016 21:15:01 +0100 Subject: Reify and separating renamer+TH from type-checking In-Reply-To: <1452281795-sup-9445@sabre> References: <1452281795-sup-9445@sabre> Message-ID: <569018C5.9080507@kane.cx> I think I ran into this issue when we had the Safe Haskell annotation bug, which is why I just disabled annotations for SH. I can't think of a way around it unless we change the TH spec. On 1/8/2016 8:40 PM, Edward Z. Yang wrote: > I implemented the refactoring to run the renamer and TH splices all > first before doing any type-checking, but actually there's a problem: > Template Haskell splices can call 'reify', which needs the type > information in order to supply the information about the identifiers > in question. I can't think of any good way around this problem. > > Edward > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4291 bytes Desc: S/MIME Cryptographic Signature URL: From simonpj at microsoft.com Fri Jan 8 23:08:21 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 8 Jan 2016 23:08:21 +0000 Subject: Reify and separating renamer+TH from type-checking In-Reply-To: <1452281795-sup-9445@sabre> References: <1452281795-sup-9445@sabre> Message-ID: Bother. That's true. And it's a vital feature. Otherwise how do we do data T = T1 | T2 $(makeLenses 'T) So we can't separate the two after all. Sorry -- I totally forgot about that. Very annoying. Simon | -----Original Message----- | From: Edward Z. Yang [mailto:ezyang at mit.edu] | Sent: 08 January 2016 19:40 | To: Simon Peyton Jones | Cc: ghc-devs | Subject: Reify and separating renamer+TH from type-checking | | I implemented the refactoring to run the renamer and TH splices all | first before doing any type-checking, but actually there's a problem: | Template Haskell splices can call 'reify', which needs the type | information in order to supply the information about the identifiers | in question. I can't think of any good way around this problem. | | Edward From omeragacan at gmail.com Sat Jan 9 15:23:32 2016 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Sat, 9 Jan 2016 10:23:32 -0500 Subject: NOINLINE effects worker/wrapper - why and how to fix? Message-ID: So I was doing some micro benchmarks and I realized that adding NOINLINE to a function somehow prevents worker/wrapper. Imagine this factorial function which has a very obvious worker/wrapper opportunity: fac :: Int -> Int fac 0 = 1 fac n = n * fac (n - 1) If I add NOINLINE to this, no matter what -O I use, I get this STG: fac = \r srt:SRT:[] [ds_s38j] case ds_s38j of _ { I# ds1_s38l -> case ds1_s38l of ds2_s38m { __DEFAULT -> case -# [ds2_s38m 1#] of sat_s38n { __DEFAULT -> let { sat_s38o = NO_CCS I#! [sat_s38n]; } in case fac sat_s38o of _ { I# y_s38q -> case *# [ds2_s38m y_s38q] of sat_s38r { __DEFAULT -> I# [sat_s38r]; }; }; }; 0# -> lvl_r38f; }; }; Which doesn't have worker/wrapper. When I remove NOINLINE I get this worker/wrappered version as expected: $wfac = \r srt:SRT:[] [ww_s38W] case ww_s38W of ds_s38X { __DEFAULT -> case -# [ds_s38X 1#] of sat_s38Y { __DEFAULT -> case $wfac sat_s38Y of ww1_s38Z { __DEFAULT -> *# [ds_s38X ww1_s38Z]; }; }; 0# -> 1#; }; fac = \r srt:SRT:[] [w_s390] case w_s390 of _ { I# ww1_s392 -> case $wfac ww1_s392 of ww2_s393 { __DEFAULT -> I# [ww2_s393]; }; }; I'd expect to get the same with NOINLINE too. First of all, I think this suggests that if my function is big enough (or has some other property and GHCs heuristics decide not to inline) I don't get worker/wrapper. Second, this type of NOINLINEs are very useful for a couple of reasons. For example, let's say I'm benchmarking a function, I NOINLINE the function because I don't want the function to be transformed to something else during the benchmarking, because of inlining and interactions of the function code with the code at the call site (the code that benchmarks). Another example is when looking at the code to see if expected optimizations are done by GHC. I NOINLINE because otherwise I may have to look at dozens of call sites, rather than just one place (the definition). But now I can't reliably do that. So my questions are: Why worker/wrapper is not applied to NOINLINE functions, and how do I fix this? Thanks. From alain.odea at gmail.com Sun Jan 10 05:44:57 2016 From: alain.odea at gmail.com (Alain O'Dea) Date: Sun, 10 Jan 2016 05:44:57 +0000 Subject: Flag warnings show intermediate hscpp filenames on SmartOS In-Reply-To: References: <5684E713.4050503@centrum.cz> <87a8oq94xe.fsf@smart-cactus.org> <568547F8.1040209@centrum.cz> <56858E53.8010105@centrum.cz> <5686618A.30905@centrum.cz> Message-ID: Progress Update: 1. fixing CPP fixes the majority of the remaining test failures 2. cpphs builds and runs successfully on SmartOS 3. --with-hs-cpp-flags='-specs=overridecpp.spec" can be used in lieu of a wrapper script 3. I am running some experiments with cpphs to see how it works 4. I will run some experiments with hs-cpp-flags and gcc to see how that goes (it would be a smaller impact change on GHC to include and reference a spec file) On Fri, Jan 1, 2016 at 5:32 PM Alain O'Dea wrote: > Okay Karel. I have a solution that works to make T2464 pass. > > Create overridecpp.spec: > > *cpp: > %{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT} > > Create ghc-cpp and make it executable: > > #!/bin/bash > gcc -spec=/path/to/overridecpp.spec $@ > > Configure and make GHC with ghc-cpp and run T2464: > > ./configure --with-hs-cpp=/path/to/ghc-cpp > make -j8 > make TEST=T2464 test > > This should work on Solaris 11 as well. > > So GHC could ship a GCC Specs file like this and that wrapper script as an > interim solution. In the interim I'll include these as patches in PKGSRC > and get a GHC 7.10.3 built with them applied. I'm going to hold off on > PKGSRC stuff until I get fixes for more of the failing tests though. > > Does this seem like a reasonable solution to you? > > On Fri, Jan 1, 2016 at 4:58 PM Alain O'Dea wrote: > >> Actually Karel, if "gcc -dumpspecs" shows you that same -P as I get you >> can override it with spec files as described here: >> https://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html >> >> I think this means that you could specify "gcc >> -specs=/path/to/overridecpp.spec" as --with-hs-cpp when building GHC. I'm >> trying that now. I've already gotten a strawman example based on your post >> to the GCC list working, and I'm going to try to expand on it. >> >> On Fri, Jan 1, 2016 at 3:08 PM Alain O'Dea wrote: >> >>> True, but I'd still like to find a mutual solution since we're both >>> somewhat at the edge of the supported landscape for GHC. >>> >>> Is installing cpphs and configuring GHC to use that an option on Solaris >>> 11? I haven't built cpphs successfully on SmartOS yet. Supplying a custom C >>> preprocessor may be your best bet and using GCC 3.4's works for you. If I >>> can get cpphs working that may be the common ground needed to keep Illumos >>> and Solaris support from diverging. >>> >>> On Fri, Jan 1, 2016 at 7:52 AM Karel Gardas >>> wrote: >>> >>>> >>>> Alain, >>>> >>>> indeed, on SmartOS you are free to modify the supplied GCC so the fix to >>>> remove -P is most natural one. On the other hand I'm not so lucky with >>>> binary Solaris 11.x distribution provided by Oracle so I need to use not >>>> so clean and nice workarounds... >>>> >>>> Karel >>>> >>>> On 01/ 1/16 12:17 AM, Alain O'Dea wrote: >>>> > cpphs isn't a direct option. It won't install on SmartOS with Cabal. >>>> > GCC 4.7 is the earliest GCC supported so I'll have to try something >>>> else >>>> > for SmartOS. >>>> > >>>> > It looks like the GCC Specs are the problem. >>>> > >>>> > On Ubuntu the Spec for cpp is: >>>> > >>>> > *cpp: >>>> > %{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT} >>>> > >>>> > On SmartOS the Spec for cpp is: >>>> > >>>> > *cpp: >>>> > %{,assembler-with-cpp:-P} %(cpp_subtarget) >>>> > >>>> > I think this is how the -P gets injected. I think this is >>>> correctable. >>>> > I had a similar issue with -std=c99 which is the default for C >>>> compiling >>>> > on Ubuntu but not on SmartOS leading to issues with compiling source >>>> > that isn't old school C (like persistent-sqlite). >>>> > >>>> > Anyways I must retire from this and entertain my guests. Happy New >>>> Year >>>> > folks. >>>> > >>>> > >>>> > On Thu, Dec 31, 2015 at 5:19 PM Alain O'Dea >>> > > wrote: >>>> > >>>> > Thanks for the clarification. I understand now. >>>> > On Thu, Dec 31, 2015 at 16:52 Karel Gardas < >>>> karel.gardas at centrum.cz >>>> > > wrote: >>>> > >>>> > On 12/31/15 07:41 PM, Alain O'Dea wrote: >>>> > > Yes. I can do that. >>>> > > >>>> > > On SmartOS it may not be GCC 3.4.3 causing this. I see this >>>> > on GCC 4.7.x >>>> > > through 4.9.x. The paths to gcc on SmartOS also differ. >>>> I'll >>>> > have to >>>> > > verify that as part of checking this. >>>> > >>>> > This is misunderstanding. GCC 3.4.3 provides *correct* CPP >>>> behavior, >>>> > while all 4.x provides broken CPP. That means as a workaround >>>> > when GCC >>>> > 3.4.3 is installed I set it as GHC's CPP automatically on >>>> > Solaris. When >>>> > it is not available, then GHC behaves like you've seen when >>>> > using CPP... >>>> > >>>> > Hopefully this is more clear now, >>>> > >>>> > Karel >>>> > >>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From alain.odea at gmail.com Sun Jan 10 17:34:25 2016 From: alain.odea at gmail.com (Alain O'Dea) Date: Sun, 10 Jan 2016 17:34:25 +0000 Subject: cpphs: can't be used to build GHC 7.10.3. Bug? Message-ID: Hi Malcolm: cpphs is under consideration as a replacement for GCC's C preprocessor in the GHC toolchain: https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp GHC 7.10.3's build fails when cpphs is used as the C preprocessor (--with-hs-cpp=cpphs --with-hs-cpp-flags="--cpp"). It runs into this error when preprocessing libraries/base/GHC/Natural.hs: cpphs: macro MIN_VERSION_integer_gmp expected 3 arguments, but was given 0 I've reproduced this issue on Ubuntu 14.04 x86-64 and SmartOS 15.3.0 x86-64. Interestingly the error seems to arise only when preprocessing Natural.hs while the autogenerated cabal-macros.h is present. Removing that include from the cpphs flags leads to a clean preprocessing run. I have more details of this investigation here: https://gist.github.com/AlainODea/bd5b3e0e6f7c4227f009 Is this a bug? Best, Alain -------------- next part -------------- An HTML attachment was scrubbed... URL: From alain.odea at gmail.com Sun Jan 10 19:23:11 2016 From: alain.odea at gmail.com (Alain O'Dea) Date: Sun, 10 Jan 2016 19:23:11 +0000 Subject: cpphs: can't be used to build GHC 7.10.3. Bug? In-Reply-To: References: Message-ID: I've isolated the issue to the handling of if defined on multi-argument macros. I took a crack at interpreting the cpphs source for this and I think it may be a bug in the conversion of defined expressions here in Language.Preprocessor.CppIfdef here: convert "defined" [arg] = case lookupST arg st of Nothing | all isDigit arg -> return arg Nothing -> return "0" Just (a at AntiDefined{}) -> return "0" Just (a at SymbolReplacement{}) -> return "1" Just (a at MacroExpansion{}) -> return "1" It looks like it will macro expand the contents of a defined expression which isn't what GCC does. I don't know if GCC is wrong or if using parameterized macros within if defined works on single-argument macros. working1.hs: {-# LANGUAGE CPP #-} #define EXAMPLE_MACRO(arg) (\ arg) #if defined(EXAMPLE_MACRO) #endif preprocess it (it works!): $ cpphs --cpp working1.hs -o $tempfile $ ifdef works on multiple-argument macros. working2.hs: {-# LANGUAGE CPP #-} #define EXAMPLE_MACRO(arg1,arg2) (\ arg1 > arg2) #ifdef EXAMPLE_MACRO #endif preprocess it (it works!): $ cpphs --cpp working2.hs -o $tempfile $ if defined fails on multi-argument macros. broken2.hs: {-# LANGUAGE CPP #-} #define EXAMPLE_MACRO(arg1,arg2) (\ arg1 > arg2) #if defined(EXAMPLE_MACRO) #endif preprocess it (it fails!): $ cpphs --cpp broken2.hs -o $tempfile cpphs: macro EXAMPLE_MACRO expected 2 arguments, but was given 0 $ I've posted a StackOverflow question to see if any of them know if this is undefined behavior: http://stackoverflow.com/questions/34709769/is-cpphs-wrong-or-is-the-behavior-of-macros-with-arguments-in-if-defined-express If it is undefined behavior we should stop relying on it in GHC sources. Either way the behavior is inconsistent with GCC which complicates things. Best, Alain On Sun, Jan 10, 2016 at 2:04 PM Alain O'Dea wrote: > Hi Malcolm: > > cpphs is under consideration as a replacement for GCC's C preprocessor in > the GHC toolchain: > https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp > > GHC 7.10.3's build fails when cpphs is used as the C preprocessor > (--with-hs-cpp=cpphs --with-hs-cpp-flags="--cpp"). > > It runs into this error when preprocessing libraries/base/GHC/Natural.hs: > > cpphs: macro MIN_VERSION_integer_gmp expected 3 arguments, but was given 0 > > I've reproduced this issue on Ubuntu 14.04 x86-64 and SmartOS 15.3.0 > x86-64. > > Interestingly the error seems to arise only when preprocessing Natural.hs > while the autogenerated cabal-macros.h is present. Removing that include > from the cpphs flags leads to a clean preprocessing run. > > I have more details of this investigation here: > https://gist.github.com/AlainODea/bd5b3e0e6f7c4227f009 > > Is this a bug? > > Best, > Alain > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alain.odea at gmail.com Sun Jan 10 20:08:11 2016 From: alain.odea at gmail.com (Alain O'Dea) Date: Sun, 10 Jan 2016 20:08:11 +0000 Subject: Flag warnings show intermediate hscpp filenames on SmartOS In-Reply-To: References: <5684E713.4050503@centrum.cz> <87a8oq94xe.fsf@smart-cactus.org> <568547F8.1040209@centrum.cz> <56858E53.8010105@centrum.cz> <5686618A.30905@centrum.cz> Message-ID: cpphs doesn't currently work for compiling GHC. libraries/base/GHC/Natural.hs uses a macro with arguments inside an if defined preprocessor expression and cpphs tries to expand the macro and errors since there are no arguments provided. This is non-compliant if cpphs is trying to be a C99 preprocessor: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf 6.10.1/1 Conditional Inclusion pg 148 clearly indicates that the token after defined or within defined ( ) is an identifier, not a macro to be expanded. On Sun, Jan 10, 2016 at 2:14 AM Alain O'Dea wrote: > Progress Update: > 1. fixing CPP fixes the majority of the remaining test failures > 2. cpphs builds and runs successfully on SmartOS > 3. --with-hs-cpp-flags='-specs=overridecpp.spec" can be used in lieu of a > wrapper script > 3. I am running some experiments with cpphs to see how it works > 4. I will run some experiments with hs-cpp-flags and gcc to see how that > goes (it would be a smaller impact change on GHC to include and reference a > spec file) > > On Fri, Jan 1, 2016 at 5:32 PM Alain O'Dea wrote: > >> Okay Karel. I have a solution that works to make T2464 pass. >> >> Create overridecpp.spec: >> >> *cpp: >> %{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT} >> >> Create ghc-cpp and make it executable: >> >> #!/bin/bash >> gcc -spec=/path/to/overridecpp.spec $@ >> >> Configure and make GHC with ghc-cpp and run T2464: >> >> ./configure --with-hs-cpp=/path/to/ghc-cpp >> make -j8 >> make TEST=T2464 test >> >> This should work on Solaris 11 as well. >> >> So GHC could ship a GCC Specs file like this and that wrapper script as >> an interim solution. In the interim I'll include these as patches in >> PKGSRC and get a GHC 7.10.3 built with them applied. I'm going to hold off >> on PKGSRC stuff until I get fixes for more of the failing tests though. >> >> Does this seem like a reasonable solution to you? >> >> On Fri, Jan 1, 2016 at 4:58 PM Alain O'Dea wrote: >> >>> Actually Karel, if "gcc -dumpspecs" shows you that same -P as I get you >>> can override it with spec files as described here: >>> https://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html >>> >>> I think this means that you could specify "gcc >>> -specs=/path/to/overridecpp.spec" as --with-hs-cpp when building GHC. I'm >>> trying that now. I've already gotten a strawman example based on your post >>> to the GCC list working, and I'm going to try to expand on it. >>> >>> On Fri, Jan 1, 2016 at 3:08 PM Alain O'Dea wrote: >>> >>>> True, but I'd still like to find a mutual solution since we're both >>>> somewhat at the edge of the supported landscape for GHC. >>>> >>>> Is installing cpphs and configuring GHC to use that an option on >>>> Solaris 11? I haven't built cpphs successfully on SmartOS yet. Supplying a >>>> custom C preprocessor may be your best bet and using GCC 3.4's works for >>>> you. If I can get cpphs working that may be the common ground needed to >>>> keep Illumos and Solaris support from diverging. >>>> >>>> On Fri, Jan 1, 2016 at 7:52 AM Karel Gardas >>>> wrote: >>>> >>>>> >>>>> Alain, >>>>> >>>>> indeed, on SmartOS you are free to modify the supplied GCC so the fix >>>>> to >>>>> remove -P is most natural one. On the other hand I'm not so lucky with >>>>> binary Solaris 11.x distribution provided by Oracle so I need to use >>>>> not >>>>> so clean and nice workarounds... >>>>> >>>>> Karel >>>>> >>>>> On 01/ 1/16 12:17 AM, Alain O'Dea wrote: >>>>> > cpphs isn't a direct option. It won't install on SmartOS with Cabal. >>>>> > GCC 4.7 is the earliest GCC supported so I'll have to try something >>>>> else >>>>> > for SmartOS. >>>>> > >>>>> > It looks like the GCC Specs are the problem. >>>>> > >>>>> > On Ubuntu the Spec for cpp is: >>>>> > >>>>> > *cpp: >>>>> > %{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT} >>>>> > >>>>> > On SmartOS the Spec for cpp is: >>>>> > >>>>> > *cpp: >>>>> > %{,assembler-with-cpp:-P} %(cpp_subtarget) >>>>> > >>>>> > I think this is how the -P gets injected. I think this is >>>>> correctable. >>>>> > I had a similar issue with -std=c99 which is the default for C >>>>> compiling >>>>> > on Ubuntu but not on SmartOS leading to issues with compiling source >>>>> > that isn't old school C (like persistent-sqlite). >>>>> > >>>>> > Anyways I must retire from this and entertain my guests. Happy New >>>>> Year >>>>> > folks. >>>>> > >>>>> > >>>>> > On Thu, Dec 31, 2015 at 5:19 PM Alain O'Dea >>>> > > wrote: >>>>> > >>>>> > Thanks for the clarification. I understand now. >>>>> > On Thu, Dec 31, 2015 at 16:52 Karel Gardas < >>>>> karel.gardas at centrum.cz >>>>> > > wrote: >>>>> > >>>>> > On 12/31/15 07:41 PM, Alain O'Dea wrote: >>>>> > > Yes. I can do that. >>>>> > > >>>>> > > On SmartOS it may not be GCC 3.4.3 causing this. I see >>>>> this >>>>> > on GCC 4.7.x >>>>> > > through 4.9.x. The paths to gcc on SmartOS also differ. >>>>> I'll >>>>> > have to >>>>> > > verify that as part of checking this. >>>>> > >>>>> > This is misunderstanding. GCC 3.4.3 provides *correct* CPP >>>>> behavior, >>>>> > while all 4.x provides broken CPP. That means as a workaround >>>>> > when GCC >>>>> > 3.4.3 is installed I set it as GHC's CPP automatically on >>>>> > Solaris. When >>>>> > it is not available, then GHC behaves like you've seen when >>>>> > using CPP... >>>>> > >>>>> > Hopefully this is more clear now, >>>>> > >>>>> > Karel >>>>> > >>>>> >>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From alain.odea at gmail.com Sun Jan 10 20:09:55 2016 From: alain.odea at gmail.com (Alain O'Dea) Date: Sun, 10 Jan 2016 20:09:55 +0000 Subject: cpphs: can't be used to build GHC 7.10.3. Bug? In-Reply-To: References: Message-ID: Got a clear answer about the handling of if defined. Expanding macros within if defined is non-compliant if cpphs is trying to be a C99 preprocessor: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf 6.10.1/1 Conditional Inclusion pg 148 indicates that the token after defined or within defined ( ) is an identifier, not a macro to be expanded. I'm not sure what's involved in fixing this behavior in cpphs, but I'm happy to test fixes. On Sun, Jan 10, 2016 at 3:53 PM Alain O'Dea wrote: > I've isolated the issue to the handling of if defined on multi-argument > macros. > > I took a crack at interpreting the cpphs source for this and I think it > may be a bug in the conversion of defined expressions here in > Language.Preprocessor.CppIfdef here: > > convert "defined" [arg] = > case lookupST arg st of > Nothing | all isDigit arg -> return arg > Nothing -> return "0" > Just (a at AntiDefined{}) -> return "0" > Just (a at SymbolReplacement{}) -> return "1" > Just (a at MacroExpansion{}) -> return "1" > > It looks like it will macro expand the contents of a defined expression > which isn't what GCC does. I don't know if GCC is wrong or if using > parameterized macros within > > if defined works on single-argument macros. > > working1.hs: > > {-# LANGUAGE CPP #-} > > #define EXAMPLE_MACRO(arg) (\ > arg) > > #if defined(EXAMPLE_MACRO) > #endif > > preprocess it (it works!): > > $ cpphs --cpp working1.hs -o $tempfile > $ > > ifdef works on multiple-argument macros. > > working2.hs: > > {-# LANGUAGE CPP #-} > > #define EXAMPLE_MACRO(arg1,arg2) (\ > arg1 > arg2) > > #ifdef EXAMPLE_MACRO > #endif > > preprocess it (it works!): > > $ cpphs --cpp working2.hs -o $tempfile > $ > > if defined fails on multi-argument macros. > > broken2.hs: > > {-# LANGUAGE CPP #-} > > #define EXAMPLE_MACRO(arg1,arg2) (\ > arg1 > arg2) > > #if defined(EXAMPLE_MACRO) > #endif > > preprocess it (it fails!): > > $ cpphs --cpp broken2.hs -o $tempfile > cpphs: macro EXAMPLE_MACRO expected 2 arguments, but was given 0 > $ > > I've posted a StackOverflow question to see if any of them know if this is > undefined behavior: > > http://stackoverflow.com/questions/34709769/is-cpphs-wrong-or-is-the-behavior-of-macros-with-arguments-in-if-defined-express > > If it is undefined behavior we should stop relying on it in GHC sources. > Either way the behavior is inconsistent with GCC which complicates things. > > Best, > Alain > > On Sun, Jan 10, 2016 at 2:04 PM Alain O'Dea wrote: > >> Hi Malcolm: >> >> cpphs is under consideration as a replacement for GCC's C preprocessor in >> the GHC toolchain: >> https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp >> >> GHC 7.10.3's build fails when cpphs is used as the C preprocessor >> (--with-hs-cpp=cpphs --with-hs-cpp-flags="--cpp"). >> >> It runs into this error when preprocessing libraries/base/GHC/Natural.hs: >> >> cpphs: macro MIN_VERSION_integer_gmp expected 3 arguments, but was given 0 >> >> I've reproduced this issue on Ubuntu 14.04 x86-64 and SmartOS 15.3.0 >> x86-64. >> >> Interestingly the error seems to arise only when preprocessing Natural.hs >> while the autogenerated cabal-macros.h is present. Removing that include >> from the cpphs flags leads to a clean preprocessing run. >> >> I have more details of this investigation here: >> https://gist.github.com/AlainODea/bd5b3e0e6f7c4227f009 >> >> Is this a bug? >> >> Best, >> Alain >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From malcolm.wallace at me.com Sun Jan 10 21:10:16 2016 From: malcolm.wallace at me.com (Malcolm Wallace) Date: Sun, 10 Jan 2016 21:10:16 +0000 Subject: cpphs: can't be used to build GHC 7.10.3. Bug? In-Reply-To: References: Message-ID: Thanks for the bug report, and for the detailed analysis. I will try to look at and fix this soon. Regards, Malcolm On 10 Jan 2016, at 20:09, Alain O'Dea wrote: > Got a clear answer about the handling of if defined. > > Expanding macros within if defined is non-compliant if cpphs is trying to be a C99 preprocessor: > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf > 6.10.1/1 Conditional Inclusion pg 148 indicates that the token after defined or within defined ( ) is an identifier, not a macro to be expanded. > > I'm not sure what's involved in fixing this behavior in cpphs, but I'm happy to test fixes. > > On Sun, Jan 10, 2016 at 3:53 PM Alain O'Dea wrote: > I've isolated the issue to the handling of if defined on multi-argument macros. > > I took a crack at interpreting the cpphs source for this and I think it may be a bug in the conversion of defined expressions here in Language.Preprocessor.CppIfdef here: > > convert "defined" [arg] = > case lookupST arg st of > Nothing | all isDigit arg -> return arg > Nothing -> return "0" > Just (a at AntiDefined{}) -> return "0" > Just (a at SymbolReplacement{}) -> return "1" > Just (a at MacroExpansion{}) -> return "1" > > It looks like it will macro expand the contents of a defined expression which isn't what GCC does. I don't know if GCC is wrong or if using parameterized macros within > > if defined works on single-argument macros. > > working1.hs: > > {-# LANGUAGE CPP #-} > > #define EXAMPLE_MACRO(arg) (\ > arg) > > #if defined(EXAMPLE_MACRO) > #endif > > preprocess it (it works!): > > $ cpphs --cpp working1.hs -o $tempfile > $ > > ifdef works on multiple-argument macros. > > working2.hs: > > {-# LANGUAGE CPP #-} > > #define EXAMPLE_MACRO(arg1,arg2) (\ > arg1 > arg2) > > #ifdef EXAMPLE_MACRO > #endif > > preprocess it (it works!): > > $ cpphs --cpp working2.hs -o $tempfile > $ > > if defined fails on multi-argument macros. > > broken2.hs: > > {-# LANGUAGE CPP #-} > > #define EXAMPLE_MACRO(arg1,arg2) (\ > arg1 > arg2) > > #if defined(EXAMPLE_MACRO) > #endif > > preprocess it (it fails!): > > $ cpphs --cpp broken2.hs -o $tempfile > cpphs: macro EXAMPLE_MACRO expected 2 arguments, but was given 0 > $ > > I've posted a StackOverflow question to see if any of them know if this is undefined behavior: > http://stackoverflow.com/questions/34709769/is-cpphs-wrong-or-is-the-behavior-of-macros-with-arguments-in-if-defined-express > > If it is undefined behavior we should stop relying on it in GHC sources. Either way the behavior is inconsistent with GCC which complicates things. > > Best, > Alain > > On Sun, Jan 10, 2016 at 2:04 PM Alain O'Dea wrote: > Hi Malcolm: > > cpphs is under consideration as a replacement for GCC's C preprocessor in the GHC toolchain: > https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp > > GHC 7.10.3's build fails when cpphs is used as the C preprocessor (--with-hs-cpp=cpphs --with-hs-cpp-flags="--cpp"). > > It runs into this error when preprocessing libraries/base/GHC/Natural.hs: > > cpphs: macro MIN_VERSION_integer_gmp expected 3 arguments, but was given 0 > > I've reproduced this issue on Ubuntu 14.04 x86-64 and SmartOS 15.3.0 x86-64. > > Interestingly the error seems to arise only when preprocessing Natural.hs while the autogenerated cabal-macros.h is present. Removing that include from the cpphs flags leads to a clean preprocessing run. > > I have more details of this investigation here: > https://gist.github.com/AlainODea/bd5b3e0e6f7c4227f009 > > Is this a bug? > > Best, > Alain From alain.odea at gmail.com Sun Jan 10 22:40:50 2016 From: alain.odea at gmail.com (Alain O'Dea) Date: Sun, 10 Jan 2016 22:40:50 +0000 Subject: cpphs: can't be used to build GHC 7.10.3. Bug? In-Reply-To: References: Message-ID: No worries. Thank you Malcolm. If there's anything else I can gather to facilitate the fix let me know. On Sun, Jan 10, 2016 at 5:40 PM Malcolm Wallace wrote: > Thanks for the bug report, and for the detailed analysis. I will try to > look at and fix this soon. > > Regards, > Malcolm > > On 10 Jan 2016, at 20:09, Alain O'Dea wrote: > > > Got a clear answer about the handling of if defined. > > > > Expanding macros within if defined is non-compliant if cpphs is trying > to be a C99 preprocessor: > > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf > > 6.10.1/1 Conditional Inclusion pg 148 indicates that the token after > defined or within defined ( ) is an identifier, not a macro to be expanded. > > > > I'm not sure what's involved in fixing this behavior in cpphs, but I'm > happy to test fixes. > > > > On Sun, Jan 10, 2016 at 3:53 PM Alain O'Dea > wrote: > > I've isolated the issue to the handling of if defined on multi-argument > macros. > > > > I took a crack at interpreting the cpphs source for this and I think it > may be a bug in the conversion of defined expressions here in > Language.Preprocessor.CppIfdef here: > > > > convert "defined" [arg] = > > case lookupST arg st of > > Nothing | all isDigit arg -> return arg > > Nothing -> return "0" > > Just (a at AntiDefined{}) -> return "0" > > Just (a at SymbolReplacement{}) -> return "1" > > Just (a at MacroExpansion{}) -> return "1" > > > > It looks like it will macro expand the contents of a defined expression > which isn't what GCC does. I don't know if GCC is wrong or if using > parameterized macros within > > > > if defined works on single-argument macros. > > > > working1.hs: > > > > {-# LANGUAGE CPP #-} > > > > #define EXAMPLE_MACRO(arg) (\ > > arg) > > > > #if defined(EXAMPLE_MACRO) > > #endif > > > > preprocess it (it works!): > > > > $ cpphs --cpp working1.hs -o $tempfile > > $ > > > > ifdef works on multiple-argument macros. > > > > working2.hs: > > > > {-# LANGUAGE CPP #-} > > > > #define EXAMPLE_MACRO(arg1,arg2) (\ > > arg1 > arg2) > > > > #ifdef EXAMPLE_MACRO > > #endif > > > > preprocess it (it works!): > > > > $ cpphs --cpp working2.hs -o $tempfile > > $ > > > > if defined fails on multi-argument macros. > > > > broken2.hs: > > > > {-# LANGUAGE CPP #-} > > > > #define EXAMPLE_MACRO(arg1,arg2) (\ > > arg1 > arg2) > > > > #if defined(EXAMPLE_MACRO) > > #endif > > > > preprocess it (it fails!): > > > > $ cpphs --cpp broken2.hs -o $tempfile > > cpphs: macro EXAMPLE_MACRO expected 2 arguments, but was given 0 > > $ > > > > I've posted a StackOverflow question to see if any of them know if this > is undefined behavior: > > > http://stackoverflow.com/questions/34709769/is-cpphs-wrong-or-is-the-behavior-of-macros-with-arguments-in-if-defined-express > > > > If it is undefined behavior we should stop relying on it in GHC > sources. Either way the behavior is inconsistent with GCC which > complicates things. > > > > Best, > > Alain > > > > On Sun, Jan 10, 2016 at 2:04 PM Alain O'Dea > wrote: > > Hi Malcolm: > > > > cpphs is under consideration as a replacement for GCC's C preprocessor > in the GHC toolchain: > > https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp > > > > GHC 7.10.3's build fails when cpphs is used as the C preprocessor > (--with-hs-cpp=cpphs --with-hs-cpp-flags="--cpp"). > > > > It runs into this error when preprocessing libraries/base/GHC/Natural.hs: > > > > cpphs: macro MIN_VERSION_integer_gmp expected 3 arguments, but was given > 0 > > > > I've reproduced this issue on Ubuntu 14.04 x86-64 and SmartOS 15.3.0 > x86-64. > > > > Interestingly the error seems to arise only when preprocessing > Natural.hs while the autogenerated cabal-macros.h is present. Removing > that include from the cpphs flags leads to a clean preprocessing run. > > > > I have more details of this investigation here: > > https://gist.github.com/AlainODea/bd5b3e0e6f7c4227f009 > > > > Is this a bug? > > > > Best, > > Alain > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alain.odea at gmail.com Mon Jan 11 04:14:14 2016 From: alain.odea at gmail.com (Alain O'Dea) Date: Mon, 11 Jan 2016 04:14:14 +0000 Subject: Flag warnings show intermediate hscpp filenames on SmartOS In-Reply-To: References: <5684E713.4050503@centrum.cz> <87a8oq94xe.fsf@smart-cactus.org> <568547F8.1040209@centrum.cz> <56858E53.8010105@centrum.cz> <5686618A.30905@centrum.cz> Message-ID: Configuring GHC with modified hs-cpp-flags works to fix the tests: ./configure --with-hs-cpp-flags="-specs=/opt/local/etc/ghc/overridecpp.spec -E -undef -traditional -x assembler-with-cpp" overridecpp.spec: *cpp: %{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT} The challenge now is how to integrate this extra file and new default hs-cpp-flags cleanly into the GHC build and install. I know I can modify aclocal.m4 to add the -specs argument to hs-cpp-flags easily: https://github.com/ghc/ghc/blob/f7b45c31f07daa4c3dca39f6ccc1a52c86900b7c/aclocal.m4#L2160 Where should I put overridecpp.spec in the GHC source and how do I get it to be included during make install? On Sun, Jan 10, 2016 at 4:38 PM Alain O'Dea wrote: > cpphs doesn't currently work for compiling GHC. > libraries/base/GHC/Natural.hs uses a macro with arguments inside an if > defined preprocessor expression and cpphs tries to expand the macro and > errors since there are no arguments provided. > > This is non-compliant if cpphs is trying to be a C99 preprocessor: > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf > 6.10.1/1 Conditional Inclusion pg 148 clearly indicates that the token > after defined or within defined ( ) is an identifier, not a macro to be > expanded. > > > > On Sun, Jan 10, 2016 at 2:14 AM Alain O'Dea wrote: > >> Progress Update: >> 1. fixing CPP fixes the majority of the remaining test failures >> 2. cpphs builds and runs successfully on SmartOS >> 3. --with-hs-cpp-flags='-specs=overridecpp.spec" can be used in lieu of a >> wrapper script >> 3. I am running some experiments with cpphs to see how it works >> 4. I will run some experiments with hs-cpp-flags and gcc to see how that >> goes (it would be a smaller impact change on GHC to include and reference a >> spec file) >> >> On Fri, Jan 1, 2016 at 5:32 PM Alain O'Dea wrote: >> >>> Okay Karel. I have a solution that works to make T2464 pass. >>> >>> Create overridecpp.spec: >>> >>> *cpp: >>> %{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT} >>> >>> Create ghc-cpp and make it executable: >>> >>> #!/bin/bash >>> gcc -spec=/path/to/overridecpp.spec $@ >>> >>> Configure and make GHC with ghc-cpp and run T2464: >>> >>> ./configure --with-hs-cpp=/path/to/ghc-cpp >>> make -j8 >>> make TEST=T2464 test >>> >>> This should work on Solaris 11 as well. >>> >>> So GHC could ship a GCC Specs file like this and that wrapper script as >>> an interim solution. In the interim I'll include these as patches in >>> PKGSRC and get a GHC 7.10.3 built with them applied. I'm going to hold off >>> on PKGSRC stuff until I get fixes for more of the failing tests though. >>> >>> Does this seem like a reasonable solution to you? >>> >>> On Fri, Jan 1, 2016 at 4:58 PM Alain O'Dea wrote: >>> >>>> Actually Karel, if "gcc -dumpspecs" shows you that same -P as I get you >>>> can override it with spec files as described here: >>>> https://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html >>>> >>>> I think this means that you could specify "gcc >>>> -specs=/path/to/overridecpp.spec" as --with-hs-cpp when building GHC. I'm >>>> trying that now. I've already gotten a strawman example based on your post >>>> to the GCC list working, and I'm going to try to expand on it. >>>> >>>> On Fri, Jan 1, 2016 at 3:08 PM Alain O'Dea >>>> wrote: >>>> >>>>> True, but I'd still like to find a mutual solution since we're both >>>>> somewhat at the edge of the supported landscape for GHC. >>>>> >>>>> Is installing cpphs and configuring GHC to use that an option on >>>>> Solaris 11? I haven't built cpphs successfully on SmartOS yet. Supplying a >>>>> custom C preprocessor may be your best bet and using GCC 3.4's works for >>>>> you. If I can get cpphs working that may be the common ground needed to >>>>> keep Illumos and Solaris support from diverging. >>>>> >>>>> On Fri, Jan 1, 2016 at 7:52 AM Karel Gardas >>>>> wrote: >>>>> >>>>>> >>>>>> Alain, >>>>>> >>>>>> indeed, on SmartOS you are free to modify the supplied GCC so the fix >>>>>> to >>>>>> remove -P is most natural one. On the other hand I'm not so lucky with >>>>>> binary Solaris 11.x distribution provided by Oracle so I need to use >>>>>> not >>>>>> so clean and nice workarounds... >>>>>> >>>>>> Karel >>>>>> >>>>>> On 01/ 1/16 12:17 AM, Alain O'Dea wrote: >>>>>> > cpphs isn't a direct option. It won't install on SmartOS with >>>>>> Cabal. >>>>>> > GCC 4.7 is the earliest GCC supported so I'll have to try something >>>>>> else >>>>>> > for SmartOS. >>>>>> > >>>>>> > It looks like the GCC Specs are the problem. >>>>>> > >>>>>> > On Ubuntu the Spec for cpp is: >>>>>> > >>>>>> > *cpp: >>>>>> > %{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT} >>>>>> > >>>>>> > On SmartOS the Spec for cpp is: >>>>>> > >>>>>> > *cpp: >>>>>> > %{,assembler-with-cpp:-P} %(cpp_subtarget) >>>>>> > >>>>>> > I think this is how the -P gets injected. I think this is >>>>>> correctable. >>>>>> > I had a similar issue with -std=c99 which is the default for C >>>>>> compiling >>>>>> > on Ubuntu but not on SmartOS leading to issues with compiling source >>>>>> > that isn't old school C (like persistent-sqlite). >>>>>> > >>>>>> > Anyways I must retire from this and entertain my guests. Happy New >>>>>> Year >>>>>> > folks. >>>>>> > >>>>>> > >>>>>> > On Thu, Dec 31, 2015 at 5:19 PM Alain O'Dea >>>>> > > wrote: >>>>>> > >>>>>> > Thanks for the clarification. I understand now. >>>>>> > On Thu, Dec 31, 2015 at 16:52 Karel Gardas < >>>>>> karel.gardas at centrum.cz >>>>>> > > wrote: >>>>>> > >>>>>> > On 12/31/15 07:41 PM, Alain O'Dea wrote: >>>>>> > > Yes. I can do that. >>>>>> > > >>>>>> > > On SmartOS it may not be GCC 3.4.3 causing this. I see >>>>>> this >>>>>> > on GCC 4.7.x >>>>>> > > through 4.9.x. The paths to gcc on SmartOS also differ. >>>>>> I'll >>>>>> > have to >>>>>> > > verify that as part of checking this. >>>>>> > >>>>>> > This is misunderstanding. GCC 3.4.3 provides *correct* CPP >>>>>> behavior, >>>>>> > while all 4.x provides broken CPP. That means as a >>>>>> workaround >>>>>> > when GCC >>>>>> > 3.4.3 is installed I set it as GHC's CPP automatically on >>>>>> > Solaris. When >>>>>> > it is not available, then GHC behaves like you've seen when >>>>>> > using CPP... >>>>>> > >>>>>> > Hopefully this is more clear now, >>>>>> > >>>>>> > Karel >>>>>> > >>>>>> >>>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Mon Jan 11 16:35:05 2016 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 11 Jan 2016 11:35:05 -0500 Subject: Injective type families In-Reply-To: <201601081243.50703.jan.stolarek@p.lodz.pl> References: <87poxc75oz.fsf@smart-cactus.org> <201601081225.25002.jan.stolarek@p.lodz.pl> <9be5e63cca3447eaaeafff6891f8ff21@DB4PR30MB030.064d.mgd.msft.net> <201601081243.50703.jan.stolarek@p.lodz.pl> Message-ID: <32387E80-F449-49D8-9215-0E8E49189FBD@cis.upenn.edu> I'm joining this conversation late, but I favor TypeFamilyDependencies over InjectiveTypeFamilies. We use the annotations for things other than injectivity! For example, > type family Plus a b = r | r a -> b, r b -> a is not injective under any common understanding of the word. And the argument-to-argument dependencies Simon has been musing about are even further from the meaning of "injective". Richard On Jan 8, 2016, at 6:43 AM, Jan Stolarek wrote: >> Is "InjectiveTypeFamilies" a good name for this? Or "TypeFamilyDependencies"? Or what? > My vote for "InjectiveTypeFamilies". > > Janek > > --- > Politechnika ??dzka > Lodz University of Technology > > Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. > Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k? > prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. > > This email contains information intended solely for the use of the individual to whom it is addressed. > If you are not the intended recipient or if you have received this message in error, > please notify the sender and delete it from your system. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From simonpj at microsoft.com Mon Jan 11 16:50:44 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 11 Jan 2016 16:50:44 +0000 Subject: Injective type families In-Reply-To: <32387E80-F449-49D8-9215-0E8E49189FBD@cis.upenn.edu> References: <87poxc75oz.fsf@smart-cactus.org> <201601081225.25002.jan.stolarek@p.lodz.pl> <9be5e63cca3447eaaeafff6891f8ff21@DB4PR30MB030.064d.mgd.msft.net> <201601081243.50703.jan.stolarek@p.lodz.pl> <32387E80-F449-49D8-9215-0E8E49189FBD@cis.upenn.edu> Message-ID: <8001f6c9d69f4655b5ccc1ef782ca604@DB4PR30MB030.064d.mgd.msft.net> I agree! | -----Original Message----- | From: Richard Eisenberg [mailto:eir at cis.upenn.edu] | Sent: 11 January 2016 16:35 | To: Jan Stolarek | Cc: Simon Peyton Jones ; GHC developers | Subject: Re: Injective type families | | I'm joining this conversation late, but I favor TypeFamilyDependencies | over InjectiveTypeFamilies. We use the annotations for things other | than injectivity! For example, | | > type family Plus a b = r | r a -> b, r b -> a | | is not injective under any common understanding of the word. And the | argument-to-argument dependencies Simon has been musing about are even | further from the meaning of "injective". | | Richard | | On Jan 8, 2016, at 6:43 AM, Jan Stolarek | wrote: | | >> Is "InjectiveTypeFamilies" a good name for this? Or | "TypeFamilyDependencies"? Or what? | > My vote for "InjectiveTypeFamilies". | > | > Janek | > | > --- | > Politechnika ??dzka | > Lodz University of Technology | > | > Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla | adresata. | > Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? | > przez pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej | usuni?cie. | > | > This email contains information intended solely for the use of the | individual to whom it is addressed. | > If you are not the intended recipient or if you have received this | > message in error, please notify the sender and delete it from your | system. | > _______________________________________________ | > 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%7csi | > | monpj%40064d.mgd.microsoft.com%7c89e853d7594848b5a2b008d31aa53339%7c72 | > | f988bf86f141af91ab2d7cd011db47%7c1&sdata=CGUuIZ3rnRG3jH7pXHUCnLuB5tG8I | > Crf%2fhYwvlrWUcA%3d | > From ben at well-typed.com Mon Jan 11 22:52:43 2016 From: ben at well-typed.com (Ben Gamari) Date: Mon, 11 Jan 2016 23:52:43 +0100 Subject: Injective type families In-Reply-To: <8001f6c9d69f4655b5ccc1ef782ca604@DB4PR30MB030.064d.mgd.msft.net> References: <87poxc75oz.fsf@smart-cactus.org> <201601081225.25002.jan.stolarek@p.lodz.pl> <9be5e63cca3447eaaeafff6891f8ff21@DB4PR30MB030.064d.mgd.msft.net> <201601081243.50703.jan.stolarek@p.lodz.pl> <32387E80-F449-49D8-9215-0E8E49189FBD@cis.upenn.edu> <8001f6c9d69f4655b5ccc1ef782ca604@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <878u3v7mpw.fsf@smart-cactus.org> Simon Peyton Jones writes: > I agree! > Currently InjectiveTypeFamilies is in the tree but it's not too late to change it. Of course, this means that we need to decide what to do about the -rc1 release. I finished the builds earlier today but have been sitting on them to check over things when I feel less ill. Given the number of rather serious issues still outstanding I was a bit reluctant to even go ahead with the builds, but thought in the name of release early, release often it would be best just to get something out there, however unperfect. Perhaps I'll just wait until the meeting tomorrow before doing any further on the rc front. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From eir at cis.upenn.edu Tue Jan 12 00:59:20 2016 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 11 Jan 2016 19:59:20 -0500 Subject: Phab not running a full validate? Message-ID: <6030E4AB-5B1B-4941-8ED4-C8E511E63E23@cis.upenn.edu> Hi devs, Take a look at https://phabricator.haskell.org/harbormaster/build/9990/ See how only 1 test was run. Is this expected? Does Phab now bail when it runs into an error? Or have I done something wrong? Thanks, Richard From matthewtpickering at gmail.com Tue Jan 12 01:06:28 2016 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Tue, 12 Jan 2016 01:06:28 +0000 Subject: Phab not running a full validate? In-Reply-To: <6030E4AB-5B1B-4941-8ED4-C8E511E63E23@cis.upenn.edu> References: <6030E4AB-5B1B-4941-8ED4-C8E511E63E23@cis.upenn.edu> Message-ID: I think it does run them all. If you look at the full stdout log it runs the failing tests again after finishing the run. Matt On 12 Jan 2016 00:59, "Richard Eisenberg" wrote: > Hi devs, > > Take a look at https://phabricator.haskell.org/harbormaster/build/9990/ > > See how only 1 test was run. Is this expected? Does Phab now bail when it > runs into an error? Or have I done something wrong? > > Thanks, > Richard > _______________________________________________ > 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: From jan.stolarek at p.lodz.pl Tue Jan 12 08:44:01 2016 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Tue, 12 Jan 2016 09:44:01 +0100 Subject: Injective type families In-Reply-To: <32387E80-F449-49D8-9215-0E8E49189FBD@cis.upenn.edu> References: <87poxc75oz.fsf@smart-cactus.org> <201601081243.50703.jan.stolarek@p.lodz.pl> <32387E80-F449-49D8-9215-0E8E49189FBD@cis.upenn.edu> Message-ID: <201601120944.01445.jan.stolarek@p.lodz.pl> > I'm joining this conversation late, but I favor TypeFamilyDependencies over > InjectiveTypeFamilies. We use the annotations for things other than > injectivity! For example, > > > type family Plus a b = r | r a -> b, r b -> a > > is not injective under any common understanding of the word. But that is not implemented yet and thus will not make it into GHC 8.0. Following earlier argumentation, once we have generalized injectivity we should put it into a separate extension. So I'd say we stick with InjectiveTypeFamilies for currently implemented features and put the new ones in TypeFamilyDependencies. That said, I don't like the idea that every addition to a language extension means creating a separate language extension. Janek --- Politechnika ??dzka Lodz University of Technology Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system. From thomasmiedema at gmail.com Tue Jan 12 08:57:44 2016 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Tue, 12 Jan 2016 09:57:44 +0100 Subject: Phab not running a full validate? In-Reply-To: References: <6030E4AB-5B1B-4941-8ED4-C8E511E63E23@cis.upenn.edu> Message-ID: The top window (remote - stderr) is the result of a normal `./validate`, with some output suppressed. The bottom window (remote - stdout) is the result of rerunning any failing tests. Note that Phabricator does indeed *not* run a full validate on patches or commits (i.e. it does not run `./validate --slow`), because it would take too long (Harbormaster is already having problems with the current load it gets), and would only sporadically catch a bug that `./validate (--normal)` would not have caught. When you add a new test yourself, and you want to be sure it also passes `validate --slow`, please run that test locally using `make TEST= slow` in the testsuite directory. The different speed settings of the testsuite are explained on https://ghc.haskell.org/trac/ghc/wiki/Building/RunningTests/Running#Speedsettings and in `Note [validate and testsuite speed]` in the toplevel Makefile. On Tue, Jan 12, 2016 at 2:06 AM, Matthew Pickering < matthewtpickering at gmail.com> wrote: > I think it does run them all. If you look at the full stdout log it runs > the failing tests again after finishing the run. > > Matt > On 12 Jan 2016 00:59, "Richard Eisenberg" wrote: > >> Hi devs, >> >> Take a look at https://phabricator.haskell.org/harbormaster/build/9990/ >> >> See how only 1 test was run. Is this expected? Does Phab now bail when it >> runs into an error? Or have I done something wrong? >> >> Thanks, >> Richard >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Jan 12 09:44:38 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 12 Jan 2016 09:44:38 +0000 Subject: Injective type families In-Reply-To: <201601120944.01445.jan.stolarek@p.lodz.pl> References: <87poxc75oz.fsf@smart-cactus.org> <201601081243.50703.jan.stolarek@p.lodz.pl> <32387E80-F449-49D8-9215-0E8E49189FBD@cis.upenn.edu> <201601120944.01445.jan.stolarek@p.lodz.pl> Message-ID: <31f1f5b407434a9fbdf9d6502f96d192@DB4PR30MB030.064d.mgd.msft.net> I'd prefer to use TypeFamilyDependencies right now, and keep using that same flag (not a new one) when we extend what "dependencies" means. Simon | -----Original Message----- | From: Jan Stolarek [mailto:jan.stolarek at p.lodz.pl] | Sent: 12 January 2016 08:44 | To: Richard Eisenberg | Cc: Simon Peyton Jones ; GHC developers | Subject: Re: Injective type families | | > I'm joining this conversation late, but I favor TypeFamilyDependencies over | > InjectiveTypeFamilies. We use the annotations for things other than | > injectivity! For example, | > | > > type family Plus a b = r | r a -> b, r b -> a | > | > is not injective under any common understanding of the word. | But that is not implemented yet and thus will not make it into GHC 8.0. | Following earlier | argumentation, once we have generalized injectivity we should put it into a | separate extension. | So I'd say we stick with InjectiveTypeFamilies for currently implemented | features and put the new | ones in TypeFamilyDependencies. | | That said, I don't like the idea that every addition to a language extension | means creating a | separate language extension. | | Janek | | --- | Politechnika ??dzka | Lodz University of Technology | | Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. | Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez | pomy?k? | prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. | | This email contains information intended solely for the use of the individual | to whom it is addressed. | If you are not the intended recipient or if you have received this message in | error, | please notify the sender and delete it from your system. From simonpj at microsoft.com Tue Jan 12 15:40:49 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 12 Jan 2016 15:40:49 +0000 Subject: Pattern match checking Message-ID: <73d0550f11964c19ab45bcdb822aeead@DB4PR30MB030.064d.mgd.msft.net> George I believe that your #1 priority on the GHC pattern matching front is to make it so that the pattern checker will give up if it examines more than 1,000 (or whatever, there should be a settable limit) cases in the pruner. This should cure all the performance problems at once, at the cost of giving up on the exhaustiveness check for that function. This is a small, local, single change; should not take long. When do you think you?ll be done with that? I am (very) ambitious to do a better job, and we discussed various approaches. But the First Thing is to stop GHC consuming infinite time. Thanks! Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Tue Jan 12 16:18:46 2016 From: marlowsd at gmail.com (Simon Marlow) Date: Tue, 12 Jan 2016 16:18:46 +0000 Subject: Warnings, -Wall, and versioning policy Message-ID: <56952766.2000505@gmail.com> Hi folks, We haven't described what guarantees GHC provides with respect to -Wall behaviour across versions, and as a result there are some differing expectations around this. It came up in this weeks' GHC meeting, so we thought it would be a good idea to state the policy explicitly. Here it is: We guarantee that code that compiles with no warnings with -Wall ("Wall-clean") and a particular GHC version, on a particular platform, will be Wall-clean with future minor releases of the same major GHC version on the same platform. (we plan to put this text in the User's Guide for future releases) There are no other guarantees. In particular: - In a new major release, GHC may introduce new warnings into -Wall, and/or change the meaning of existing warnings such that they trigger (or not) under different conditions. - GHC may generate different warnings on different platforms. (examples of this are -fwarn-overflowed-literals and -fwarn-unsupported-calling-conventions) Some rationale: - We consider any change to the language that GHC accepts to be a potentially code-breaking change, and subject to careful scrutiny. To extend this to warnings would be a *lot* of work, and would make it really difficult to introduce new warnings and improve the existing ones. - Warnings can be based on analyses that can change in accuracy over time. The -fwarn-unused-imports warning has changed a lot in what it rejects, for example. - We often introduce new warnings that naturally belong in -Wall. If -Wall was required to be a fixed point, we would have to start introducing new flags, and versioning, etc. and even keep the old implementation of warnings when they change. It would get really messy. There are some consequences to this. -Wall -Werror is useful for keeping your code warning-clean when developing, but shipping code with these options turned on in the build system is asking for trouble when building your code with different GHC versions and platforms. Keep those options for development only. Hackage already rejects packages that include -Wall for this reason. One reason we're raising this now is that it causes problems for the 3-release policy (https://prime.haskell.org/wiki/Libraries/3-Release-Policy) which requires that it be possible to write code that is Wall-clean with 3 major releases of GHC. GHC itself doesn't guarantee this, so it might be hard for the core libraries committee to provide this guarantee. I suggest this requirement be dropped from the policy. Cheers, Simon From simonpj at microsoft.com Tue Jan 12 16:20:30 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 12 Jan 2016 16:20:30 +0000 Subject: FW: Shaking up GHC In-Reply-To: References: <3b354546145a4a448ea6a4849441a6d6@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <5a0882565cb245d48bcd158b41ab0567@DB4PR30MB030.064d.mgd.msft.net> Dear ghc devs Can someone figure out how to help Andrey be able to post to this mailing list (ghc-devs)? I thought anyone subscribed can post, but perhaps not. Thanks! Simon From: Andrey Mokhov [mailto:andrey.mokhov at newcastle.ac.uk] Sent: 12 January 2016 14:49 To: Simon Peyton Jones Cc: Neil Mitchell ; Andrey Mokhov Subject: RE: Shaking up GHC Hi Simon, Happy New Year! Indeed, as soon as my teaching was over I jumped on the project with double energy, and then several people joined as collaborators, so we are in a very good shape right now. I'm happy with the progress. We can already build GHC on Windows/Linux/OSX from scratch without relying on the old build system, but with some limitations (only vanilla way, no validation, command line flags not supported). Feel free to try! We are getting close to the first milestone `first-shake`: https://github.com/snowleopard/shaking-up-ghc/milestones. It should be ready in a week, and I think it would be a perfect timing to announce it on GHC devs mailing list. The only problem: I still can't post to the GHC devs mailing list. I tried several times, sent several requests to ghc-devs-owner at haskell.org to whitelist my email, but no luck so far. Would you be the owner by any chance? Please let me in! :-) As soon as `first-shake` is released I'll start writing the ICFP paper. Thanks for pushing and willing to be a co-author! Cheers, Andrey From: Simon Peyton Jones [mailto:simonpj at microsoft.com] Sent: 12 January 2016 11:02 To: Andrey Mokhov Cc: Neil Mitchell; Simon Peyton Jones Subject: Shaking up GHC Andrey I?ve seen a few issue messages from #147 https://github.com/snowleopard/shaking-up-ghc (it says ?you are receiving notifications because you were mentioned?). And I saw Neil yesterday. So it looks as though you are tremendously active and, better still, have several other collaborators. That?s fantastic! Would you like to send an update message to the GHC devs mailing list, to keep us all up to date? ? what you are doing ? who is involved ? what help (if any) you want; e.g. alpha-testers ? what you plan Finally, what about a paper for ICFP or, if rejected, the Haskell Symposium. I really want to get this written up, and ICFP is a useful forcing function. But you?d need to start writing now! I?d be a willing co-author. Happy new year! Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at seidel.io Tue Jan 12 16:33:55 2016 From: eric at seidel.io (Eric Seidel) Date: Tue, 12 Jan 2016 08:33:55 -0800 Subject: FW: Shaking up GHC In-Reply-To: <5a0882565cb245d48bcd158b41ab0567@DB4PR30MB030.064d.mgd.msft.net> References: <3b354546145a4a448ea6a4849441a6d6@DB4PR30MB030.064d.mgd.msft.net> <5a0882565cb245d48bcd158b41ab0567@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <1452616435.4005509.489998426.679A85DA@webmail.messagingengine.com> I'm pretty sure you can only post to the list with the address you used to subscribe. According to https://mail.haskell.org/cgi-bin/mailman/roster/ghc-devs it looks like Andrey is subscribed with andrey.mokhov at ncl.ac.uk but the email you forwarded is from andrey.mokhov at newcastle.ac.uk So that may be the issue. Eric On Tue, Jan 12, 2016, at 08:20, Simon Peyton Jones wrote: > Dear ghc devs > Can someone figure out how to help Andrey be able to post to this mailing > list (ghc-devs)? I thought anyone subscribed can post, but perhaps not. > Thanks! > Simon > > From: Andrey Mokhov [mailto:andrey.mokhov at newcastle.ac.uk] > Sent: 12 January 2016 14:49 > To: Simon Peyton Jones > Cc: Neil Mitchell ; Andrey Mokhov > > Subject: RE: Shaking up GHC > > Hi Simon, > Happy New Year! > Indeed, as soon as my teaching was over I jumped on the project with > double energy, and then several people joined as collaborators, so we are > in a very good shape right now. I'm happy with the progress. We can > already build GHC on Windows/Linux/OSX from scratch without relying on > the old build system, but with some limitations (only vanilla way, no > validation, command line flags not supported). Feel free to try! > We are getting close to the first milestone `first-shake`: > https://github.com/snowleopard/shaking-up-ghc/milestones. It should be > ready in a week, and I think it would be a perfect timing to announce it > on GHC devs mailing list. > The only problem: I still can't post to the GHC devs mailing list. I > tried several times, sent several requests to > ghc-devs-owner at haskell.org to > whitelist my email, but no luck so far. Would you be the owner by any > chance? Please let me in! :-) > > As soon as `first-shake` is released I'll start writing the ICFP paper. > Thanks for pushing and willing to be a co-author! > > Cheers, > Andrey > > From: Simon Peyton Jones [mailto:simonpj at microsoft.com] > Sent: 12 January 2016 11:02 > To: Andrey Mokhov > Cc: Neil Mitchell; Simon Peyton Jones > Subject: Shaking up GHC > > Andrey > I?ve seen a few issue messages from #147 > https://github.com/snowleopard/shaking-up-ghc (it says ?you are receiving > notifications because you were mentioned?). And I saw Neil yesterday. > So it looks as though you are tremendously active and, better still, have > several other collaborators. That?s fantastic! > Would you like to send an update message to the GHC devs mailing list, to > keep us all up to date? > > ? what you are doing > > ? who is involved > > ? what help (if any) you want; e.g. alpha-testers > > ? what you plan > Finally, what about a paper for ICFP or, if rejected, the Haskell > Symposium. I really want to get this written up, and ICFP is a useful > forcing function. But you?d need to start writing now! I?d be a willing > co-author. > Happy new year! > Simon > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From ben at well-typed.com Tue Jan 12 16:50:33 2016 From: ben at well-typed.com (Ben Gamari) Date: Tue, 12 Jan 2016 17:50:33 +0100 Subject: Cabal status for GHC 8.0.1 Message-ID: <8760yy7ndy.fsf@smart-cactus.org> Hello everyone, As you likely know the GHC 8.0.1 release is quickly approaching. The release candidate should be out any moment now and we anticipate a final release in mid-February. Consequently, we should start thinking about how we will manage the Cabal release. Duncan has said that his nix-local-builds branch should be in good enough shape to be included as a technology preview with the GHC 8.0 release. Within what timeframe in particular do you think we'll be able to have a release tagged and (and ideally released)? Is late January possible? Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From mikhail.glushenkov at gmail.com Tue Jan 12 22:59:40 2016 From: mikhail.glushenkov at gmail.com (Mikhail Glushenkov) Date: Tue, 12 Jan 2016 23:59:40 +0100 Subject: Cabal status for GHC 8.0.1 In-Reply-To: <8760yy7ndy.fsf@smart-cactus.org> References: <8760yy7ndy.fsf@smart-cactus.org> Message-ID: Hi, On 12 January 2016 at 17:50, Ben Gamari wrote: > Within what timeframe in particular do you think we'll > be able to have a release tagged and (and ideally released)? Is late > January possible? Yes, I think it should be possible. In fact, all Cabal library changes required by nix-local-build and hackage-security are already in. I plan to merge some remaining open PRs and then create the 1.24 branch. From conal at conal.net Wed Jan 13 01:31:07 2016 From: conal at conal.net (Conal Elliott) Date: Tue, 12 Jan 2016 17:31:07 -0800 Subject: Inlining of methods (dictionary accessors) in GHC 7.10? In-Reply-To: References: Message-ID: I don't know that I can give an example, because I'm using the GHC API indirectly, via HERMIT. Andrew Farmer noticed that the dictionary accessors have special rules rather than unfoldings, and he was able to extend HERMIT to do the equivalent of applying those rules. It's working fine, and the supporting HERMIT code is reasonably simple. Cheers, - Conal On Wed, Jan 6, 2016 at 1:25 AM, Simon Peyton Jones wrote: > Quite possibly. Maybe you can give a tiny concrete example? > > > > *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Conal > Elliott > *Sent:* 06 January 2016 05:38 > *To:* ghc-devs at haskell.org > *Subject:* Inlining of methods (dictionary accessors) in GHC 7.10? > > > > Did something about change with method inlining between GHC 7.8.2 and > 7.10.3? I don't mean methods attached to instances, but rather the method > name itself, which I understand is defined as simple field accessors into a > dictionary. I do inlining indirectly via HERMIT, and the method names are > no longer successfully inlining to the accessors. The dictionaries > themselves inline fine, as do field accessors for algebraic types with > named fields. > > -- Conal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gershomb at gmail.com Wed Jan 13 02:19:45 2016 From: gershomb at gmail.com (Gershom B) Date: Tue, 12 Jan 2016 21:19:45 -0500 Subject: Warnings, -Wall, and versioning policy In-Reply-To: <56952766.2000505@gmail.com> References: <56952766.2000505@gmail.com> Message-ID: Hi Simon. I think you raise important issues here, although I believe you?re mistaken in one regard. Hackage rejects -Werror but I don?t think it rejects -Wall. ?What I?d suggest is perhaps the following. 1) The libraries committee put forward -Wall cleanliness as an _aspirational goal_ rather than a final product, noting that the actual cleanliness might be with regards to `-Wall -Wno-foo -Wno-bar``. 2) GHC _change its code_ so that `ghc -Wno-wat` yields a _warning_ rather than an _error_ on `-W` followed by an unrecognized string. 3) No warning flags be introduced into the _default_ set without at least a few releases in some other set such as `-Wall`. We may also want to try to maintain a ?best practices? example cabal file that shows how one can build with additional warnings under a ?dev? flag, and with fewer warnings otherwise ? so that the noise inflicted on package devs under their builds doesn?t get inflicted on all end users, and even perhaps with different warning flags per ghc version flag. I think this will respect the concerns of people that like to use `-Wall`, want to have relatively warning clean code, and want to have some degree of backwards compatibility (which is not an unreasonable combination in my opinion). Some related discussion:?https://ghc.haskell.org/trac/ghc/ticket/11370?and?https://ghc.haskell.org/trac/ghc/wiki/Design/Warnings Cheers, Gershom On January 12, 2016 at 11:18:57 AM, Simon Marlow (marlowsd at gmail.com) wrote: > Hi folks, > > We haven't described what guarantees GHC provides with respect to -Wall > behaviour across versions, and as a result there are some differing > expectations around this. It came up in this weeks' GHC meeting, so we > thought it would be a good idea to state the policy explicitly. Here it is: > > We guarantee that code that compiles with no warnings with -Wall > ("Wall-clean") and a particular GHC version, on a particular > platform, will be Wall-clean with future minor releases of the same > major GHC version on the same platform. > > (we plan to put this text in the User's Guide for future releases) > > There are no other guarantees. In particular: > - In a new major release, GHC may introduce new warnings into -Wall, > and/or change the meaning of existing warnings such that they trigger > (or not) under different conditions. > - GHC may generate different warnings on different platforms. (examples > of this are -fwarn-overflowed-literals and > -fwarn-unsupported-calling-conventions) > > Some rationale: > - We consider any change to the language that GHC accepts to be a > potentially code-breaking change, and subject to careful scrutiny. To > extend this to warnings would be a *lot* of work, and would make it > really difficult to introduce new warnings and improve the existing ones. > - Warnings can be based on analyses that can change in accuracy over > time. The -fwarn-unused-imports warning has changed a lot in what it > rejects, for example. > - We often introduce new warnings that naturally belong in -Wall. If > -Wall was required to be a fixed point, we would have to start > introducing new flags, and versioning, etc. and even keep the old > implementation of warnings when they change. It would get really messy. > > There are some consequences to this. -Wall -Werror is useful for > keeping your code warning-clean when developing, but shipping code with > these options turned on in the build system is asking for trouble when > building your code with different GHC versions and platforms. Keep > those options for development only. Hackage already rejects packages > that include -Wall for this reason. > > One reason we're raising this now is that it causes problems for the > 3-release policy > (https://prime.haskell.org/wiki/Libraries/3-Release-Policy) which > requires that it be possible to write code that is Wall-clean with 3 > major releases of GHC. GHC itself doesn't guarantee this, so it might > be hard for the core libraries committee to provide this guarantee. I > suggest this requirement be dropped from the policy. > > Cheers, > Simon > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > From carette at mcmaster.ca Wed Jan 13 02:57:57 2016 From: carette at mcmaster.ca (Jacques Carette) Date: Tue, 12 Jan 2016 21:57:57 -0500 Subject: Reify and separating renamer+TH from type-checking In-Reply-To: References: <1452281795-sup-9445@sabre> Message-ID: <5695BD35.9060007@mcmaster.ca> FYI, metaocaml runs into the same problem [for different reasons]. There the design decision was to not allow using a data-type in the same file as its definition. Separate compilation then solves the problem. This is a minor pain. But in Haskell, this would lead to orphan instances when using TH to derive instances, which is likely to be thought of as a rather bigger pain. Jacques On 2016-01-08 6:08 PM, Simon Peyton Jones wrote: > Bother. That's true. And it's a vital feature. Otherwise how do we do > > data T = T1 | T2 > $(makeLenses 'T) > > So we can't separate the two after all. Sorry -- I totally forgot about that. Very annoying. > > Simon > > | -----Original Message----- > | From: Edward Z. Yang [mailto:ezyang at mit.edu] > | Sent: 08 January 2016 19:40 > | To: Simon Peyton Jones > | Cc: ghc-devs > | Subject: Reify and separating renamer+TH from type-checking > | > | I implemented the refactoring to run the renamer and TH splices all > | first before doing any type-checking, but actually there's a problem: > | Template Haskell splices can call 'reify', which needs the type > | information in order to supply the information about the identifiers > | in question. I can't think of any good way around this problem. > | > | Edward > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From andrey.mokhov at newcastle.ac.uk Wed Jan 13 03:15:37 2016 From: andrey.mokhov at newcastle.ac.uk (Andrey Mokhov) Date: Wed, 13 Jan 2016 03:15:37 +0000 Subject: FW: Shaking up GHC Message-ID: Many thanks Eric, I think you solved the mystery! I changed my address on the ghc-devs mailing list from andrey.mokhov at ncl.ac.uk to andrey.mokhov at newcastle.ac.uk (it's the same mailbox really). Hopefully this will go through this time. Cheers, Andrey From: Eric Seidel To: ghc-devs at haskell.org Subject: Re: FW: Shaking up GHC I'm pretty sure you can only post to the list with the address you used to subscribe. According to https://mail.haskell.org/cgi-bin/mailman/roster/ghc-devs it looks like Andrey is subscribed with andrey.mokhov at ncl.ac.uk but the email you forwarded is from andrey.mokhov at newcastle.ac.uk So that may be the issue. Eric On Tue, Jan 12, 2016, at 08:20, Simon Peyton Jones wrote: > Dear ghc devs > Can someone figure out how to help Andrey be able to post to this mailing > list (ghc-devs)? I thought anyone subscribed can post, but perhaps not. > Thanks! > Simon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed Jan 13 12:43:58 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 13 Jan 2016 12:43:58 +0000 Subject: Warnings, -Wall, and versioning policy In-Reply-To: References: <56952766.2000505@gmail.com> Message-ID: Thanks Gershom. That all sounds fine to me. An implication is that GHC is free to introduce new warnings X into -Wall. Indeed doing so would be good, because the warning X might later move into the default set. Indeed for such warnings, adding a "PS: this warning will become the default in GHC 9.2" might be a useful way to signal the upcoming change. Then you can use -Wall and look for any "PS" indicators. You don?t give a rationale for (2) but I think you intend that if someone wants to add -Wno-X when GHC introduces X in 9.0, you don't want GHC 8.6 to fall over. Worth articulating the rationale. Simon | -----Original Message----- | From: Glasgow-haskell-users [mailto:glasgow-haskell-users- | bounces at haskell.org] On Behalf Of Gershom B | Sent: 13 January 2016 02:20 | To: GHC users ; ghc-devs at haskell.org; | Edward Kmett ; Herbert Valerio Riedel ; Simon | Marlow | Subject: Re: Warnings, -Wall, and versioning policy | | Hi Simon. I think you raise important issues here, although I believe you?re | mistaken in one regard. Hackage rejects -Werror but I don?t think it rejects | -Wall. | | ?What I?d suggest is perhaps the following. | | 1) The libraries committee put forward -Wall cleanliness as an _aspirational | goal_ rather than a final product, noting that the actual cleanliness might | be with regards to `-Wall -Wno-foo -Wno-bar``. | | 2) GHC _change its code_ so that `ghc -Wno-wat` yields a _warning_ rather | than an _error_ on `-W` followed by an unrecognized string. | | 3) No warning flags be introduced into the _default_ set without at least a | few releases in some other set such as `-Wall`. | | We may also want to try to maintain a ?best practices? example cabal file | that shows how one can build with additional warnings under a ?dev? flag, and | with fewer warnings otherwise ? so that the noise inflicted on package devs | under their builds doesn?t get inflicted on all end users, and even perhaps | with different warning flags per ghc version flag. | | I think this will respect the concerns of people that like to use `-Wall`, | want to have relatively warning clean code, and want to have some degree of | backwards compatibility (which is not an unreasonable combination in my | opinion). | | Some related | discussion:?https://ghc.haskell.org/trac/ghc/ticket/11370?and?https://ghc.has | kell.org/trac/ghc/wiki/Design/Warnings | | Cheers, | Gershom | | | On January 12, 2016 at 11:18:57 AM, Simon Marlow (marlowsd at gmail.com) wrote: | > Hi folks, | > | > We haven't described what guarantees GHC provides with respect to -Wall | > behaviour across versions, and as a result there are some differing | > expectations around this. It came up in this weeks' GHC meeting, so we | > thought it would be a good idea to state the policy explicitly. Here it is: | > | > We guarantee that code that compiles with no warnings with -Wall | > ("Wall-clean") and a particular GHC version, on a particular | > platform, will be Wall-clean with future minor releases of the same | > major GHC version on the same platform. | > | > (we plan to put this text in the User's Guide for future releases) | > | > There are no other guarantees. In particular: | > - In a new major release, GHC may introduce new warnings into -Wall, | > and/or change the meaning of existing warnings such that they trigger | > (or not) under different conditions. | > - GHC may generate different warnings on different platforms. (examples | > of this are -fwarn-overflowed-literals and | > -fwarn-unsupported-calling-conventions) | > | > Some rationale: | > - We consider any change to the language that GHC accepts to be a | > potentially code-breaking change, and subject to careful scrutiny. To | > extend this to warnings would be a *lot* of work, and would make it | > really difficult to introduce new warnings and improve the existing ones. | > - Warnings can be based on analyses that can change in accuracy over | > time. The -fwarn-unused-imports warning has changed a lot in what it | > rejects, for example. | > - We often introduce new warnings that naturally belong in -Wall. If | > -Wall was required to be a fixed point, we would have to start | > introducing new flags, and versioning, etc. and even keep the old | > implementation of warnings when they change. It would get really messy. | > | > There are some consequences to this. -Wall -Werror is useful for | > keeping your code warning-clean when developing, but shipping code with | > these options turned on in the build system is asking for trouble when | > building your code with different GHC versions and platforms. Keep | > those options for development only. Hackage already rejects packages | > that include -Wall for this reason. | > | > One reason we're raising this now is that it causes problems for the | > 3-release policy | > | (https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fprime.haske | ll.org%2fwiki%2fLibraries%2f3-Release- | Policy&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c5d13dce17e0b47a80263 | 08d31bc02832%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=KzdY%2bG8jP8ofztNpN | khKGyB5PVW1XUWbw2lCQqdSNmc%3d) which | > requires that it be possible to write code that is Wall-clean with 3 | > major releases of GHC. GHC itself doesn't guarantee this, so it might | > be hard for the core libraries committee to provide this guarantee. I | > suggest this requirement be dropped from the policy. | > | > Cheers, | > Simon | > _______________________________________________ | > Glasgow-haskell-users mailing list | > Glasgow-haskell-users at haskell.org | > | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell. | org%2fcgi-bin%2fmailman%2flistinfo%2fglasgow-haskell- | users&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c5d13dce17e0b47a802630 | 8d31bc02832%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=f395AsIaHpKb8S9z4CAo | qfGhiDxa5tzQUo8Sm5%2bgKPQ%3d | > | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users at haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell. | org%2fcgi-bin%2fmailman%2flistinfo%2fglasgow-haskell- | users%0a&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c5d13dce17e0b47a802 | 6308d31bc02832%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=6snGzNQuPSFVsZ2SY | fAxdSvo%2fjCOXvlq6cwzQM0L6iY%3d From ekmett at gmail.com Wed Jan 13 14:15:11 2016 From: ekmett at gmail.com (Edward Kmett) Date: Wed, 13 Jan 2016 09:15:11 -0500 Subject: Reify and separating renamer+TH from type-checking In-Reply-To: <1452281795-sup-9445@sabre> References: <1452281795-sup-9445@sabre> Message-ID: Worse, 'reify' is in many cases the very reason why folks are using template-haskell in the first place to build instances or classes based on properties of data types above the splice in the current module. On Fri, Jan 8, 2016 at 2:40 PM, Edward Z. Yang wrote: > I implemented the refactoring to run the renamer and TH splices all > first before doing any type-checking, but actually there's a problem: > Template Haskell splices can call 'reify', which needs the type > information in order to supply the information about the identifiers > in question. I can't think of any good way around this problem. > > Edward > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Wed Jan 13 15:43:35 2016 From: ben at well-typed.com (Ben Gamari) Date: Wed, 13 Jan 2016 16:43:35 +0100 Subject: [ANNOUNCE] Glasgow Haskell Compiler 8.0.1, release candidate 1 Message-ID: <87twmh5vtk.fsf@smart-cactus.org> The GHC Team is very pleased to announce the first release candidate of the Glasgow Haskell Compiler 8.0.1 release. Source and binary distributions as well as the newly revised users guide can be found at http://downloads.haskell.org/~ghc/8.0.1-rc1/ This is the first in a series of release candidates which will allow us to get wider testing of the significant changes that have occurred since the 7.10 series. These include, * the TypeInType extension, which unifies types and kinds allowing for promotion of more Haskell constructs to the type-level * the introduction of type application in source programs * support for recursive superclass relationships * support for Applicative do notation * introduction of the DuplicateRecordFields language extension * a rewritten and substantially more thorough pattern match checker * the introduction of injective type classes * introduction of the Strict and StrictData language extensions, allowing modules to be compiled with strict-by-default evaluation of bindings * the ability to run the GHCi interpreter in a separate process, allowing a callstacks in GHCi, easier integration with tooling, and more and much more. Changes of this magnitude will invariably bring bugs. This release candidate in particular is known to suffer from a few significant issues which are being actively worked upon, * The new -XInjectiveTypeFamilies language extension will likely be renamed to -XTypeFamilyDependencies * #11120: Type representations are missing for some types and promoted constructors * #11334: Solving for Typeable (Proxy :: Proxy 'Compose) fails * #11276: Pattern checker performance can degrade significantly in presence of pattern matches with guards * #11405: Type-level skolem-escape check fails incorrectly * #11414: Use of -XStrict results in compiler abort * #11379: Instance solver fails to terminate * #11419: Haddock documentation is currently not included in the binary distributions (and hence is missing on downloads.haskell.org) * #11370: -Wredundant-constraints being included in -Wall breaks the three-release compatibility policy In the coming weeks we will continue to iterate on these issues. We will also look at Trac tickets marked with "highest" priority on the release status page [2]. If you have a ticket that you would like to see addressed that does not meet one of these criteria, please bring this to our attention. Likewise, if you encounter an issue please open a ticket if one does not already exist. Also note that we currently cannot offer 32-bit Windows builds due to breaking changing in a recent Windows 10 upgrade. We'll work to resolve this before the 8.0 release but please let us know if this poses a significant problem for you. Cheers, - Ben [1] https://cygwin.com/ml/cygwin/2015-12/msg00003.htm [2] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From david.macek.0 at gmail.com Wed Jan 13 16:06:36 2016 From: david.macek.0 at gmail.com (David Macek) Date: Wed, 13 Jan 2016 17:06:36 +0100 Subject: [ANNOUNCE] Glasgow Haskell Compiler 8.0.1, release candidate 1 In-Reply-To: <87twmh5vtk.fsf@smart-cactus.org> References: <87twmh5vtk.fsf@smart-cactus.org> Message-ID: <5696760C.7080907@gmail.com> On 13. 1. 2016 16:43, Ben Gamari wrote: > Also note that we currently cannot offer 32-bit Windows builds due to > breaking changing in a recent Windows 10 upgrade. We'll work to > resolve this before the 8.0 release but please let us know if this poses > a significant problem for you. > [1] https://cygwin.com/ml/cygwin/2015-12/msg00003.htm I believe that issue is resolved in latest msys2-runtime. -- David Macek -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3834 bytes Desc: S/MIME Cryptographic Signature URL: From ben at well-typed.com Wed Jan 13 16:19:19 2016 From: ben at well-typed.com (Ben Gamari) Date: Wed, 13 Jan 2016 17:19:19 +0100 Subject: Dropping bzip2 release tarballs? Message-ID: <87r3hl5u60.fsf@smart-cactus.org> tl;dr do you rely on the .bz2 release tarballs on downloads.haskell.org? If so, let us know! Hello everyone, As you may have noticed, a few releases ago we started producing xz-compressed binary distributions in addition to the usual bzip2 tarballs. While preparing 8.0.1-rc1 it was suggested that we move to distributing xz tarballs exclusively. Not only would this move reduce storage and bandwidth demands on our infrastructure but it would also simplify the job of producing the distributions. Indeed there is plenty of precendent for projects who have moved exclusively to xz (the Linux kernel and git being two examples). Of course, these reasons alone aren't sufficient to abandon those who might rely on our bzip2 tarballs. If you feel strongly that we should continue to distribute bzip2 tarballs, please let us know. Thanks! - Your friendly GHC packaging gnomes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From ben at well-typed.com Wed Jan 13 16:21:57 2016 From: ben at well-typed.com (Ben Gamari) Date: Wed, 13 Jan 2016 17:21:57 +0100 Subject: [ANNOUNCE] Glasgow Haskell Compiler 8.0.1, release candidate 1 In-Reply-To: <5696760C.7080907@gmail.com> References: <87twmh5vtk.fsf@smart-cactus.org> <5696760C.7080907@gmail.com> Message-ID: <87oacp5u1m.fsf@smart-cactus.org> David Macek writes: > On 13. 1. 2016 16:43, Ben Gamari wrote: >> Also note that we currently cannot offer 32-bit Windows builds due to >> breaking changing in a recent Windows 10 upgrade. We'll work to >> resolve this before the 8.0 release but please let us know if this poses >> a significant problem for you. > >> [1] https://cygwin.com/ml/cygwin/2015-12/msg00003.htm > > I believe that issue is resolved in latest msys2-runtime. > Indeed it is. I'll produce a 32-bit build tonight. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From gershomb at gmail.com Wed Jan 13 18:17:46 2016 From: gershomb at gmail.com (Gershom B) Date: Wed, 13 Jan 2016 13:17:46 -0500 Subject: Warnings, -Wall, and versioning policy In-Reply-To: References: <56952766.2000505@gmail.com> Message-ID: On Wed, Jan 13, 2016 at 7:43 AM, Simon Peyton Jones wrote: > An implication is that GHC is free to introduce new warnings X into -Wall. Indeed doing so would be good, because the warning X might later move into the default set. Indeed for such warnings, adding a "PS: this warning will become the default in GHC 9.2" might be a useful way to signal the upcoming change. Then you can use -Wall and look for any "PS" indicators. Yep. In general I think we don't know how _much_ noise a warning will create until it makes it into the wild, so just as with other new features its good to give them a bit of a "dry run" before deciding that they come "by default." > You don?t give a rationale for (2) but I think you intend that if someone wants to add -Wno-X when GHC introduces X in 9.0, you don't want GHC 8.6 to fall over. Worth articulating the rationale. Yes, that's exactly the rationale. It doesn't help us short term, but longer term it should let users fiddle with warning flags more freely. I think the general issue with three releases is not whether or not GHC introduces warnings and at what pace, but that certain _types_ of warnings (in particular redundancies, be they constraints, imports, etc) will fire on entirely desirable code due to certain migration paths. Most of the tricks we developed for backwards-compatible migrations essentially depend on certain redundancies in code for a period. Those can't be removed without hurting backwards-compatibility of code, but their presence also induces warnings. So as a whole "warning freeness" and "backwards compatible migrations" become increasingly at odds with one another. A full refactor of our warning sets would probably help in this regard, so that the default advice could be "good code is -Wlint clean but not necessarily -Wpedantic clean". Or even "is clean under -Wpedantic -Wno-redundancies". --Gershom > > | -----Original Message----- > | From: Glasgow-haskell-users [mailto:glasgow-haskell-users- > | bounces at haskell.org] On Behalf Of Gershom B > | Sent: 13 January 2016 02:20 > | To: GHC users ; ghc-devs at haskell.org; > | Edward Kmett ; Herbert Valerio Riedel ; Simon > | Marlow > | Subject: Re: Warnings, -Wall, and versioning policy > | > | Hi Simon. I think you raise important issues here, although I believe you?re > | mistaken in one regard. Hackage rejects -Werror but I don?t think it rejects > | -Wall. > | > | What I?d suggest is perhaps the following. > | > | 1) The libraries committee put forward -Wall cleanliness as an _aspirational > | goal_ rather than a final product, noting that the actual cleanliness might > | be with regards to `-Wall -Wno-foo -Wno-bar``. > | > | 2) GHC _change its code_ so that `ghc -Wno-wat` yields a _warning_ rather > | than an _error_ on `-W` followed by an unrecognized string. > | > | 3) No warning flags be introduced into the _default_ set without at least a > | few releases in some other set such as `-Wall`. > | > | We may also want to try to maintain a ?best practices? example cabal file > | that shows how one can build with additional warnings under a ?dev? flag, and > | with fewer warnings otherwise ? so that the noise inflicted on package devs > | under their builds doesn?t get inflicted on all end users, and even perhaps > | with different warning flags per ghc version flag. > | > | I think this will respect the concerns of people that like to use `-Wall`, > | want to have relatively warning clean code, and want to have some degree of > | backwards compatibility (which is not an unreasonable combination in my > | opinion). > | > | Some related > | discussion: https://ghc.haskell.org/trac/ghc/ticket/11370 and https://ghc.has > | kell.org/trac/ghc/wiki/Design/Warnings > | > | Cheers, > | Gershom > | > | > | On January 12, 2016 at 11:18:57 AM, Simon Marlow (marlowsd at gmail.com) wrote: > | > Hi folks, > | > > | > We haven't described what guarantees GHC provides with respect to -Wall > | > behaviour across versions, and as a result there are some differing > | > expectations around this. It came up in this weeks' GHC meeting, so we > | > thought it would be a good idea to state the policy explicitly. Here it is: > | > > | > We guarantee that code that compiles with no warnings with -Wall > | > ("Wall-clean") and a particular GHC version, on a particular > | > platform, will be Wall-clean with future minor releases of the same > | > major GHC version on the same platform. > | > > | > (we plan to put this text in the User's Guide for future releases) > | > > | > There are no other guarantees. In particular: > | > - In a new major release, GHC may introduce new warnings into -Wall, > | > and/or change the meaning of existing warnings such that they trigger > | > (or not) under different conditions. > | > - GHC may generate different warnings on different platforms. (examples > | > of this are -fwarn-overflowed-literals and > | > -fwarn-unsupported-calling-conventions) > | > > | > Some rationale: > | > - We consider any change to the language that GHC accepts to be a > | > potentially code-breaking change, and subject to careful scrutiny. To > | > extend this to warnings would be a *lot* of work, and would make it > | > really difficult to introduce new warnings and improve the existing ones. > | > - Warnings can be based on analyses that can change in accuracy over > | > time. The -fwarn-unused-imports warning has changed a lot in what it > | > rejects, for example. > | > - We often introduce new warnings that naturally belong in -Wall. If > | > -Wall was required to be a fixed point, we would have to start > | > introducing new flags, and versioning, etc. and even keep the old > | > implementation of warnings when they change. It would get really messy. > | > > | > There are some consequences to this. -Wall -Werror is useful for > | > keeping your code warning-clean when developing, but shipping code with > | > these options turned on in the build system is asking for trouble when > | > building your code with different GHC versions and platforms. Keep > | > those options for development only. Hackage already rejects packages > | > that include -Wall for this reason. > | > > | > One reason we're raising this now is that it causes problems for the > | > 3-release policy > | > > | (https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fprime.haske > | ll.org%2fwiki%2fLibraries%2f3-Release- > | Policy&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c5d13dce17e0b47a80263 > | 08d31bc02832%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=KzdY%2bG8jP8ofztNpN > | khKGyB5PVW1XUWbw2lCQqdSNmc%3d) which > | > requires that it be possible to write code that is Wall-clean with 3 > | > major releases of GHC. GHC itself doesn't guarantee this, so it might > | > be hard for the core libraries committee to provide this guarantee. I > | > suggest this requirement be dropped from the policy. > | > > | > Cheers, > | > Simon > | > _______________________________________________ > | > Glasgow-haskell-users mailing list > | > Glasgow-haskell-users at haskell.org > | > > | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell. > | org%2fcgi-bin%2fmailman%2flistinfo%2fglasgow-haskell- > | users&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c5d13dce17e0b47a802630 > | 8d31bc02832%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=f395AsIaHpKb8S9z4CAo > | qfGhiDxa5tzQUo8Sm5%2bgKPQ%3d > | > > | > | _______________________________________________ > | Glasgow-haskell-users mailing list > | Glasgow-haskell-users at haskell.org > | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell. > | org%2fcgi-bin%2fmailman%2flistinfo%2fglasgow-haskell- > | users%0a&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c5d13dce17e0b47a802 > | 6308d31bc02832%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=6snGzNQuPSFVsZ2SY > | fAxdSvo%2fjCOXvlq6cwzQM0L6iY%3d From asr at eafit.edu.co Wed Jan 13 20:27:22 2016 From: asr at eafit.edu.co (=?UTF-8?B?QW5kcsOpcyBTaWNhcmQtUmFtw61yZXo=?=) Date: Wed, 13 Jan 2016 15:27:22 -0500 Subject: [ANNOUNCE] Glasgow Haskell Compiler 8.0.1, release candidate 1 In-Reply-To: <87twmh5vtk.fsf@smart-cactus.org> References: <87twmh5vtk.fsf@smart-cactus.org> Message-ID: On 13 January 2016 at 10:43, Ben Gamari wrote: > The GHC Team is very pleased to announce the first release candidate of > the Glasgow Haskell Compiler 8.0.1 release. Source and binary > distributions as well as the newly revised users guide can be found at > > http://downloads.haskell.org/~ghc/8.0.1-rc1/ I'm using Ubuntu precise (12.04LTS). How I know which binary distribution should install? I'm asking because I could install without problems both ghc*x86_64-deb7-linux* and ghc*x86_64-deb8-linux*. Best, -- Andr?s From george.colpitts at gmail.com Wed Jan 13 20:28:29 2016 From: george.colpitts at gmail.com (George Colpitts) Date: Wed, 13 Jan 2016 16:28:29 -0400 Subject: [ANNOUNCE] Glasgow Haskell Compiler 8.0.1, release candidate 1 In-Reply-To: <87twmh5vtk.fsf@smart-cactus.org> References: <87twmh5vtk.fsf@smart-cactus.org> Message-ID: installs fine on mac but cabal install vector fails on primitive, looks to me like gmp library is not provided cabal install vector Resolving dependencies... Configuring primitive-0.6.1.0... Failed to install primitive-0.6.1.0 Build log ( /Users/gcolpitts/.cabal/logs/primitive-0.6.1.0.log ): cabal: Error: some packages failed to install: primitive-0.6.1.0 failed during the configure step. The exception was: user error ('/usr/local/bin/ghc' exited with an error: *ld: library not found for -lgmp* collect2: error: ld returned 1 exit status `gcc' failed in phase `Linker'. (Exit code: 1) ) vector-0.11.0.0 depends on primitive-0.6.1.0 which failed to install. On Wed, Jan 13, 2016 at 11:43 AM, Ben Gamari wrote: > > The GHC Team is very pleased to announce the first release candidate of > the Glasgow Haskell Compiler 8.0.1 release. Source and binary > distributions as well as the newly revised users guide can be found at > > http://downloads.haskell.org/~ghc/8.0.1-rc1/ > > This is the first in a series of release candidates which will allow us > to get wider testing of the significant changes that have occurred since > the 7.10 series. These include, > > * the TypeInType extension, which unifies types and kinds allowing for > promotion of more Haskell constructs to the type-level > > * the introduction of type application in source programs > > * support for recursive superclass relationships > > * support for Applicative do notation > > * introduction of the DuplicateRecordFields language extension > > * a rewritten and substantially more thorough pattern match checker > > * the introduction of injective type classes > > * introduction of the Strict and StrictData language extensions, > allowing modules to be compiled with strict-by-default evaluation > of bindings > > * the ability to run the GHCi interpreter in a separate process, > allowing a callstacks in GHCi, easier integration with tooling, and > more > > and much more. > > Changes of this magnitude will invariably bring bugs. This release > candidate in particular is known to suffer from a few significant issues > which are being actively worked upon, > > * The new -XInjectiveTypeFamilies language extension will likely be > renamed to -XTypeFamilyDependencies > > * #11120: Type representations are missing for some types and promoted > constructors > > * #11334: Solving for Typeable (Proxy :: Proxy 'Compose) fails > > * #11276: Pattern checker performance can degrade significantly in > presence of pattern matches with guards > > * #11405: Type-level skolem-escape check fails incorrectly > > * #11414: Use of -XStrict results in compiler abort > > * #11379: Instance solver fails to terminate > > * #11419: Haddock documentation is currently not included in the binary > distributions (and hence is missing on downloads.haskell.org) > > * #11370: -Wredundant-constraints being included in -Wall breaks > the three-release compatibility policy > > In the coming weeks we will continue to iterate on these issues. We will > also look at Trac tickets marked with "highest" priority on the release > status page [2]. > > If you have a ticket that you would like to see addressed that does not > meet one of these criteria, please bring this to our attention. > Likewise, if you encounter an issue please open a ticket if one does not > already exist. > > Also note that we currently cannot offer 32-bit Windows builds due to > breaking changing in a recent Windows 10 upgrade. We'll work to > resolve this before the 8.0 release but please let us know if this poses > a significant problem for you. > > Cheers, > > - Ben > > > [1] https://cygwin.com/ml/cygwin/2015-12/msg00003.htm > [2] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1 > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From asr at eafit.edu.co Wed Jan 13 20:49:44 2016 From: asr at eafit.edu.co (=?UTF-8?B?QW5kcsOpcyBTaWNhcmQtUmFtw61yZXo=?=) Date: Wed, 13 Jan 2016 15:49:44 -0500 Subject: [ANNOUNCE] Glasgow Haskell Compiler 8.0.1, release candidate 1 In-Reply-To: References: <87twmh5vtk.fsf@smart-cactus.org> Message-ID: On 13 January 2016 at 15:28, George Colpitts wrote: > installs fine on mac but cabal install vector fails on primitive, looks to > me like gmp library is not provided > > cabal install vector > Resolving dependencies... > Configuring primitive-0.6.1.0... > Failed to install primitive-0.6.1.0 > Build log ( /Users/gcolpitts/.cabal/logs/primitive-0.6.1.0.log ): > cabal: Error: some packages failed to install: > primitive-0.6.1.0 failed during the configure step. The exception was: > user error ('/usr/local/bin/ghc' exited with an error: > ld: library not found for -lgmp > collect2: error: ld returned 1 exit status > `gcc' failed in phase `Linker'. (Exit code: 1) > ) > vector-0.11.0.0 depends on primitive-0.6.1.0 which failed to install. I found a different problem installing vector on Ubuntu precise (12.04LTS): $ cabal install vector ... Installed primitive-0.6.1.0 Configuring vector-0.11.0.0... ... Data/Vector/Generic/Mutable/Base.hs:18:1: error: Bad interface file: /home/asr/.cabal/lib/x86_64-linux-ghc-8.0.0.20160111/primitive-0.6.1.0-6R7Tzfc83qM6k1j6TLqRai/Control/Monad/Primitive.hi Something is amiss; requested module primitive-0.6.1.0 at primitive-0.6.1.0-de94d43ed2b084399e39dfe5a3f60217:Control.Monad.Primitive differs from name found in the interface file primi_6R7Tzfc83qM6k1j6TLqRai:Control.Monad.Primitive Failed to install vector-0.11.0.0 I have found the same "Bad interface file" problem installing other packages. Best, -- Andr?s From karel.gardas at centrum.cz Wed Jan 13 20:55:13 2016 From: karel.gardas at centrum.cz (Karel Gardas) Date: Wed, 13 Jan 2016 21:55:13 +0100 Subject: [ANNOUNCE] Glasgow Haskell Compiler 8.0.1, release candidate 1 In-Reply-To: References: <87twmh5vtk.fsf@smart-cactus.org> Message-ID: <5696B9B1.50901@centrum.cz> On 01/13/16 09:28 PM, George Colpitts wrote: > installs fine on mac but cabal install vector fails on primitive, looks > to me like gmp library is not provided gmp should be probably provided by your OS. Looks like you will also need its -dev version too. Does sudo apt-get install gmp-dev or sudo apt-get install libgmp-dev helps? Sorry, don't know precise package name on your platform... Karel From allbery.b at gmail.com Wed Jan 13 20:57:11 2016 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 13 Jan 2016 15:57:11 -0500 Subject: [ANNOUNCE] Glasgow Haskell Compiler 8.0.1, release candidate 1 In-Reply-To: <5696B9B1.50901@centrum.cz> References: <87twmh5vtk.fsf@smart-cactus.org> <5696B9B1.50901@centrum.cz> Message-ID: On Wed, Jan 13, 2016 at 3:55 PM, Karel Gardas wrote: > On 01/13/16 09:28 PM, George Colpitts wrote: > >> installs fine on mac but cabal install vector fails on primitive, looks >> to me like gmp library is not provided >> > > gmp should be probably provided by your OS. Looks like you will also need > its -dev version too. Does > Won't help on OS X unless they have Fink installed, and even then that means potentially getting a different libgmp than base is using. If base includes libgmp, as it must on Windows / OS X, it should be made available to other packages. -- 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: From karel.gardas at centrum.cz Wed Jan 13 21:00:05 2016 From: karel.gardas at centrum.cz (Karel Gardas) Date: Wed, 13 Jan 2016 22:00:05 +0100 Subject: [ANNOUNCE] Glasgow Haskell Compiler 8.0.1, release candidate 1 In-Reply-To: References: <87twmh5vtk.fsf@smart-cactus.org> <5696B9B1.50901@centrum.cz> Message-ID: <5696BAD5.3090209@centrum.cz> I'm sorry, this is my mistake. I've thought original poster was talking about ubuntu 12.04 LTS but it looks like it was mac os x in fact. Sorry for this noise. Karel On 01/13/16 09:57 PM, Brandon Allbery wrote: > On Wed, Jan 13, 2016 at 3:55 PM, Karel Gardas > wrote: > > On 01/13/16 09:28 PM, George Colpitts wrote: > > installs fine on mac but cabal install vector fails on > primitive, looks > to me like gmp library is not provided > > > gmp should be probably provided by your OS. Looks like you will also > need its -dev version too. Does > > > Won't help on OS X unless they have Fink installed, and even then that > means potentially getting a different libgmp than base is using. > If base includes libgmp, as it must on Windows / OS X, it should be made > available to other packages. > > -- > brandon s allbery kf8nh sine nomine associates > allbery.b at gmail.com ballbery at sinenomine.net > > unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net From simonpj at microsoft.com Wed Jan 13 21:42:11 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 13 Jan 2016 21:42:11 +0000 Subject: Warnings, -Wall, and versioning policy In-Reply-To: References: <56952766.2000505@gmail.com> Message-ID: <9058175ec0b04d75bf896bc98da524a8@DB4PR30MB030.064d.mgd.msft.net> OK. When this thread comes to a conclusion, can someone write it down; update the 3-release policy; and say what changes you want in GHC? Thanks Simon | -----Original Message----- | From: Gershom B [mailto:gershomb at gmail.com] | Sent: 13 January 2016 18:18 | To: Simon Peyton Jones | Cc: GHC users ; ghc-devs at haskell.org; | Edward Kmett ; Herbert Valerio Riedel ; Simon | Marlow | Subject: Re: Warnings, -Wall, and versioning policy | | On Wed, Jan 13, 2016 at 7:43 AM, Simon Peyton Jones | wrote: | | > An implication is that GHC is free to introduce new warnings X into -Wall. | Indeed doing so would be good, because the warning X might later move into | the default set. Indeed for such warnings, adding a "PS: this warning will | become the default in GHC 9.2" might be a useful way to signal the upcoming | change. Then you can use -Wall and look for any "PS" indicators. | | Yep. In general I think we don't know how _much_ noise a warning will | create until it makes it into the wild, so just as with other new | features its good to give them a bit of a "dry run" before deciding | that they come "by default." | | > You don?t give a rationale for (2) but I think you intend that if someone | wants to add -Wno-X when GHC introduces X in 9.0, you don't want GHC 8.6 to | fall over. Worth articulating the rationale. | | Yes, that's exactly the rationale. It doesn't help us short term, but | longer term it should let users fiddle with warning flags more freely. | | I think the general issue with three releases is not whether or not | GHC introduces warnings and at what pace, but that certain _types_ of | warnings (in particular redundancies, be they constraints, imports, | etc) will fire on entirely desirable code due to certain migration | paths. Most of the tricks we developed for backwards-compatible | migrations essentially depend on certain redundancies in code for a | period. Those can't be removed without hurting backwards-compatibility | of code, but their presence also induces warnings. | | So as a whole "warning freeness" and "backwards compatible migrations" | become increasingly at odds with one another. | | A full refactor of our warning sets would probably help in this | regard, so that the default advice could be "good code is -Wlint clean | but not necessarily -Wpedantic clean". Or even "is clean under | -Wpedantic -Wno-redundancies". | | --Gershom | | > | > | -----Original Message----- | > | From: Glasgow-haskell-users [mailto:glasgow-haskell-users- | > | bounces at haskell.org] On Behalf Of Gershom B | > | Sent: 13 January 2016 02:20 | > | To: GHC users ; ghc-devs at haskell.org; | > | Edward Kmett ; Herbert Valerio Riedel ; | Simon | > | Marlow | > | Subject: Re: Warnings, -Wall, and versioning policy | > | | > | Hi Simon. I think you raise important issues here, although I believe | you?re | > | mistaken in one regard. Hackage rejects -Werror but I don?t think it | rejects | > | -Wall. | > | | > | What I?d suggest is perhaps the following. | > | | > | 1) The libraries committee put forward -Wall cleanliness as an | _aspirational | > | goal_ rather than a final product, noting that the actual cleanliness | might | > | be with regards to `-Wall -Wno-foo -Wno-bar``. | > | | > | 2) GHC _change its code_ so that `ghc -Wno-wat` yields a _warning_ rather | > | than an _error_ on `-W` followed by an unrecognized string. | > | | > | 3) No warning flags be introduced into the _default_ set without at least | a | > | few releases in some other set such as `-Wall`. | > | | > | We may also want to try to maintain a ?best practices? example cabal file | > | that shows how one can build with additional warnings under a ?dev? flag, | and | > | with fewer warnings otherwise ? so that the noise inflicted on package | devs | > | under their builds doesn?t get inflicted on all end users, and even | perhaps | > | with different warning flags per ghc version flag. | > | | > | I think this will respect the concerns of people that like to use `- | Wall`, | > | want to have relatively warning clean code, and want to have some degree | of | > | backwards compatibility (which is not an unreasonable combination in my | > | opinion). | > | | > | Some related | > | discussion: https://ghc.haskell.org/trac/ghc/ticket/11370 and | https://ghc.has | > | | https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fkell.org%2ft | rac%2fghc%2fwiki%2fDesign%2fWarnings&data=01%7c01%7csimonpj%40064d.mgd.micros | oft.com%7c9de7c65d89a84408f00808d31c45e258%7c72f988bf86f141af91ab2d7cd011db47 | %7c1&sdata=BE9pq5knT%2fWTxOfrtEYefqDC2qMEQP%2b9fbcgvs%2f2qr0%3d | Cheers, | > | Gershom | > | | > | | > | On January 12, 2016 at 11:18:57 AM, Simon Marlow (marlowsd at gmail.com) | wrote: | > | > Hi folks, | > | > | > | > We haven't described what guarantees GHC provides with respect to -Wall | > | > behaviour across versions, and as a result there are some differing | > | > expectations around this. It came up in this weeks' GHC meeting, so we | > | > thought it would be a good idea to state the policy explicitly. Here it | is: | > | > | > | > We guarantee that code that compiles with no warnings with -Wall | > | > ("Wall-clean") and a particular GHC version, on a particular | > | > platform, will be Wall-clean with future minor releases of the same | > | > major GHC version on the same platform. | > | > | > | > (we plan to put this text in the User's Guide for future releases) | > | > | > | > There are no other guarantees. In particular: | > | > - In a new major release, GHC may introduce new warnings into -Wall, | > | > and/or change the meaning of existing warnings such that they trigger | > | > (or not) under different conditions. | > | > - GHC may generate different warnings on different platforms. (examples | > | > of this are -fwarn-overflowed-literals and | > | > -fwarn-unsupported-calling-conventions) | > | > | > | > Some rationale: | > | > - We consider any change to the language that GHC accepts to be a | > | > potentially code-breaking change, and subject to careful scrutiny. To | > | > extend this to warnings would be a *lot* of work, and would make it | > | > really difficult to introduce new warnings and improve the existing | ones. | > | > - Warnings can be based on analyses that can change in accuracy over | > | > time. The -fwarn-unused-imports warning has changed a lot in what it | > | > rejects, for example. | > | > - We often introduce new warnings that naturally belong in -Wall. If | > | > -Wall was required to be a fixed point, we would have to start | > | > introducing new flags, and versioning, etc. and even keep the old | > | > implementation of warnings when they change. It would get really messy. | > | > | > | > There are some consequences to this. -Wall -Werror is useful for | > | > keeping your code warning-clean when developing, but shipping code with | > | > these options turned on in the build system is asking for trouble when | > | > building your code with different GHC versions and platforms. Keep | > | > those options for development only. Hackage already rejects packages | > | > that include -Wall for this reason. | > | > | > | > One reason we're raising this now is that it causes problems for the | > | > 3-release policy | > | > | > | | (https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fprime.haske | > | ll.org%2fwiki%2fLibraries%2f3-Release- | > | | Policy&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c5d13dce17e0b47a80263 | > | | 08d31bc02832%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=KzdY%2bG8jP8ofztNpN | > | khKGyB5PVW1XUWbw2lCQqdSNmc%3d) which | > | > requires that it be possible to write code that is Wall-clean with 3 | > | > major releases of GHC. GHC itself doesn't guarantee this, so it might | > | > be hard for the core libraries committee to provide this guarantee. I | > | > suggest this requirement be dropped from the policy. | > | > | > | > Cheers, | > | > Simon | > | > _______________________________________________ | > | > Glasgow-haskell-users mailing list | > | > Glasgow-haskell-users at haskell.org | > | > | > | | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell. | > | org%2fcgi-bin%2fmailman%2flistinfo%2fglasgow-haskell- | > | | users&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c5d13dce17e0b47a802630 | > | | 8d31bc02832%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=f395AsIaHpKb8S9z4CAo | > | qfGhiDxa5tzQUo8Sm5%2bgKPQ%3d | > | > | > | | > | _______________________________________________ | > | Glasgow-haskell-users mailing list | > | Glasgow-haskell-users at haskell.org | > | | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell. | > | org%2fcgi-bin%2fmailman%2flistinfo%2fglasgow-haskell- | > | | users%0a&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c5d13dce17e0b47a802 | > | | 6308d31bc02832%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=6snGzNQuPSFVsZ2SY | > | fAxdSvo%2fjCOXvlq6cwzQM0L6iY%3d From ben at well-typed.com Wed Jan 13 22:33:11 2016 From: ben at well-typed.com (Ben Gamari) Date: Wed, 13 Jan 2016 23:33:11 +0100 Subject: [ANNOUNCE] Glasgow Haskell Compiler 8.0.1, release candidate 1 In-Reply-To: References: <87twmh5vtk.fsf@smart-cactus.org> Message-ID: <8760yx5cuw.fsf@smart-cactus.org> Andr?s Sicard-Ram?rez writes: > I found a different problem installing vector on Ubuntu precise (12.04LTS): > > $ cabal install vector > ... > Installed primitive-0.6.1.0 > Configuring vector-0.11.0.0... > ... > Data/Vector/Generic/Mutable/Base.hs:18:1: error: > Bad interface file: > /home/asr/.cabal/lib/x86_64-linux-ghc-8.0.0.20160111/primitive-0.6.1.0-6R7Tzfc83qM6k1j6TLqRai/Control/Monad/Primitive.hi > Something is amiss; requested module > primitive-0.6.1.0 at primitive-0.6.1.0-de94d43ed2b084399e39dfe5a3f60217:Control.Monad.Primitive > differs from name found in the interface file > primi_6R7Tzfc83qM6k1j6TLqRai:Control.Monad.Primitive > Failed to install vector-0.11.0.0 > > I have found the same "Bad interface file" problem installing other packages. > Ahh yes; I suspected I was missing something in the release announcement. Due to unfortunate Cabal/GHC interactions, GHC 8.0 will require Cabal 0.23. These interface file issues should be cleared up by wiping your 8.0.1 package database, installing Cabal and cabal-install 0.23 (only available from the upstream repository at the moment), and trying to install vector again. The reason for this is a change in how packages are identified in GHC 8.0. While previous versions of Cabal identified packages to GHC with a package key (with GHC's -this-package-key argument), GHC 8.0 and later uses another, more specific identifier, the installed package ID. For compatibility reasons -this-package-key is currently accepted by GHC as a synonym for -package-name. This is a bit unfortunate, however, as the two flags aren't really synonymous. This is the reason why cabal-install fails. I'm discussing this with Edward Yang and hopefully we'll be able to have a louder, more obvious failure in place for rc2. I'll be sure to mention this in future release announcements. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From ben at well-typed.com Wed Jan 13 22:52:16 2016 From: ben at well-typed.com (Ben Gamari) Date: Wed, 13 Jan 2016 23:52:16 +0100 Subject: [ANNOUNCE] Glasgow Haskell Compiler 8.0.1, release candidate 1 In-Reply-To: References: <87twmh5vtk.fsf@smart-cactus.org> Message-ID: <8737u15bz3.fsf@smart-cactus.org> George Colpitts writes: > installs fine on mac but cabal install vector fails on primitive, looks to > me like gmp library is not provided > > cabal install vector > Resolving dependencies... > Configuring primitive-0.6.1.0... > Failed to install primitive-0.6.1.0 > Build log ( /Users/gcolpitts/.cabal/logs/primitive-0.6.1.0.log ): > cabal: Error: some packages failed to install: > primitive-0.6.1.0 failed during the configure step. The exception was: > user error ('/usr/local/bin/ghc' exited with an error: > *ld: library not found for -lgmp* > collect2: error: ld returned 1 exit status > `gcc' failed in phase `Linker'. (Exit code: 1) > ) > vector-0.11.0.0 depends on primitive-0.6.1.0 which failed to install. > The issue here appears to be that the build was compiled against the host's libgmp on account of the the Wiki build instructions [1] being out of date. I've fixed this particular inaccuracy, but it would be great if someone familiar with Darwin could take a close look at this page: do a build of their own, work through the build instructions, and ensure that the build instructions are still accurate, fixing any issues. George or Carter, perhaps one of you could pick this up? Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From ben at well-typed.com Wed Jan 13 22:54:16 2016 From: ben at well-typed.com (Ben Gamari) Date: Wed, 13 Jan 2016 23:54:16 +0100 Subject: [ANNOUNCE] Glasgow Haskell Compiler 8.0.1, release candidate 1 In-Reply-To: References: <87twmh5vtk.fsf@smart-cactus.org> Message-ID: <87ziw93xbb.fsf@smart-cactus.org> Andr?s Sicard-Ram?rez writes: > On 13 January 2016 at 10:43, Ben Gamari wrote: >> The GHC Team is very pleased to announce the first release candidate of >> the Glasgow Haskell Compiler 8.0.1 release. Source and binary >> distributions as well as the newly revised users guide can be found at >> >> http://downloads.haskell.org/~ghc/8.0.1-rc1/ > > I'm using Ubuntu precise (12.04LTS). How I know which binary > distribution should install? > > I'm asking because I could install without problems both > > ghc*x86_64-deb7-linux* and > > ghc*x86_64-deb8-linux*. > You should likely be using the deb8 build in this case. The only difference is the libc version which is linked against. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From asr at eafit.edu.co Wed Jan 13 22:54:19 2016 From: asr at eafit.edu.co (=?UTF-8?B?QW5kcsOpcyBTaWNhcmQtUmFtw61yZXo=?=) Date: Wed, 13 Jan 2016 17:54:19 -0500 Subject: [ANNOUNCE] Glasgow Haskell Compiler 8.0.1, release candidate 1 In-Reply-To: <8760yx5cuw.fsf@smart-cactus.org> References: <87twmh5vtk.fsf@smart-cactus.org> <8760yx5cuw.fsf@smart-cactus.org> Message-ID: 2016-01-13 17:33 GMT-05:00 Ben Gamari : > Due to unfortunate Cabal/GHC interactions, GHC 8.0 will require > Cabal 0.23. These interface file issues should be cleared up by > wiping your 8.0.1 package database, installing Cabal and cabal-install > 0.23 (only available from the upstream repository at the moment), and > trying to install vector again. Installing Cabal and cabal-install (with GHC 7.10.3) from the upstream repository fixed the problem. Thanks! -- Andr?s From xichekolas at gmail.com Thu Jan 14 00:18:27 2016 From: xichekolas at gmail.com (Andrew Farmer) Date: Wed, 13 Jan 2016 16:18:27 -0800 Subject: [ANNOUNCE] Glasgow Haskell Compiler 8.0.1, release candidate 1 In-Reply-To: <8737u15bz3.fsf@smart-cactus.org> References: <87twmh5vtk.fsf@smart-cactus.org> <8737u15bz3.fsf@smart-cactus.org> Message-ID: I'm guessing this is the same problem with gmp on OS X, but I got it during the ./configure step, so thought I'd pass along the error message: mba:ghc-8.0.0.20160111 xich$ ./configure --prefix=/Users/xich/projects/ghc8 checking for path to top of build tree... dyld: Library not loaded: /usr/local/opt/gmp/lib/libgmp.10.dylib Referenced from: /Users/xich/projects/ghc-8.0.0.20160111/utils/ghc-pwd/dist-install/build/tmp/ghc-pwd Reason: image not found configure: error: cannot determine current directory You made reference to the wiki build instructions... do you have a link to the ones you mean? I can try following them. On Wed, Jan 13, 2016 at 2:52 PM, Ben Gamari wrote: > George Colpitts writes: > >> installs fine on mac but cabal install vector fails on primitive, looks to >> me like gmp library is not provided >> >> cabal install vector >> Resolving dependencies... >> Configuring primitive-0.6.1.0... >> Failed to install primitive-0.6.1.0 >> Build log ( /Users/gcolpitts/.cabal/logs/primitive-0.6.1.0.log ): >> cabal: Error: some packages failed to install: >> primitive-0.6.1.0 failed during the configure step. The exception was: >> user error ('/usr/local/bin/ghc' exited with an error: >> *ld: library not found for -lgmp* >> collect2: error: ld returned 1 exit status >> `gcc' failed in phase `Linker'. (Exit code: 1) >> ) >> vector-0.11.0.0 depends on primitive-0.6.1.0 which failed to install. >> > The issue here appears to be that the build was compiled against the > host's libgmp on account of the the Wiki build instructions [1] being out of > date. I've fixed this particular inaccuracy, but it would be great if > someone familiar with Darwin could take a close look at this page: do a > build of their own, work through the build instructions, and ensure that > the build instructions are still accurate, fixing any issues. > > George or Carter, perhaps one of you could pick this up? > > Cheers, > > - Ben > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From george.colpitts at gmail.com Thu Jan 14 00:20:17 2016 From: george.colpitts at gmail.com (George Colpitts) Date: Wed, 13 Jan 2016 20:20:17 -0400 Subject: [ANNOUNCE] Glasgow Haskell Compiler 8.0.1, release candidate 1 In-Reply-To: References: <87twmh5vtk.fsf@smart-cactus.org> <8737u15bz3.fsf@smart-cactus.org> Message-ID: I asked the same question and Ben answered: (gmail default is reply and I forgot to do reply all) [1] https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/MacOSX On Wed, Jan 13, 2016 at 8:18 PM, Andrew Farmer wrote: > I'm guessing this is the same problem with gmp on OS X, but I got it > during the ./configure step, so thought I'd pass along the error > message: > > mba:ghc-8.0.0.20160111 xich$ ./configure --prefix=/Users/xich/projects/ghc8 > checking for path to top of build tree... dyld: Library not loaded: > /usr/local/opt/gmp/lib/libgmp.10.dylib > Referenced from: > > /Users/xich/projects/ghc-8.0.0.20160111/utils/ghc-pwd/dist-install/build/tmp/ghc-pwd > Reason: image not found > configure: error: cannot determine current directory > > You made reference to the wiki build instructions... do you have a > link to the ones you mean? I can try following them. > > On Wed, Jan 13, 2016 at 2:52 PM, Ben Gamari wrote: > > George Colpitts writes: > > > >> installs fine on mac but cabal install vector fails on primitive, looks > to > >> me like gmp library is not provided > >> > >> cabal install vector > >> Resolving dependencies... > >> Configuring primitive-0.6.1.0... > >> Failed to install primitive-0.6.1.0 > >> Build log ( /Users/gcolpitts/.cabal/logs/primitive-0.6.1.0.log ): > >> cabal: Error: some packages failed to install: > >> primitive-0.6.1.0 failed during the configure step. The exception was: > >> user error ('/usr/local/bin/ghc' exited with an error: > >> *ld: library not found for -lgmp* > >> collect2: error: ld returned 1 exit status > >> `gcc' failed in phase `Linker'. (Exit code: 1) > >> ) > >> vector-0.11.0.0 depends on primitive-0.6.1.0 which failed to install. > >> > > The issue here appears to be that the build was compiled against the > > host's libgmp on account of the the Wiki build instructions [1] being > out of > > date. I've fixed this particular inaccuracy, but it would be great if > > someone familiar with Darwin could take a close look at this page: do a > > build of their own, work through the build instructions, and ensure that > > the build instructions are still accurate, fixing any issues. > > > > George or Carter, perhaps one of you could pick this up? > > > > 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: From carter.schonwald at gmail.com Thu Jan 14 00:40:12 2016 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 13 Jan 2016 19:40:12 -0500 Subject: [ANNOUNCE] Glasgow Haskell Compiler 8.0.1, release candidate 1 In-Reply-To: References: <87twmh5vtk.fsf@smart-cactus.org> <8737u15bz3.fsf@smart-cactus.org> Message-ID: I'll take a look at the directions and validate they're correct. Just finished up some family dinner stuff. On Wednesday, January 13, 2016, George Colpitts wrote: > I asked the same question and Ben answered: (gmail default is reply and I > forgot to do reply all) > > [1] https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/MacOSX > > On Wed, Jan 13, 2016 at 8:18 PM, Andrew Farmer > wrote: > >> I'm guessing this is the same problem with gmp on OS X, but I got it >> during the ./configure step, so thought I'd pass along the error >> message: >> >> mba:ghc-8.0.0.20160111 xich$ ./configure >> --prefix=/Users/xich/projects/ghc8 >> checking for path to top of build tree... dyld: Library not loaded: >> /usr/local/opt/gmp/lib/libgmp.10.dylib >> Referenced from: >> >> /Users/xich/projects/ghc-8.0.0.20160111/utils/ghc-pwd/dist-install/build/tmp/ghc-pwd >> Reason: image not found >> configure: error: cannot determine current directory >> >> You made reference to the wiki build instructions... do you have a >> link to the ones you mean? I can try following them. >> >> On Wed, Jan 13, 2016 at 2:52 PM, Ben Gamari > > wrote: >> > George Colpitts > > writes: >> > >> >> installs fine on mac but cabal install vector fails on primitive, >> looks to >> >> me like gmp library is not provided >> >> >> >> cabal install vector >> >> Resolving dependencies... >> >> Configuring primitive-0.6.1.0... >> >> Failed to install primitive-0.6.1.0 >> >> Build log ( /Users/gcolpitts/.cabal/logs/primitive-0.6.1.0.log ): >> >> cabal: Error: some packages failed to install: >> >> primitive-0.6.1.0 failed during the configure step. The exception was: >> >> user error ('/usr/local/bin/ghc' exited with an error: >> >> *ld: library not found for -lgmp* >> >> collect2: error: ld returned 1 exit status >> >> `gcc' failed in phase `Linker'. (Exit code: 1) >> >> ) >> >> vector-0.11.0.0 depends on primitive-0.6.1.0 which failed to install. >> >> >> > The issue here appears to be that the build was compiled against the >> > host's libgmp on account of the the Wiki build instructions [1] being >> out of >> > date. I've fixed this particular inaccuracy, but it would be great if >> > someone familiar with Darwin could take a close look at this page: do a >> > build of their own, work through the build instructions, and ensure that >> > the build instructions are still accurate, fixing any issues. >> > >> > George or Carter, perhaps one of you could pick this up? >> > >> > 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: From george.colpitts at gmail.com Thu Jan 14 00:42:03 2016 From: george.colpitts at gmail.com (George Colpitts) Date: Wed, 13 Jan 2016 20:42:03 -0400 Subject: [ANNOUNCE] Glasgow Haskell Compiler 8.0.1, release candidate 1 In-Reply-To: <87twmh5vtk.fsf@smart-cactus.org> References: <87twmh5vtk.fsf@smart-cactus.org> Message-ID: Building from src on a Mac Not sure why configure script couldn't figure out version of llvm I have: checking for llc-3.7... no checking for llc... /usr/local/bin/llc checking /usr/local/bin/llc is version 3.7... no checking for opt-3.7... no checking for opt... /usr/local/bin/opt checking /usr/local/bin/opt is version 3.7... no ./configure: line 7717: test: too many arguments ./configure: line 7765: test: too many arguments checking whether bootstrap compiler is affected by bug 9439... : Warning: Couldn't figure out LLVM version! Make sure you have installed LLVM ghc: could not execute: , ( failed to compile bash-3.2$ llc --version LLVM (http://llvm.org/): LLVM version 3.5.1 Optimized build with assertions. Built Jan 16 2015 (03:07:02). Default target: x86_64-apple-darwin15.2.0 Host CPU: corei7 Registered Targets: x86 - 32-bit X86: Pentium-Pro and above x86-64 - 64-bit X86: EM64T and AMD64 bash-3.2$ opt --version LLVM (http://llvm.org/): LLVM version 3.5.1 Optimized build with assertions. Built Jan 16 2015 (03:07:02). Default target: x86_64-apple-darwin15.2.0 Host CPU: corei7 On Wed, Jan 13, 2016 at 11:43 AM, Ben Gamari wrote: > > The GHC Team is very pleased to announce the first release candidate of > the Glasgow Haskell Compiler 8.0.1 release. Source and binary > distributions as well as the newly revised users guide can be found at > > http://downloads.haskell.org/~ghc/8.0.1-rc1/ > > This is the first in a series of release candidates which will allow us > to get wider testing of the significant changes that have occurred since > the 7.10 series. These include, > > * the TypeInType extension, which unifies types and kinds allowing for > promotion of more Haskell constructs to the type-level > > * the introduction of type application in source programs > > * support for recursive superclass relationships > > * support for Applicative do notation > > * introduction of the DuplicateRecordFields language extension > > * a rewritten and substantially more thorough pattern match checker > > * the introduction of injective type classes > > * introduction of the Strict and StrictData language extensions, > allowing modules to be compiled with strict-by-default evaluation > of bindings > > * the ability to run the GHCi interpreter in a separate process, > allowing a callstacks in GHCi, easier integration with tooling, and > more > > and much more. > > Changes of this magnitude will invariably bring bugs. This release > candidate in particular is known to suffer from a few significant issues > which are being actively worked upon, > > * The new -XInjectiveTypeFamilies language extension will likely be > renamed to -XTypeFamilyDependencies > > * #11120: Type representations are missing for some types and promoted > constructors > > * #11334: Solving for Typeable (Proxy :: Proxy 'Compose) fails > > * #11276: Pattern checker performance can degrade significantly in > presence of pattern matches with guards > > * #11405: Type-level skolem-escape check fails incorrectly > > * #11414: Use of -XStrict results in compiler abort > > * #11379: Instance solver fails to terminate > > * #11419: Haddock documentation is currently not included in the binary > distributions (and hence is missing on downloads.haskell.org) > > * #11370: -Wredundant-constraints being included in -Wall breaks > the three-release compatibility policy > > In the coming weeks we will continue to iterate on these issues. We will > also look at Trac tickets marked with "highest" priority on the release > status page [2]. > > If you have a ticket that you would like to see addressed that does not > meet one of these criteria, please bring this to our attention. > Likewise, if you encounter an issue please open a ticket if one does not > already exist. > > Also note that we currently cannot offer 32-bit Windows builds due to > breaking changing in a recent Windows 10 upgrade. We'll work to > resolve this before the 8.0 release but please let us know if this poses > a significant problem for you. > > Cheers, > > - Ben > > > [1] https://cygwin.com/ml/cygwin/2015-12/msg00003.htm > [2] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1 > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.colpitts at gmail.com Thu Jan 14 00:45:10 2016 From: george.colpitts at gmail.com (George Colpitts) Date: Wed, 13 Jan 2016 20:45:10 -0400 Subject: [ANNOUNCE] Glasgow Haskell Compiler 8.0.1, release candidate 1 In-Reply-To: <87twmh5vtk.fsf@smart-cactus.org> References: <87twmh5vtk.fsf@smart-cactus.org> Message-ID: Building from src. Shouldn't INSTALL.md mention - j option for make ? On Wed, Jan 13, 2016 at 11:43 AM, Ben Gamari wrote: > > The GHC Team is very pleased to announce the first release candidate of > the Glasgow Haskell Compiler 8.0.1 release. Source and binary > distributions as well as the newly revised users guide can be found at > > http://downloads.haskell.org/~ghc/8.0.1-rc1/ > > This is the first in a series of release candidates which will allow us > to get wider testing of the significant changes that have occurred since > the 7.10 series. These include, > > * the TypeInType extension, which unifies types and kinds allowing for > promotion of more Haskell constructs to the type-level > > * the introduction of type application in source programs > > * support for recursive superclass relationships > > * support for Applicative do notation > > * introduction of the DuplicateRecordFields language extension > > * a rewritten and substantially more thorough pattern match checker > > * the introduction of injective type classes > > * introduction of the Strict and StrictData language extensions, > allowing modules to be compiled with strict-by-default evaluation > of bindings > > * the ability to run the GHCi interpreter in a separate process, > allowing a callstacks in GHCi, easier integration with tooling, and > more > > and much more. > > Changes of this magnitude will invariably bring bugs. This release > candidate in particular is known to suffer from a few significant issues > which are being actively worked upon, > > * The new -XInjectiveTypeFamilies language extension will likely be > renamed to -XTypeFamilyDependencies > > * #11120: Type representations are missing for some types and promoted > constructors > > * #11334: Solving for Typeable (Proxy :: Proxy 'Compose) fails > > * #11276: Pattern checker performance can degrade significantly in > presence of pattern matches with guards > > * #11405: Type-level skolem-escape check fails incorrectly > > * #11414: Use of -XStrict results in compiler abort > > * #11379: Instance solver fails to terminate > > * #11419: Haddock documentation is currently not included in the binary > distributions (and hence is missing on downloads.haskell.org) > > * #11370: -Wredundant-constraints being included in -Wall breaks > the three-release compatibility policy > > In the coming weeks we will continue to iterate on these issues. We will > also look at Trac tickets marked with "highest" priority on the release > status page [2]. > > If you have a ticket that you would like to see addressed that does not > meet one of these criteria, please bring this to our attention. > Likewise, if you encounter an issue please open a ticket if one does not > already exist. > > Also note that we currently cannot offer 32-bit Windows builds due to > breaking changing in a recent Windows 10 upgrade. We'll work to > resolve this before the 8.0 release but please let us know if this poses > a significant problem for you. > > Cheers, > > - Ben > > > [1] https://cygwin.com/ml/cygwin/2015-12/msg00003.htm > [2] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1 > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Thu Jan 14 01:06:32 2016 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 13 Jan 2016 20:06:32 -0500 Subject: [ANNOUNCE] Glasgow Haskell Compiler 8.0.1, release candidate 1 In-Reply-To: References: <87twmh5vtk.fsf@smart-cactus.org> Message-ID: I think 8.0 requires llvm 3.7 and only supports that version. Are we still planning to bundle opt and LLC in the final release ? On Wednesday, January 13, 2016, George Colpitts wrote: > Building from src on a Mac > Not sure why configure script couldn't figure out version of llvm I have: > > checking for llc-3.7... no > checking for llc... /usr/local/bin/llc > checking /usr/local/bin/llc is version 3.7... no > checking for opt-3.7... no > checking for opt... /usr/local/bin/opt > checking /usr/local/bin/opt is version 3.7... no > ./configure: line 7717: test: too many arguments > ./configure: line 7765: test: too many arguments > checking whether bootstrap compiler is affected by bug 9439... > : > Warning: Couldn't figure out LLVM version! > Make sure you have installed LLVM > ghc: could not execute: , ( > failed to compile > > > bash-3.2$ llc --version > LLVM (http://llvm.org/): > LLVM version 3.5.1 > Optimized build with assertions. > Built Jan 16 2015 (03:07:02). > Default target: x86_64-apple-darwin15.2.0 > Host CPU: corei7 > > Registered Targets: > x86 - 32-bit X86: Pentium-Pro and above > x86-64 - 64-bit X86: EM64T and AMD64 > bash-3.2$ opt --version > LLVM (http://llvm.org/): > LLVM version 3.5.1 > Optimized build with assertions. > Built Jan 16 2015 (03:07:02). > Default target: x86_64-apple-darwin15.2.0 > Host CPU: corei7 > > > > > On Wed, Jan 13, 2016 at 11:43 AM, Ben Gamari > wrote: > >> >> The GHC Team is very pleased to announce the first release candidate of >> the Glasgow Haskell Compiler 8.0.1 release. Source and binary >> distributions as well as the newly revised users guide can be found at >> >> http://downloads.haskell.org/~ghc/8.0.1-rc1/ >> >> This is the first in a series of release candidates which will allow us >> to get wider testing of the significant changes that have occurred since >> the 7.10 series. These include, >> >> * the TypeInType extension, which unifies types and kinds allowing for >> promotion of more Haskell constructs to the type-level >> >> * the introduction of type application in source programs >> >> * support for recursive superclass relationships >> >> * support for Applicative do notation >> >> * introduction of the DuplicateRecordFields language extension >> >> * a rewritten and substantially more thorough pattern match checker >> >> * the introduction of injective type classes >> >> * introduction of the Strict and StrictData language extensions, >> allowing modules to be compiled with strict-by-default evaluation >> of bindings >> >> * the ability to run the GHCi interpreter in a separate process, >> allowing a callstacks in GHCi, easier integration with tooling, and >> more >> >> and much more. >> >> Changes of this magnitude will invariably bring bugs. This release >> candidate in particular is known to suffer from a few significant issues >> which are being actively worked upon, >> >> * The new -XInjectiveTypeFamilies language extension will likely be >> renamed to -XTypeFamilyDependencies >> >> * #11120: Type representations are missing for some types and promoted >> constructors >> >> * #11334: Solving for Typeable (Proxy :: Proxy 'Compose) fails >> >> * #11276: Pattern checker performance can degrade significantly in >> presence of pattern matches with guards >> >> * #11405: Type-level skolem-escape check fails incorrectly >> >> * #11414: Use of -XStrict results in compiler abort >> >> * #11379: Instance solver fails to terminate >> >> * #11419: Haddock documentation is currently not included in the binary >> distributions (and hence is missing on downloads.haskell.org) >> >> * #11370: -Wredundant-constraints being included in -Wall breaks >> the three-release compatibility policy >> >> In the coming weeks we will continue to iterate on these issues. We will >> also look at Trac tickets marked with "highest" priority on the release >> status page [2]. >> >> If you have a ticket that you would like to see addressed that does not >> meet one of these criteria, please bring this to our attention. >> Likewise, if you encounter an issue please open a ticket if one does not >> already exist. >> >> Also note that we currently cannot offer 32-bit Windows builds due to >> breaking changing in a recent Windows 10 upgrade. We'll work to >> resolve this before the 8.0 release but please let us know if this poses >> a significant problem for you. >> >> Cheers, >> >> - Ben >> >> >> [1] https://cygwin.com/ml/cygwin/2015-12/msg00003.htm >> [2] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1 >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Thu Jan 14 09:25:16 2016 From: ben at well-typed.com (Ben Gamari) Date: Thu, 14 Jan 2016 10:25:16 +0100 Subject: [ANNOUNCE] Glasgow Haskell Compiler 8.0.1, release candidate 1 In-Reply-To: References: <87twmh5vtk.fsf@smart-cactus.org> Message-ID: <87mvs84io3.fsf@smart-cactus.org> George Colpitts writes: > Building from src. > > Shouldn't INSTALL.md mention - j option for make ? > This is pretty standard but it wouldn't hurt to mention it. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From ben at well-typed.com Thu Jan 14 09:26:37 2016 From: ben at well-typed.com (Ben Gamari) Date: Thu, 14 Jan 2016 10:26:37 +0100 Subject: [ANNOUNCE] Glasgow Haskell Compiler 8.0.1, release candidate 1 In-Reply-To: References: <87twmh5vtk.fsf@smart-cactus.org> Message-ID: <87k2nc4ilu.fsf@smart-cactus.org> Carter Schonwald writes: > I think 8.0 requires llvm 3.7 and only supports that version. Are we still > planning to bundle opt and LLC in the final release ? > Possibly. The logistics of this still need to be worked out. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From mail at nh2.me Thu Jan 14 11:01:56 2016 From: mail at nh2.me (=?UTF-8?Q?Niklas_Hamb=c3=bcchen?=) Date: Thu, 14 Jan 2016 12:01:56 +0100 Subject: [ANNOUNCE] Glasgow Haskell Compiler 8.0.1, release candidate 1 In-Reply-To: <87twmh5vtk.fsf@smart-cactus.org> References: <87twmh5vtk.fsf@smart-cactus.org> Message-ID: <56978024.7060304@nh2.me> On 13/01/16 16:43, Ben Gamari wrote: > If you have a ticket that you would like to see addressed that does > not meet one of these criteria, please bring this to our > attention. I would like to nominate https://ghc.haskell.org/trac/ghc/ticket/11172, the run-time segfault bug I found when using TH with -O, because it currently forces us to do some production builds with -O0. Happy to provide more input/testing in the ticket if needed. From thomasmiedema at gmail.com Thu Jan 14 11:11:40 2016 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Thu, 14 Jan 2016 12:11:40 +0100 Subject: [ANNOUNCE] Glasgow Haskell Compiler 8.0.1, release candidate 1 In-Reply-To: <56978024.7060304@nh2.me> References: <87twmh5vtk.fsf@smart-cactus.org> <56978024.7060304@nh2.me> Message-ID: On Thu, Jan 14, 2016 at 12:01 PM, Niklas Hamb?chen wrote: > I would like to nominate > https://ghc.haskell.org/trac/ghc/ticket/11172, the run-time segfault > bug I found when using TH with -O, because it currently forces us to > do some production builds with -O0. > You should be able to use `-O -fno-cse` (at least that worked last time I checked). -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Thu Jan 14 11:24:02 2016 From: ben at well-typed.com (Ben Gamari) Date: Thu, 14 Jan 2016 12:24:02 +0100 Subject: [ANNOUNCE] Glasgow Haskell Compiler 8.0.1, release candidate 1 In-Reply-To: <56978024.7060304@nh2.me> References: <87twmh5vtk.fsf@smart-cactus.org> <56978024.7060304@nh2.me> Message-ID: <8760yw4d65.fsf@smart-cactus.org> Niklas Hamb?chen writes: > On 13/01/16 16:43, Ben Gamari wrote: >> If you have a ticket that you would like to see addressed that does >> not meet one of these criteria, please bring this to our >> attention. > > I would like to nominate > https://ghc.haskell.org/trac/ghc/ticket/11172, the run-time segfault > bug I found when using TH with -O, because it currently forces us to > do some production builds with -O0. > Indeed this should be fixed. Thanks! Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From hvriedel at gmail.com Thu Jan 14 12:52:17 2016 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Thu, 14 Jan 2016 13:52:17 +0100 Subject: GHC 8.0 Migration Guide & Ubuntu GHC8/cabal packages (was: [ANNOUNCE] Glasgow Haskell Compiler 8.0.1, release candidate 1) In-Reply-To: <87twmh5vtk.fsf@smart-cactus.org> (Ben Gamari's message of "Wed, 13 Jan 2016 16:43:35 +0100") References: <87twmh5vtk.fsf@smart-cactus.org> Message-ID: <8760yw4932.fsf@gmail.com> On 2016-01-13 at 16:43:35 +0100, Ben Gamari wrote: > The GHC Team is very pleased to announce the first release candidate of > the Glasgow Haskell Compiler 8.0.1 release. Source and binary > distributions as well as the newly revised users guide can be found at > > http://downloads.haskell.org/~ghc/8.0.1-rc1/ > > This is the first in a series of release candidates which will allow us > to get wider testing of the significant changes that have occurred since > the 7.10 series. [...] As this wasn't explicitly mentioned in the announce, I'd like to point your attention to https://ghc.haskell.org/trac/ghc/wiki/Migration/8.0 which would benefit greatly from early adopters. More importantly, this helps us all to reduce the boring & redundant investigative work of rediscovering the same migration techniques by multiple parties over and over again... :-) ---- I'd also like to remind you that (more or less) daily snapshots of GHC 8.0.1 for Ubuntu {Precise,Trusty,Vivid,Wily} are already available via https://github.com/hvr/multi-ghc-travis This also includes a "cabal-install-1.24" package (which currently contains the current latest devel snapshots of cabal-install soon to become version 1.24) This specifically allows you to integrate GHC 8.0.1 & cabal-install 1.24 into your test-matrices in the `travis.yml` files, and thereby help detect GHC 8.0 & Cabal 1.2[34] issues early on. The new packages have been whitelisted for containerised Travis jobs already. Cheers, hvr From pali.gabor at gmail.com Thu Jan 14 15:09:44 2016 From: pali.gabor at gmail.com (=?UTF-8?B?UMOhbGkgR8OhYm9yIErDoW5vcw==?=) Date: Thu, 14 Jan 2016 16:09:44 +0100 Subject: [ANNOUNCE] Glasgow Haskell Compiler 8.0.1, release candidate 1 In-Reply-To: <87twmh5vtk.fsf@smart-cactus.org> References: <87twmh5vtk.fsf@smart-cactus.org> Message-ID: Hello there, 2016-01-13 16:43 GMT+01:00 Ben Gamari : > The GHC Team is very pleased to announce the first release candidate of > the Glasgow Haskell Compiler 8.0.1 release. For the FreeBSD users, I have built the vanilla binary distributions. They are available here, along with a brief installation guide: http://haskell.inf.elte.hu/ghc/8.0.0.20160111/ Cheers, G?bor From george.colpitts at gmail.com Thu Jan 14 15:35:36 2016 From: george.colpitts at gmail.com (George Colpitts) Date: Thu, 14 Jan 2016 11:35:36 -0400 Subject: [ANNOUNCE] Glasgow Haskell Compiler 8.0.1, release candidate 1 In-Reply-To: References: <87twmh5vtk.fsf@smart-cactus.org> Message-ID: That error is only on the binary distribution, building from source works fine On Wed, Jan 13, 2016 at 4:28 PM, George Colpitts wrote: > installs fine on mac but cabal install vector fails on primitive, looks to > me like gmp library is not provided > > cabal install vector > Resolving dependencies... > Configuring primitive-0.6.1.0... > Failed to install primitive-0.6.1.0 > Build log ( /Users/gcolpitts/.cabal/logs/primitive-0.6.1.0.log ): > cabal: Error: some packages failed to install: > primitive-0.6.1.0 failed during the configure step. The exception was: > user error ('/usr/local/bin/ghc' exited with an error: > *ld: library not found for -lgmp* > collect2: error: ld returned 1 exit status > `gcc' failed in phase `Linker'. (Exit code: 1) > ) > vector-0.11.0.0 depends on primitive-0.6.1.0 which failed to install. > > > On Wed, Jan 13, 2016 at 11:43 AM, Ben Gamari wrote: > >> >> The GHC Team is very pleased to announce the first release candidate of >> the Glasgow Haskell Compiler 8.0.1 release. Source and binary >> distributions as well as the newly revised users guide can be found at >> >> http://downloads.haskell.org/~ghc/8.0.1-rc1/ >> >> This is the first in a series of release candidates which will allow us >> to get wider testing of the significant changes that have occurred since >> the 7.10 series. These include, >> >> * the TypeInType extension, which unifies types and kinds allowing for >> promotion of more Haskell constructs to the type-level >> >> * the introduction of type application in source programs >> >> * support for recursive superclass relationships >> >> * support for Applicative do notation >> >> * introduction of the DuplicateRecordFields language extension >> >> * a rewritten and substantially more thorough pattern match checker >> >> * the introduction of injective type classes >> >> * introduction of the Strict and StrictData language extensions, >> allowing modules to be compiled with strict-by-default evaluation >> of bindings >> >> * the ability to run the GHCi interpreter in a separate process, >> allowing a callstacks in GHCi, easier integration with tooling, and >> more >> >> and much more. >> >> Changes of this magnitude will invariably bring bugs. This release >> candidate in particular is known to suffer from a few significant issues >> which are being actively worked upon, >> >> * The new -XInjectiveTypeFamilies language extension will likely be >> renamed to -XTypeFamilyDependencies >> >> * #11120: Type representations are missing for some types and promoted >> constructors >> >> * #11334: Solving for Typeable (Proxy :: Proxy 'Compose) fails >> >> * #11276: Pattern checker performance can degrade significantly in >> presence of pattern matches with guards >> >> * #11405: Type-level skolem-escape check fails incorrectly >> >> * #11414: Use of -XStrict results in compiler abort >> >> * #11379: Instance solver fails to terminate >> >> * #11419: Haddock documentation is currently not included in the binary >> distributions (and hence is missing on downloads.haskell.org) >> >> * #11370: -Wredundant-constraints being included in -Wall breaks >> the three-release compatibility policy >> >> In the coming weeks we will continue to iterate on these issues. We will >> also look at Trac tickets marked with "highest" priority on the release >> status page [2]. >> >> If you have a ticket that you would like to see addressed that does not >> meet one of these criteria, please bring this to our attention. >> Likewise, if you encounter an issue please open a ticket if one does not >> already exist. >> >> Also note that we currently cannot offer 32-bit Windows builds due to >> breaking changing in a recent Windows 10 upgrade. We'll work to >> resolve this before the 8.0 release but please let us know if this poses >> a significant problem for you. >> >> Cheers, >> >> - Ben >> >> >> [1] https://cygwin.com/ml/cygwin/2015-12/msg00003.htm >> [2] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1 >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Thu Jan 14 15:50:56 2016 From: ben at well-typed.com (Ben Gamari) Date: Thu, 14 Jan 2016 16:50:56 +0100 Subject: [ANNOUNCE] Glasgow Haskell Compiler 8.0.1, release candidate 1 In-Reply-To: References: <87twmh5vtk.fsf@smart-cactus.org> Message-ID: <87y4bs2m8v.fsf@smart-cactus.org> George Colpitts writes: > That error is only on the binary distribution, building from source works > fine > Great! Let me know if you find any other issues. Thanks George. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From karel.gardas at centrum.cz Thu Jan 14 21:27:38 2016 From: karel.gardas at centrum.cz (Karel Gardas) Date: Thu, 14 Jan 2016 22:27:38 +0100 Subject: [ANNOUNCE] Glasgow Haskell Compiler 8.0.1, release candidate 1 In-Reply-To: <87twmh5vtk.fsf@smart-cactus.org> References: <87twmh5vtk.fsf@smart-cactus.org> Message-ID: <569812CA.7070708@centrum.cz> Hi, I've build two builds for Solaris 11.2: i386: https://app.box.com/s/1m75kzunzsz6bqh77py5517t39734446 amd64: https://app.box.com/s/y583zs1tqduz8lbppt66z1qlxms0vytg Both binary distributions support shared libraries and use system provided GMP library. If you do not have it installed then you should do that using "pkg install library/gmp" command. and one build for OpenBSD 5.9 (current): amd64: https://app.box.com/s/95lpdhoc5h0zs0mx3chlacdl3hskzkqi This binary distribution also supports shared libraries and by default also OpenBSD position independent executables (PIE). It requires gmp, libffi and libiconv to be installed by "pkg_add " command. SPARC build for Solaris 11.2 is ongoing. Karel On 01/13/16 04:43 PM, Ben Gamari wrote: > > The GHC Team is very pleased to announce the first release candidate of > the Glasgow Haskell Compiler 8.0.1 release. Source and binary > distributions as well as the newly revised users guide can be found at > > http://downloads.haskell.org/~ghc/8.0.1-rc1/ > > This is the first in a series of release candidates which will allow us > to get wider testing of the significant changes that have occurred since > the 7.10 series. These include, > > * the TypeInType extension, which unifies types and kinds allowing for > promotion of more Haskell constructs to the type-level > > * the introduction of type application in source programs > > * support for recursive superclass relationships > > * support for Applicative do notation > > * introduction of the DuplicateRecordFields language extension > > * a rewritten and substantially more thorough pattern match checker > > * the introduction of injective type classes > > * introduction of the Strict and StrictData language extensions, > allowing modules to be compiled with strict-by-default evaluation > of bindings > > * the ability to run the GHCi interpreter in a separate process, > allowing a callstacks in GHCi, easier integration with tooling, and > more > > and much more. > > Changes of this magnitude will invariably bring bugs. This release > candidate in particular is known to suffer from a few significant issues > which are being actively worked upon, > > * The new -XInjectiveTypeFamilies language extension will likely be > renamed to -XTypeFamilyDependencies > > * #11120: Type representations are missing for some types and promoted > constructors > > * #11334: Solving for Typeable (Proxy :: Proxy 'Compose) fails > > * #11276: Pattern checker performance can degrade significantly in > presence of pattern matches with guards > > * #11405: Type-level skolem-escape check fails incorrectly > > * #11414: Use of -XStrict results in compiler abort > > * #11379: Instance solver fails to terminate > > * #11419: Haddock documentation is currently not included in the binary > distributions (and hence is missing on downloads.haskell.org) > > * #11370: -Wredundant-constraints being included in -Wall breaks > the three-release compatibility policy > > In the coming weeks we will continue to iterate on these issues. We will > also look at Trac tickets marked with "highest" priority on the release > status page [2]. > > If you have a ticket that you would like to see addressed that does not > meet one of these criteria, please bring this to our attention. > Likewise, if you encounter an issue please open a ticket if one does not > already exist. > > Also note that we currently cannot offer 32-bit Windows builds due to > breaking changing in a recent Windows 10 upgrade. We'll work to > resolve this before the 8.0 release but please let us know if this poses > a significant problem for you. > > Cheers, > > - Ben > > > [1] https://cygwin.com/ml/cygwin/2015-12/msg00003.htm > [2] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1 > > > > _______________________________________________ > 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 Thu Jan 14 21:29:59 2016 From: karel.gardas at centrum.cz (Karel Gardas) Date: Thu, 14 Jan 2016 22:29:59 +0100 Subject: [ANNOUNCE] Glasgow Haskell Compiler 8.0.1, release candidate 1 In-Reply-To: <569812CA.7070708@centrum.cz> References: <87twmh5vtk.fsf@smart-cactus.org> <569812CA.7070708@centrum.cz> Message-ID: <56981357.3050706@centrum.cz> SHA256SUM: https://app.box.com/s/0t3kutu8i3xhhs1vh97x6vcmjdnvlm78 Sorry for noise, Karel On 01/14/16 10:27 PM, Karel Gardas wrote: > > Hi, > > I've build two builds for Solaris 11.2: > > i386: https://app.box.com/s/1m75kzunzsz6bqh77py5517t39734446 > amd64: https://app.box.com/s/y583zs1tqduz8lbppt66z1qlxms0vytg > > Both binary distributions support shared libraries and use system > provided GMP library. If you do not have it installed then you should do > that using "pkg install library/gmp" command. > > > and one build for OpenBSD 5.9 (current): > > amd64: https://app.box.com/s/95lpdhoc5h0zs0mx3chlacdl3hskzkqi > > This binary distribution also supports shared libraries and by default > also OpenBSD position independent executables (PIE). It requires gmp, > libffi and libiconv to be installed by "pkg_add " command. > > > SPARC build for Solaris 11.2 is ongoing. > > Karel > > > On 01/13/16 04:43 PM, Ben Gamari wrote: >> >> The GHC Team is very pleased to announce the first release candidate of >> the Glasgow Haskell Compiler 8.0.1 release. Source and binary >> distributions as well as the newly revised users guide can be found at >> >> http://downloads.haskell.org/~ghc/8.0.1-rc1/ >> >> This is the first in a series of release candidates which will allow us >> to get wider testing of the significant changes that have occurred since >> the 7.10 series. These include, >> >> * the TypeInType extension, which unifies types and kinds allowing for >> promotion of more Haskell constructs to the type-level >> >> * the introduction of type application in source programs >> >> * support for recursive superclass relationships >> >> * support for Applicative do notation >> >> * introduction of the DuplicateRecordFields language extension >> >> * a rewritten and substantially more thorough pattern match checker >> >> * the introduction of injective type classes >> >> * introduction of the Strict and StrictData language extensions, >> allowing modules to be compiled with strict-by-default evaluation >> of bindings >> >> * the ability to run the GHCi interpreter in a separate process, >> allowing a callstacks in GHCi, easier integration with tooling, and >> more >> >> and much more. >> >> Changes of this magnitude will invariably bring bugs. This release >> candidate in particular is known to suffer from a few significant issues >> which are being actively worked upon, >> >> * The new -XInjectiveTypeFamilies language extension will likely be >> renamed to -XTypeFamilyDependencies >> >> * #11120: Type representations are missing for some types and promoted >> constructors >> >> * #11334: Solving for Typeable (Proxy :: Proxy 'Compose) fails >> >> * #11276: Pattern checker performance can degrade significantly in >> presence of pattern matches with guards >> >> * #11405: Type-level skolem-escape check fails incorrectly >> >> * #11414: Use of -XStrict results in compiler abort >> >> * #11379: Instance solver fails to terminate >> >> * #11419: Haddock documentation is currently not included in the binary >> distributions (and hence is missing on downloads.haskell.org) >> >> * #11370: -Wredundant-constraints being included in -Wall breaks >> the three-release compatibility policy >> >> In the coming weeks we will continue to iterate on these issues. We will >> also look at Trac tickets marked with "highest" priority on the release >> status page [2]. >> >> If you have a ticket that you would like to see addressed that does not >> meet one of these criteria, please bring this to our attention. >> Likewise, if you encounter an issue please open a ticket if one does not >> already exist. >> >> Also note that we currently cannot offer 32-bit Windows builds due to >> breaking changing in a recent Windows 10 upgrade. We'll work to >> resolve this before the 8.0 release but please let us know if this poses >> a significant problem for you. >> >> Cheers, >> >> - Ben >> >> >> [1] https://cygwin.com/ml/cygwin/2015-12/msg00003.htm >> [2] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1 >> >> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From ben at well-typed.com Fri Jan 15 09:40:13 2016 From: ben at well-typed.com (Ben Gamari) Date: Fri, 15 Jan 2016 10:40:13 +0100 Subject: [ANNOUNCE] Glasgow Haskell Compiler 8.0.1, release candidate 1 In-Reply-To: <569812CA.7070708@centrum.cz> References: <87twmh5vtk.fsf@smart-cactus.org> <569812CA.7070708@centrum.cz> Message-ID: <87twmf2nb6.fsf@smart-cactus.org> Karel Gardas writes: > Hi, > > I've build two builds for Solaris 11.2: > > i386: https://app.box.com/s/1m75kzunzsz6bqh77py5517t39734446 > amd64: https://app.box.com/s/y583zs1tqduz8lbppt66z1qlxms0vytg > > Both binary distributions support shared libraries and use system > provided GMP library. If you do not have it installed then you should do > that using "pkg install library/gmp" command. > > > and one build for OpenBSD 5.9 (current): > > amd64: https://app.box.com/s/95lpdhoc5h0zs0mx3chlacdl3hskzkqi > > This binary distribution also supports shared libraries and by default > also OpenBSD position independent executables (PIE). It requires gmp, > libffi and libiconv to be installed by "pkg_add " command. > > > SPARC build for Solaris 11.2 is ongoing. > Thanks Karel, let me know when 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: From jan.bracker at googlemail.com Fri Jan 15 14:03:03 2016 From: jan.bracker at googlemail.com (Jan Bracker) Date: Fri, 15 Jan 2016 14:03:03 +0000 Subject: Explanation of a core-lint warning (Bad getNth) In-Reply-To: <1471396847564ce18df16cc6a3692ace@DB4PR30MB030.064d.mgd.msft.net> References: <1471396847564ce18df16cc6a3692ace@DB4PR30MB030.064d.mgd.msft.net> Message-ID: I have condensed a self-contained plugin and an example application that reproduces the error. You can find it here: https://github.com/jbracker/polymonad-plugin/tree/master/examples/core-error You just have to download the three files and run "cabal install" to reproduce the error. There is a high-level explanation of what is going on in [1]. The plugin [2] is still around 600 lines long, but I have added a lot of comments to make it comprehensible. I suppose the most interesting part is the production of evidence [3]. I have added checks to see if the evidence I produce contains the 'Nth' constructors the core-linter refers to [4,5], but the evidence produced does not contain them. So somehow the evidence triggers GHC to produce evidence that the core-linter warns about. I hope this is comprehensible and you can help me with what is going on. Best, Jan [1] https://github.com/jbracker/polymonad-plugin/blob/master/examples/core-error/Main.hs#L83 [2] https://github.com/jbracker/polymonad-plugin/blob/master/examples/core-error/MinimalPlugin.hs [3] https://github.com/jbracker/polymonad-plugin/blob/master/examples/core-error/MinimalPlugin.hs#L198 [4] https://github.com/jbracker/polymonad-plugin/blob/master/examples/core-error/MinimalPlugin.hs#L130 [5] https://github.com/jbracker/polymonad-plugin/blob/master/examples/core-error/MinimalPlugin.hs#L556 2015-11-20 9:57 GMT+00:00 Simon Peyton Jones : > I don?t know how to help either, because there?s no way to reproduce it. > Can you find a Haskell program that, when GHC compiles it, produces this > Lint error? Or does it require your plugin? If the latter, it?s hard to > know what your plugin might be doing? > > > > So I feel a bit stalled on how to help. > > > > Simon > > > > *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Richard > Eisenberg > *Sent:* 18 November 2015 17:14 > *To:* Jan Bracker > *Cc:* ghc-devs at haskell.org > *Subject:* Re: Explanation of a core-lint warning (Bad getNth) > > > > Ah yes. I looked too quickly. Note that there are two NthCo's listed. Its > the outermost that's the problem, which is deconstructing the Union. But > it's doing so to prove that '["thres" :-> Int] ~ '["thres" :-> Int] which > is rather easy to prove without NthCo. I'm not sure why GHC is doing this. > > > > Richard > > > > On Nov 18, 2015, at 12:11 PM, Jan Bracker > wrote: > > > > Hi Richard, > > > > No "Split" is a class and is defined here: > http://hackage.haskell.org/package/effect-monad-0.6.1/docs/Control-Effect-State.html#t:Split > > > "Union" is a type function (synonym that refers to a type function call): > http://hackage.haskell.org/package/effect-monad-0.6.1/docs/Control-Effect-Writer.html#t:Union > > > > > thank you for your quick reply! > > > > Best, > > Jan > > > > 2015-11-18 17:05 GMT+00:00 Richard Eisenberg : > > I took just a quick look at this. Is Split a type family? The NthCo > coercion form takes apart a composite equality into its pieces. For > example, if we know (Maybe a ~ Maybe b), then NthCo:0 will tell us that (a > ~ b). In your case, it looks like GHC is trying to deduce (Union '["thres" > :-> Int] []) ~ (Union '["thres" :-> Int] (Unit Reader)) from an equality of > two (Split ...) types. If Split is a type family, this deduction is > unsound. That may be what Core Lint is worried about. > > > > I'm not surprised that the executable would run with an error. But it > might not in the future. If -dcore-lint fails, it means that there is a > potential type safety issue in the Core code, and this should be taken > seriously. > > > > I hope this helps! > > Richard > > > > On Nov 18, 2015, at 11:35 AM, Jan Bracker > wrote: > > > > Hi, > > > > I am using the type checker plugin interface and I am trying to produce > some evidence for type class instances. During compilation of one of my > examples I get this core-lint error: > > > > *** Core Lint errors : in result of Simplifier *** > > : Warning: > > [RHS of ds_a6bY :: (Set '["thres" :-> Int], Set (Unit Reader))] > > Bad getNth: > > Nth:0 > > (Nth:2 > > (Sub (Sym (TFCo:R:Inv[]Readerfg[0] <'["thres" :-> Int]>_N > <'[]>_N)) > > ; (Inv > > _N <'["thres" :-> Int]>_N (Sym > TFCo:R:Unit[]Reader[0]))_R > > ; Sub > > (TFCo:R:Inv[]Readerfg[0] <'["thres" :-> Int]>_N Reader>_N))) > > Split '["thres" :-> Int] '[] (Union '["thres" :-> Int] '[]) > > Split > > '["thres" :-> Int] > > (Unit Reader) > > (Union '["thres" :-> Int] (Unit Reader)) > > > > I suppose "getNth" refers to the constructor "EvTupleSel" from "EvTerm", > "TcNthCo" from "TcCoercion" or to "NthCo" from "Coercion". But I never > produce evidence of the shape "getNth". My evidence production code can be > found at [1] and the only place where evidence of this shape can come > from is my "evaluateType" function [2] that calls "normaliseType" from the > GHC module "FamInstEnv". You can reproduce the error by checking out > commit 144525886ec107af6f1283b26b19f8125c980aa4 from [3] and running "make > effect-example" in the top directory of the repository (GHC 7.10 or better > is required and a sandbox is automatically created). > > > > The core-lint error does not seem to have any negative consequences when > ignored. The produced executable works fine. Can somebody explain why it > appears and maybe how I can fix it? > > > > Thank you! > > Jan > > > > [1] > https://github.com/jbracker/polymonad-plugin/blob/144525886ec107af6f1283b26b19f8125c980aa4/src/Control/Polymonad/Plugin/Evidence.hs#L177 > > [2] > https://github.com/jbracker/polymonad-plugin/blob/144525886ec107af6f1283b26b19f8125c980aa4/src/Control/Polymonad/Plugin/Evaluate.hs#L29 > > [3] https://github.com/jbracker/polymonad-plugin > > _______________________________________________ > 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: From simonpj at microsoft.com Fri Jan 15 14:15:38 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 15 Jan 2016 14:15:38 +0000 Subject: Explanation of a core-lint warning (Bad getNth) In-Reply-To: References: <1471396847564ce18df16cc6a3692ace@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <749bb96d33704e24ad626ca9920efce0@DB4PR30MB030.064d.mgd.msft.net> Maybe put this all on a ticket? Everyone: would someone like to dig into this? I?m so under water that I just can?t Simon From: Jan Bracker [mailto:jan.bracker at googlemail.com] Sent: 15 January 2016 14:03 To: Simon Peyton Jones Cc: Richard Eisenberg ; ghc-devs at haskell.org Subject: Re: Explanation of a core-lint warning (Bad getNth) I have condensed a self-contained plugin and an example application that reproduces the error. You can find it here: https://github.com/jbracker/polymonad-plugin/tree/master/examples/core-error You just have to download the three files and run "cabal install" to reproduce the error. There is a high-level explanation of what is going on in [1]. The plugin [2] is still around 600 lines long, but I have added a lot of comments to make it comprehensible. I suppose the most interesting part is the production of evidence [3]. I have added checks to see if the evidence I produce contains the 'Nth' constructors the core-linter refers to [4,5], but the evidence produced does not contain them. So somehow the evidence triggers GHC to produce evidence that the core-linter warns about. I hope this is comprehensible and you can help me with what is going on. Best, Jan [1] https://github.com/jbracker/polymonad-plugin/blob/master/examples/core-error/Main.hs#L83 [2] https://github.com/jbracker/polymonad-plugin/blob/master/examples/core-error/MinimalPlugin.hs [3] https://github.com/jbracker/polymonad-plugin/blob/master/examples/core-error/MinimalPlugin.hs#L198 [4] https://github.com/jbracker/polymonad-plugin/blob/master/examples/core-error/MinimalPlugin.hs#L130 [5] https://github.com/jbracker/polymonad-plugin/blob/master/examples/core-error/MinimalPlugin.hs#L556 2015-11-20 9:57 GMT+00:00 Simon Peyton Jones >: I don?t know how to help either, because there?s no way to reproduce it. Can you find a Haskell program that, when GHC compiles it, produces this Lint error? Or does it require your plugin? If the latter, it?s hard to know what your plugin might be doing? So I feel a bit stalled on how to help. Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Richard Eisenberg Sent: 18 November 2015 17:14 To: Jan Bracker Cc: ghc-devs at haskell.org Subject: Re: Explanation of a core-lint warning (Bad getNth) Ah yes. I looked too quickly. Note that there are two NthCo's listed. Its the outermost that's the problem, which is deconstructing the Union. But it's doing so to prove that '["thres" :-> Int] ~ '["thres" :-> Int] which is rather easy to prove without NthCo. I'm not sure why GHC is doing this. Richard On Nov 18, 2015, at 12:11 PM, Jan Bracker > wrote: Hi Richard, No "Split" is a class and is defined here: http://hackage.haskell.org/package/effect-monad-0.6.1/docs/Control-Effect-State.html#t:Split "Union" is a type function (synonym that refers to a type function call): http://hackage.haskell.org/package/effect-monad-0.6.1/docs/Control-Effect-Writer.html#t:Union thank you for your quick reply! Best, Jan 2015-11-18 17:05 GMT+00:00 Richard Eisenberg >: I took just a quick look at this. Is Split a type family? The NthCo coercion form takes apart a composite equality into its pieces. For example, if we know (Maybe a ~ Maybe b), then NthCo:0 will tell us that (a ~ b). In your case, it looks like GHC is trying to deduce (Union '["thres" :-> Int] []) ~ (Union '["thres" :-> Int] (Unit Reader)) from an equality of two (Split ...) types. If Split is a type family, this deduction is unsound. That may be what Core Lint is worried about. I'm not surprised that the executable would run with an error. But it might not in the future. If -dcore-lint fails, it means that there is a potential type safety issue in the Core code, and this should be taken seriously. I hope this helps! Richard On Nov 18, 2015, at 11:35 AM, Jan Bracker > wrote: Hi, I am using the type checker plugin interface and I am trying to produce some evidence for type class instances. During compilation of one of my examples I get this core-lint error: *** Core Lint errors : in result of Simplifier *** : Warning: [RHS of ds_a6bY :: (Set '["thres" :-> Int], Set (Unit Reader))] Bad getNth: Nth:0 (Nth:2 (Sub (Sym (TFCo:R:Inv[]Readerfg[0] <'["thres" :-> Int]>_N <'[]>_N)) ; (Inv _N <'["thres" :-> Int]>_N (Sym TFCo:R:Unit[]Reader[0]))_R ; Sub (TFCo:R:Inv[]Readerfg[0] <'["thres" :-> Int]>_N _N))) Split '["thres" :-> Int] '[] (Union '["thres" :-> Int] '[]) Split '["thres" :-> Int] (Unit Reader) (Union '["thres" :-> Int] (Unit Reader)) I suppose "getNth" refers to the constructor "EvTupleSel" from "EvTerm", "TcNthCo" from "TcCoercion" or to "NthCo" from "Coercion". But I never produce evidence of the shape "getNth". My evidence production code can be found at [1] and the only place where evidence of this shape can come from is my "evaluateType" function [2] that calls "normaliseType" from the GHC module "FamInstEnv". You can reproduce the error by checking out commit 144525886ec107af6f1283b26b19f8125c980aa4 from [3] and running "make effect-example" in the top directory of the repository (GHC 7.10 or better is required and a sandbox is automatically created). The core-lint error does not seem to have any negative consequences when ignored. The produced executable works fine. Can somebody explain why it appears and maybe how I can fix it? Thank you! Jan [1] https://github.com/jbracker/polymonad-plugin/blob/144525886ec107af6f1283b26b19f8125c980aa4/src/Control/Polymonad/Plugin/Evidence.hs#L177 [2] https://github.com/jbracker/polymonad-plugin/blob/144525886ec107af6f1283b26b19f8125c980aa4/src/Control/Polymonad/Plugin/Evaluate.hs#L29 [3] https://github.com/jbracker/polymonad-plugin _______________________________________________ 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: From karel.gardas at centrum.cz Fri Jan 15 14:15:44 2016 From: karel.gardas at centrum.cz (Karel Gardas) Date: Fri, 15 Jan 2016 15:15:44 +0100 Subject: [ANNOUNCE] Glasgow Haskell Compiler 8.0.1, release candidate 1 In-Reply-To: <569812CA.7070708@centrum.cz> References: <87twmh5vtk.fsf@smart-cactus.org> <569812CA.7070708@centrum.cz> Message-ID: <5698FF10.7080508@centrum.cz> Hi, SPARC/Solaris 11.2 build: https://app.box.com/s/lktjbjtnqv39pil4pkkni4xpn5mi2053 Its signature: https://app.box.com/s/catr69sepivx5xb0g5totl2y6hwrznpj Signatures of already sent files: i386/solaris: https://app.box.com/s/it4pih3bi6bq02mfqmnnae13sk7gebb4 amd64/solaris: https://app.box.com/s/okvd7dq3g1jhznkmlf4coug51f83724t amd64/openbsd: https://app.box.com/s/xa4u80t8htmmqotxwcmdj25soxddgrxb SHA256SUM: https://app.box.com/s/86ipjn3z3wwzbcpwos8e80qcivn6fnhv Updated SHA256SUM file: https://app.box.com/s/0t3kutu8i3xhhs1vh97x6vcmjdnvlm78 Karel On 01/14/16 10:27 PM, Karel Gardas wrote: > > Hi, > > I've build two builds for Solaris 11.2: > > i386: https://app.box.com/s/1m75kzunzsz6bqh77py5517t39734446 > amd64: https://app.box.com/s/y583zs1tqduz8lbppt66z1qlxms0vytg > > Both binary distributions support shared libraries and use system > provided GMP library. If you do not have it installed then you should do > that using "pkg install library/gmp" command. > > > and one build for OpenBSD 5.9 (current): > > amd64: https://app.box.com/s/95lpdhoc5h0zs0mx3chlacdl3hskzkqi > > This binary distribution also supports shared libraries and by default > also OpenBSD position independent executables (PIE). It requires gmp, > libffi and libiconv to be installed by "pkg_add " command. > > > SPARC build for Solaris 11.2 is ongoing. > > Karel > > > On 01/13/16 04:43 PM, Ben Gamari wrote: >> >> The GHC Team is very pleased to announce the first release candidate of >> the Glasgow Haskell Compiler 8.0.1 release. Source and binary >> distributions as well as the newly revised users guide can be found at >> >> http://downloads.haskell.org/~ghc/8.0.1-rc1/ >> >> This is the first in a series of release candidates which will allow us >> to get wider testing of the significant changes that have occurred since >> the 7.10 series. These include, >> >> * the TypeInType extension, which unifies types and kinds allowing for >> promotion of more Haskell constructs to the type-level >> >> * the introduction of type application in source programs >> >> * support for recursive superclass relationships >> >> * support for Applicative do notation >> >> * introduction of the DuplicateRecordFields language extension >> >> * a rewritten and substantially more thorough pattern match checker >> >> * the introduction of injective type classes >> >> * introduction of the Strict and StrictData language extensions, >> allowing modules to be compiled with strict-by-default evaluation >> of bindings >> >> * the ability to run the GHCi interpreter in a separate process, >> allowing a callstacks in GHCi, easier integration with tooling, and >> more >> >> and much more. >> >> Changes of this magnitude will invariably bring bugs. This release >> candidate in particular is known to suffer from a few significant issues >> which are being actively worked upon, >> >> * The new -XInjectiveTypeFamilies language extension will likely be >> renamed to -XTypeFamilyDependencies >> >> * #11120: Type representations are missing for some types and promoted >> constructors >> >> * #11334: Solving for Typeable (Proxy :: Proxy 'Compose) fails >> >> * #11276: Pattern checker performance can degrade significantly in >> presence of pattern matches with guards >> >> * #11405: Type-level skolem-escape check fails incorrectly >> >> * #11414: Use of -XStrict results in compiler abort >> >> * #11379: Instance solver fails to terminate >> >> * #11419: Haddock documentation is currently not included in the binary >> distributions (and hence is missing on downloads.haskell.org) >> >> * #11370: -Wredundant-constraints being included in -Wall breaks >> the three-release compatibility policy >> >> In the coming weeks we will continue to iterate on these issues. We will >> also look at Trac tickets marked with "highest" priority on the release >> status page [2]. >> >> If you have a ticket that you would like to see addressed that does not >> meet one of these criteria, please bring this to our attention. >> Likewise, if you encounter an issue please open a ticket if one does not >> already exist. >> >> Also note that we currently cannot offer 32-bit Windows builds due to >> breaking changing in a recent Windows 10 upgrade. We'll work to >> resolve this before the 8.0 release but please let us know if this poses >> a significant problem for you. >> >> Cheers, >> >> - Ben >> >> >> [1] https://cygwin.com/ml/cygwin/2015-12/msg00003.htm >> [2] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1 >> >> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From jan.bracker at googlemail.com Fri Jan 15 14:49:51 2016 From: jan.bracker at googlemail.com (Jan Bracker) Date: Fri, 15 Jan 2016 14:49:51 +0000 Subject: Explanation of a core-lint warning (Bad getNth) In-Reply-To: <749bb96d33704e24ad626ca9920efce0@DB4PR30MB030.064d.mgd.msft.net> References: <1471396847564ce18df16cc6a3692ace@DB4PR30MB030.064d.mgd.msft.net> <749bb96d33704e24ad626ca9920efce0@DB4PR30MB030.064d.mgd.msft.net> Message-ID: I have created Ticket #11435. I am still not sure if I am producing incorrect evidence or if there really is an issue with GHC, but I would expect GHC to tell me if the evidence I produced does not make sense. [1] https://ghc.haskell.org/trac/ghc/ticket/11435 2016-01-15 14:15 GMT+00:00 Simon Peyton Jones : > Maybe put this all on a ticket? > > > > Everyone: would someone like to dig into this? I?m so under water that I > just can?t > > > > Simon > > > > *From:* Jan Bracker [mailto:jan.bracker at googlemail.com] > *Sent:* 15 January 2016 14:03 > *To:* Simon Peyton Jones > *Cc:* Richard Eisenberg ; ghc-devs at haskell.org > > *Subject:* Re: Explanation of a core-lint warning (Bad getNth) > > > > I have condensed a self-contained plugin and an example application that > reproduces the error. You can find it here: > > > https://github.com/jbracker/polymonad-plugin/tree/master/examples/core-error > > > > You just have to download the three files and run "cabal install" to > reproduce the error. There is a high-level explanation of > > what is going on in [1]. The plugin [2] is still around 600 lines long, > but I have added a lot of comments to make it comprehensible. > > I suppose the most interesting part is the production of evidence [3]. I > have added checks to see if the evidence I produce contains the 'Nth' > constructors the core-linter refers to [4,5], but the evidence produced > does not contain them. So somehow the evidence triggers GHC to produce > evidence that the core-linter warns about. > > > > I hope this is comprehensible and you can help me with what is going on. > > > > Best, > > Jan > > > > [1] > https://github.com/jbracker/polymonad-plugin/blob/master/examples/core-error/Main.hs#L83 > > [2] > https://github.com/jbracker/polymonad-plugin/blob/master/examples/core-error/MinimalPlugin.hs > > [3] > https://github.com/jbracker/polymonad-plugin/blob/master/examples/core-error/MinimalPlugin.hs#L198 > > [4] > https://github.com/jbracker/polymonad-plugin/blob/master/examples/core-error/MinimalPlugin.hs#L130 > > [5] > https://github.com/jbracker/polymonad-plugin/blob/master/examples/core-error/MinimalPlugin.hs#L556 > > > > 2015-11-20 9:57 GMT+00:00 Simon Peyton Jones : > > I don?t know how to help either, because there?s no way to reproduce it. > Can you find a Haskell program that, when GHC compiles it, produces this > Lint error? Or does it require your plugin? If the latter, it?s hard to > know what your plugin might be doing? > > > > So I feel a bit stalled on how to help. > > > > Simon > > > > *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Richard > Eisenberg > *Sent:* 18 November 2015 17:14 > *To:* Jan Bracker > *Cc:* ghc-devs at haskell.org > *Subject:* Re: Explanation of a core-lint warning (Bad getNth) > > > > Ah yes. I looked too quickly. Note that there are two NthCo's listed. Its > the outermost that's the problem, which is deconstructing the Union. But > it's doing so to prove that '["thres" :-> Int] ~ '["thres" :-> Int] which > is rather easy to prove without NthCo. I'm not sure why GHC is doing this. > > > > Richard > > > > On Nov 18, 2015, at 12:11 PM, Jan Bracker > wrote: > > > > Hi Richard, > > > > No "Split" is a class and is defined here: > http://hackage.haskell.org/package/effect-monad-0.6.1/docs/Control-Effect-State.html#t:Split > > > "Union" is a type function (synonym that refers to a type function call): > http://hackage.haskell.org/package/effect-monad-0.6.1/docs/Control-Effect-Writer.html#t:Union > > > > > thank you for your quick reply! > > > > Best, > > Jan > > > > 2015-11-18 17:05 GMT+00:00 Richard Eisenberg : > > I took just a quick look at this. Is Split a type family? The NthCo > coercion form takes apart a composite equality into its pieces. For > example, if we know (Maybe a ~ Maybe b), then NthCo:0 will tell us that (a > ~ b). In your case, it looks like GHC is trying to deduce (Union '["thres" > :-> Int] []) ~ (Union '["thres" :-> Int] (Unit Reader)) from an equality of > two (Split ...) types. If Split is a type family, this deduction is > unsound. That may be what Core Lint is worried about. > > > > I'm not surprised that the executable would run with an error. But it > might not in the future. If -dcore-lint fails, it means that there is a > potential type safety issue in the Core code, and this should be taken > seriously. > > > > I hope this helps! > > Richard > > > > On Nov 18, 2015, at 11:35 AM, Jan Bracker > wrote: > > > > Hi, > > > > I am using the type checker plugin interface and I am trying to produce > some evidence for type class instances. During compilation of one of my > examples I get this core-lint error: > > > > *** Core Lint errors : in result of Simplifier *** > > : Warning: > > [RHS of ds_a6bY :: (Set '["thres" :-> Int], Set (Unit Reader))] > > Bad getNth: > > Nth:0 > > (Nth:2 > > (Sub (Sym (TFCo:R:Inv[]Readerfg[0] <'["thres" :-> Int]>_N > <'[]>_N)) > > ; (Inv > > _N <'["thres" :-> Int]>_N (Sym > TFCo:R:Unit[]Reader[0]))_R > > ; Sub > > (TFCo:R:Inv[]Readerfg[0] <'["thres" :-> Int]>_N Reader>_N))) > > Split '["thres" :-> Int] '[] (Union '["thres" :-> Int] '[]) > > Split > > '["thres" :-> Int] > > (Unit Reader) > > (Union '["thres" :-> Int] (Unit Reader)) > > > > I suppose "getNth" refers to the constructor "EvTupleSel" from "EvTerm", > "TcNthCo" from "TcCoercion" or to "NthCo" from "Coercion". But I never > produce evidence of the shape "getNth". My evidence production code can be > found at [1] and the only place where evidence of this shape can come > from is my "evaluateType" function [2] that calls "normaliseType" from the > GHC module "FamInstEnv". You can reproduce the error by checking out > commit 144525886ec107af6f1283b26b19f8125c980aa4 from [3] and running "make > effect-example" in the top directory of the repository (GHC 7.10 or better > is required and a sandbox is automatically created). > > > > The core-lint error does not seem to have any negative consequences when > ignored. The produced executable works fine. Can somebody explain why it > appears and maybe how I can fix it? > > > > Thank you! > > Jan > > > > [1] > https://github.com/jbracker/polymonad-plugin/blob/144525886ec107af6f1283b26b19f8125c980aa4/src/Control/Polymonad/Plugin/Evidence.hs#L177 > > [2] > https://github.com/jbracker/polymonad-plugin/blob/144525886ec107af6f1283b26b19f8125c980aa4/src/Control/Polymonad/Plugin/Evaluate.hs#L29 > > [3] https://github.com/jbracker/polymonad-plugin > > _______________________________________________ > 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: From ben at well-typed.com Fri Jan 15 15:11:44 2016 From: ben at well-typed.com (Ben Gamari) Date: Fri, 15 Jan 2016 16:11:44 +0100 Subject: [ANNOUNCE] Glasgow Haskell Compiler 8.0.1, release candidate 1 In-Reply-To: References: <87twmh5vtk.fsf@smart-cactus.org> Message-ID: <87h9ie3mj3.fsf@smart-cactus.org> George Colpitts writes: > installs fine on mac but cabal install vector fails on primitive, looks to > me like gmp library is not provided > I have built a new OS X binary [1] which should be linked against the in-tree libgmp, fixing this issue (which we've been tracking as Trac #11423). I have also pushed a 32-bit Windows build. Perhaps those affected by this issue could try this distribution? Cheers, - Ben [1] http://downloads.haskell.org/~ghc/8.0.1-rc1/ghc-8.0.0b.20160111-x86_64-apple-darwin.tar.xz -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From jan.stolarek at p.lodz.pl Fri Jan 15 17:49:14 2016 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Fri, 15 Jan 2016 18:49:14 +0100 Subject: Phab failing to apply patches Message-ID: <201601151849.14883.jan.stolarek@p.lodz.pl> It seems that Phab is once again failing to apply patches (eg. D1778, which built perfectly fine until latest update). Is anyone else experiencing this? Janek --- Politechnika ??dzka Lodz University of Technology Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system. From thomasmiedema at gmail.com Fri Jan 15 18:02:03 2016 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Fri, 15 Jan 2016 19:02:03 +0100 Subject: Phab failing to apply patches In-Reply-To: <201601151849.14883.jan.stolarek@p.lodz.pl> References: <201601151849.14883.jan.stolarek@p.lodz.pl> Message-ID: "Unable to apply patch!" means just that. Harbormaster is unable to apply the patch (to master). You can test it yourself by running 'arc patch --nobranch D1778` on an up-to-date checkout of the master branch, and it will fail in the same way. Solution: rebase your patch onto master, and update the Diff. You'll notice there are indeed merge problems. On Fri, Jan 15, 2016 at 6:49 PM, Jan Stolarek wrote: > It seems that Phab is once again failing to apply patches (eg. D1778, > which built perfectly fine > until latest update). Is anyone else experiencing this? > > Janek > > --- > Politechnika ??dzka > Lodz University of Technology > > Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. > Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez > pomy?k? > prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. > > This email contains information intended solely for the use of the > individual to whom it is addressed. > If you are not the intended recipient or if you have received this message > in error, > please notify the sender and delete it from your system. > _______________________________________________ > 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: From jan.stolarek at p.lodz.pl Fri Jan 15 18:06:33 2016 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Fri, 15 Jan 2016 19:06:33 +0100 Subject: Phab failing to apply patches In-Reply-To: References: <201601151849.14883.jan.stolarek@p.lodz.pl> Message-ID: <201601151906.33939.jan.stolarek@p.lodz.pl> Somehow I always I believed that Harbormaster does not apply a patch onto master but onto the revision it was created from. Has there been any change in this behaviour recently? Janek Dnia pi?tek, 15 stycznia 2016, Thomas Miedema napisa?: > "Unable to apply patch!" means just that. Harbormaster is unable to apply > the patch (to master). You can test it yourself by running 'arc patch > --nobranch D1778` on an up-to-date checkout of the master branch, and it > will fail in the same way. > > Solution: rebase your patch onto master, and update the Diff. You'll notice > there are indeed merge problems. > > > On Fri, Jan 15, 2016 at 6:49 PM, Jan Stolarek > > wrote: > > It seems that Phab is once again failing to apply patches (eg. D1778, > > which built perfectly fine > > until latest update). Is anyone else experiencing this? > > > > Janek > > > > --- > > Politechnika ??dzka > > Lodz University of Technology > > > > Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. > > Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez > > pomy?k? > > prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. > > > > This email contains information intended solely for the use of the > > individual to whom it is addressed. > > If you are not the intended recipient or if you have received this > > message in error, > > please notify the sender and delete it from your system. > > _______________________________________________ > > 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 thomasmiedema at gmail.com Fri Jan 15 18:38:23 2016 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Fri, 15 Jan 2016 19:38:23 +0100 Subject: Phab failing to apply patches In-Reply-To: <201601151906.33939.jan.stolarek@p.lodz.pl> References: <201601151849.14883.jan.stolarek@p.lodz.pl> <201601151906.33939.jan.stolarek@p.lodz.pl> Message-ID: It changed some time last year. Before, Harbormaster would sometimes try to build some bizarro intermediate mix of base commit + patch + master. See https://ghc.haskell.org/trac/ghc/ticket/9855. On Fri, Jan 15, 2016 at 7:06 PM, Jan Stolarek wrote: > Somehow I always I believed that Harbormaster does not apply a patch onto > master but onto the > revision it was created from. Has there been any change in this behaviour > recently? > > Janek > > Dnia pi?tek, 15 stycznia 2016, Thomas Miedema napisa?: > > "Unable to apply patch!" means just that. Harbormaster is unable to apply > > the patch (to master). You can test it yourself by running 'arc patch > > --nobranch D1778` on an up-to-date checkout of the master branch, and it > > will fail in the same way. > > > > Solution: rebase your patch onto master, and update the Diff. You'll > notice > > there are indeed merge problems. > > > > > > On Fri, Jan 15, 2016 at 6:49 PM, Jan Stolarek > > > > wrote: > > > It seems that Phab is once again failing to apply patches (eg. D1778, > > > which built perfectly fine > > > until latest update). Is anyone else experiencing this? > > > > > > Janek > > > > > > --- > > > Politechnika ??dzka > > > Lodz University of Technology > > > > > > Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla > adresata. > > > Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez > > > pomy?k? > > > prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. > > > > > > This email contains information intended solely for the use of the > > > individual to whom it is addressed. > > > If you are not the intended recipient or if you have received this > > > message in error, > > > please notify the sender and delete it from your system. > > > _______________________________________________ > > > 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Fri Jan 15 18:47:35 2016 From: ben at well-typed.com (Ben Gamari) Date: Fri, 15 Jan 2016 19:47:35 +0100 Subject: [ANNOUNCE] Glasgow Haskell Compiler 8.0.1, release candidate 1 In-Reply-To: <5698FF10.7080508@centrum.cz> References: <87twmh5vtk.fsf@smart-cactus.org> <569812CA.7070708@centrum.cz> <5698FF10.7080508@centrum.cz> Message-ID: <87egdi3cjc.fsf@smart-cactus.org> Karel Gardas writes: > Hi, > Hi Karel, In the future do you suppose you could just tar these up and post the tarball? box.com is a bit annoying to download files from. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From thomasmiedema at gmail.com Fri Jan 15 22:30:04 2016 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Fri, 15 Jan 2016 23:30:04 +0100 Subject: Explanation of a core-lint warning (Bad getNth) In-Reply-To: References: <1471396847564ce18df16cc6a3692ace@DB4PR30MB030.064d.mgd.msft.net> Message-ID: On Fri, Jan 15, 2016 at 3:03 PM, Jan Bracker wrote: > You just have to download the three files and run "cabal install" to > reproduce the error. > It's never that easy, is it? Can you try in a cabal sandbox, with ghc-7.10.3. I'm getting: cabal: Could not resolve dependencies: trying: core-error-0.1 (user goal) next goal: base (dependency of core-error-0.1) rejecting: base-4.8.2.0/installed-0d6... (conflict: core-error => base==4.8.1.0) rejecting: base-4.8.1.0, base-4.8.0.0, base-4.7.0.2, base-4.7.0.1, base-4.7.0.0, base-4.6.0.1, base-4.6.0.0, base-4.5.1.0, base-4.5.0.0, base-4.4.1.0, base-4.4.0.0, base-4.3.1.0, base-4.3.0.0, base-4.2.0.2, base-4.2.0.1, base-4.2.0.0, base-4.1.0.0, base-4.0.0.0, base-3.0.3.2, base-3.0.3.1 (constraint from main config /home/thomas/.cabal/config requires installed instance) Dependency tree exhaustively searched. After relaxing the depenency on base (or is the problem only reproducible with base 4.8.1.0 that, in case we are done here), I get: Preprocessing library effect-monad-0.6.1... src/Control/Effect/State.hs:4:14: Warning: -XOverlappingInstances is deprecated: instead use per-instance pragmas OVERLAPPING/OVERLAPPABLE/OVERLAPS [ 1 of 17] Compiling Control.Effect.Helpers.List ( src/Control/Effect/Helpers/List.hs, dist/build/Control/Effect/Helpers/List.o ) [ 2 of 17] Compiling Control.Effect.Cond ( src/Control/Effect/Cond.hs, dist/build/Control/Effect/Cond.o ) [ 3 of 17] Compiling Control.Effect ( src/Control/Effect.hs, dist/build/Control/Effect.o ) [ 4 of 17] Compiling Control.Effect.Counter ( src/Control/Effect/Counter.hs, dist/build/Control/Effect/Counter.o ) [ 5 of 17] Compiling Control.Effect.CounterNat ( src/Control/Effect/CounterNat.hs, dist/build/Control/Effect/CounterNat.o ) [ 6 of 17] Compiling Control.Effect.Maybe ( src/Control/Effect/Maybe.hs, dist/build/Control/Effect/Maybe.o ) [ 7 of 17] Compiling Control.Effect.Monad ( src/Control/Effect/Monad.hs, dist/build/Control/Effect/Monad.o ) [ 8 of 17] Compiling Control.Effect.Parameterised ( src/Control/Effect/Parameterised.hs, dist/build/Control/Effect/Parameterised.o ) [ 9 of 17] Compiling Control.Effect.Reader ( src/Control/Effect/Reader.hs, dist/build/Control/Effect/Reader.o ) src/Control/Effect/Reader.hs:33:8: Not in scope: type constructor or class ?Var? src/Control/Effect/Reader.hs:33:28: Not in scope: type constructor or class ?:->? src/Control/Effect/Reader.hs:34:5: Not in scope: data constructor ?Var? src/Control/Effect/Reader.hs:34:24: Not in scope: data constructor ?Var? src/Control/Effect/Reader.hs:34:28: Not in scope: data constructor ?:->? Failed to install effect-monad-0.6.1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.bracker at googlemail.com Fri Jan 15 23:49:38 2016 From: jan.bracker at googlemail.com (Jan Bracker) Date: Fri, 15 Jan 2016 23:49:38 +0000 Subject: Explanation of a core-lint warning (Bad getNth) In-Reply-To: References: <1471396847564ce18df16cc6a3692ace@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Hard-coding the exact base version was a stupid mistake, sorry. I relaxed that and reattached a new version of the files to the ticket. It seems that 'effect-monad's dependency on 'type-level-sets' is a bit to liberal, because the module structure and exports of that package changed between versions. I hard-coded the correct version of 'type-level-set' into the cabal file of the example. I did not get this, because I share a sandbox between my main project and the examples (and its been around for some time now). Seems like 'effect-monad' is bitrotting a bit... I did not test these changes on 7.10.3, because I currently only have version 7.10.2 installed. 2016-01-15 22:30 GMT+00:00 Thomas Miedema : > > > On Fri, Jan 15, 2016 at 3:03 PM, Jan Bracker > wrote: > >> You just have to download the three files and run "cabal install" to >> reproduce the error. >> > > It's never that easy, is it? Can you try in a cabal sandbox, with > ghc-7.10.3. I'm getting: > > > > cabal: Could not resolve dependencies: > trying: core-error-0.1 (user goal) > next goal: base (dependency of core-error-0.1) > rejecting: base-4.8.2.0/installed-0d6... (conflict: core-error => > base==4.8.1.0) > rejecting: base-4.8.1.0, base-4.8.0.0, base-4.7.0.2, base-4.7.0.1, > base-4.7.0.0, base-4.6.0.1, base-4.6.0.0, base-4.5.1.0, base-4.5.0.0, > base-4.4.1.0, base-4.4.0.0, base-4.3.1.0, base-4.3.0.0, base-4.2.0.2, > base-4.2.0.1, base-4.2.0.0, base-4.1.0.0, base-4.0.0.0, base-3.0.3.2, > base-3.0.3.1 (constraint from main config /home/thomas/.cabal/config > requires > installed instance) > Dependency tree exhaustively searched. > > > > After relaxing the depenency on base (or is the problem only reproducible > with base 4.8.1.0 that, in case we are done here), I get: > > > > > > Preprocessing library effect-monad-0.6.1... > > src/Control/Effect/State.hs:4:14: Warning: > -XOverlappingInstances is deprecated: instead use per-instance pragmas > OVERLAPPING/OVERLAPPABLE/OVERLAPS > [ 1 of 17] Compiling Control.Effect.Helpers.List ( > src/Control/Effect/Helpers/List.hs, > dist/build/Control/Effect/Helpers/List.o ) > [ 2 of 17] Compiling Control.Effect.Cond ( src/Control/Effect/Cond.hs, > dist/build/Control/Effect/Cond.o ) > [ 3 of 17] Compiling Control.Effect ( src/Control/Effect.hs, > dist/build/Control/Effect.o ) > [ 4 of 17] Compiling Control.Effect.Counter ( > src/Control/Effect/Counter.hs, dist/build/Control/Effect/Counter.o ) > [ 5 of 17] Compiling Control.Effect.CounterNat ( > src/Control/Effect/CounterNat.hs, dist/build/Control/Effect/CounterNat.o ) > [ 6 of 17] Compiling Control.Effect.Maybe ( src/Control/Effect/Maybe.hs, > dist/build/Control/Effect/Maybe.o ) > [ 7 of 17] Compiling Control.Effect.Monad ( src/Control/Effect/Monad.hs, > dist/build/Control/Effect/Monad.o ) > [ 8 of 17] Compiling Control.Effect.Parameterised ( > src/Control/Effect/Parameterised.hs, > dist/build/Control/Effect/Parameterised.o ) > [ 9 of 17] Compiling Control.Effect.Reader ( src/Control/Effect/Reader.hs, > dist/build/Control/Effect/Reader.o ) > > src/Control/Effect/Reader.hs:33:8: > Not in scope: type constructor or class ?Var? > > src/Control/Effect/Reader.hs:33:28: > Not in scope: type constructor or class ?:->? > > src/Control/Effect/Reader.hs:34:5: > Not in scope: data constructor ?Var? > > src/Control/Effect/Reader.hs:34:24: > Not in scope: data constructor ?Var? > > src/Control/Effect/Reader.hs:34:28: > Not in scope: data constructor ?:->? > Failed to install effect-monad-0.6.1 > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasmiedema at gmail.com Sat Jan 16 01:18:22 2016 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Sat, 16 Jan 2016 02:18:22 +0100 Subject: Explanation of a core-lint warning (Bad getNth) In-Reply-To: References: <1471396847564ce18df16cc6a3692ace@DB4PR30MB030.064d.mgd.msft.net> Message-ID: I can reproduce the problem with 7.10.3. Since the compiler got completely rewritten, the plugin for sure doesn't work with 8.0. In case anyone else wants to take look at this bug, I can say the plugin contains a lot of hopefully helpful comments. On Sat, Jan 16, 2016 at 12:49 AM, Jan Bracker wrote: > Seems like 'effect-monad' is bitrotting a bit... > I submitted this pull request: https://github.com/dorchard/effect-monad/pull/5 -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.colpitts at gmail.com Sat Jan 16 14:43:01 2016 From: george.colpitts at gmail.com (George Colpitts) Date: Sat, 16 Jan 2016 10:43:01 -0400 Subject: issues on Glasgow Haskell Compiler 8.0.1, release candidate 1 Message-ID: Hi Ben Yes this fixes the issue I found on the Mac. Although it seems there is a minor problem that I encountered: sudo make install ... /usr/bin/install -c -m 644 docs/users_guide/ghc.1 "/usr/local/share/man/man1" install: /usr/local/share/man/man1/ghc.1: No such file or directory make[1]: *** [install_man] Error 71 make: *** [install] Error 2 bash-3.2$ rm /usr/local/share/man/man1/ghc.1 Also, again minor, with either source or binary distribution I am seeing the following warnings: Warning: /var/folders/9b/rh4y2gy92hgdb6ktv4df1jv00000gn/T/pkgConf-data-ordlist-0.4.78235644401115438165.0: Unrecognized field abi on line 15 ?when doing cabal installs, e.g. cabal install data-ordlist I believe somebody else asked, do we intend to distribute llvm with 8.0.1. If so I will wait for the next release candidate to test llvm otherwise I will install llvm 3.7 and test llvm Thanks George ? On Fri, Jan 15, 2016 at 11:11 AM, Ben Gamari wrote: > George Colpitts writes: > > > installs fine on mac but cabal install vector fails on primitive, looks > to > > me like gmp library is not provided > > > I have built a new OS X binary [1] which should be linked against the > in-tree libgmp, fixing this issue (which we've been tracking as Trac > #11423). > > I have also pushed a 32-bit Windows build. > > Perhaps those affected by this issue could try this distribution? > > Cheers, > > - Ben > > > [1] > http://downloads.haskell.org/~ghc/8.0.1-rc1/ghc-8.0.0b.20160111-x86_64-apple-darwin.tar.xz > > _______________________________________________ > 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: From matthewtpickering at gmail.com Sat Jan 16 14:47:44 2016 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Sat, 16 Jan 2016 14:47:44 +0000 Subject: issues on Glasgow Haskell Compiler 8.0.1, release candidate 1 In-Reply-To: References: Message-ID: Hi George, For the the second error, building cabal from the github repo will stop the warnings. Matt On Sat, Jan 16, 2016 at 2:43 PM, George Colpitts wrote: > Hi Ben > > Yes this fixes the issue I found on the Mac. Although it seems there is a > minor problem that I encountered: > > sudo make install > ... > /usr/bin/install -c -m 644 docs/users_guide/ghc.1 > "/usr/local/share/man/man1" > install: /usr/local/share/man/man1/ghc.1: No such file or directory > make[1]: *** [install_man] Error 71 > make: *** [install] Error 2 > bash-3.2$ rm /usr/local/share/man/man1/ghc.1 > > > Also, again minor, with either source or binary distribution I am seeing the > following warnings: > > Warning: > /var/folders/9b/rh4y2gy92hgdb6ktv4df1jv00000gn/T/pkgConf-data-ordlist-0.4.78235644401115438165.0: > Unrecognized field abi on line 15 > > when doing cabal installs, e.g. cabal install data-ordlist > > I believe somebody else asked, do we intend to distribute llvm with 8.0.1. > If so I will wait for the next release candidate to test llvm otherwise I > will install llvm 3.7 and test llvm > > Thanks > George > > > On Fri, Jan 15, 2016 at 11:11 AM, Ben Gamari wrote: >> >> George Colpitts writes: >> >> > installs fine on mac but cabal install vector fails on primitive, looks >> > to >> > me like gmp library is not provided >> > >> I have built a new OS X binary [1] which should be linked against the >> in-tree libgmp, fixing this issue (which we've been tracking as Trac >> #11423). >> >> I have also pushed a 32-bit Windows build. >> >> Perhaps those affected by this issue could try this distribution? >> >> Cheers, >> >> - Ben >> >> >> [1] >> http://downloads.haskell.org/~ghc/8.0.1-rc1/ghc-8.0.0b.20160111-x86_64-apple-darwin.tar.xz >> >> _______________________________________________ >> 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 alan.zimm at gmail.com Sun Jan 17 14:49:43 2016 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Sun, 17 Jan 2016 16:49:43 +0200 Subject: Multiple GHC sessions Message-ID: At the moment there are issues with having multiple GHC API sessions in a single executable, which boil down to GHC having global variables. A quick grep over the GHC sources shows the following instances compiler/ghci/Linker.hs:90:GLOBAL_VAR_M(v_PersistentLinkerState, ... compiler/ghci/Linker.hs:91:GLOBAL_VAR(v_InitLinkerDone, .... compiler/main/StaticFlags.hs:94:GLOBAL_VAR(v_opt_C, .... compiler/main/StaticFlags.hs:95:GLOBAL_VAR(v_opt_C_ready, .... compiler/main/DynFlags.hs:4453:GLOBAL_VAR(v_unsafeGlobalDynFlags,.... ghc/GHCi/UI.hs:149:GLOBAL_VAR(macros_ref,.... Of these the v_unsafeGlobalDynFlags can probably be ignored, as they are intended to be used in very specific, limited circumstances only. So, would it be possible to create a structure housing the remaining ones, and somehow make it possible to access these in some kind of session? Or preferably get rid of them, or move them into existing structures such as DynFlags. This is an exploratory email, more to get a handle on what has been done/considered already in this space. The issue does have a major impact on tooling developers though. Regards Alan From niteria at gmail.com Sun Jan 17 14:58:53 2016 From: niteria at gmail.com (Bartosz Nitka) Date: Sun, 17 Jan 2016 14:58:53 +0000 Subject: Multiple GHC sessions In-Reply-To: References: Message-ID: >From https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi: "We can have multiple instances of a GHC Session on the GHC API, each running TH and/or interpreted code. Right now this is not possible because the linker's state is global." Regards, Bartosz 2016-01-17 14:49 GMT+00:00 Alan & Kim Zimmerman : > At the moment there are issues with having multiple GHC API sessions > in a single executable, which boil down to GHC having global > variables. > > A quick grep over the GHC sources shows the following instances > > compiler/ghci/Linker.hs:90:GLOBAL_VAR_M(v_PersistentLinkerState, ... > compiler/ghci/Linker.hs:91:GLOBAL_VAR(v_InitLinkerDone, .... > > compiler/main/StaticFlags.hs:94:GLOBAL_VAR(v_opt_C, .... > compiler/main/StaticFlags.hs:95:GLOBAL_VAR(v_opt_C_ready, .... > > compiler/main/DynFlags.hs:4453:GLOBAL_VAR(v_unsafeGlobalDynFlags,.... > > ghc/GHCi/UI.hs:149:GLOBAL_VAR(macros_ref,.... > > Of these the v_unsafeGlobalDynFlags can probably be ignored, as they > are intended to be used in very specific, limited circumstances only. > > So, would it be possible to create a structure housing the remaining > ones, and somehow make it possible to access these in some kind of > session? Or preferably get rid of them, or move them into existing > structures such as DynFlags. > > This is an exploratory email, more to get a handle on what has been > done/considered already in this space. > > The issue does have a major impact on tooling developers though. > > Regards > Alan > _______________________________________________ > 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: From alan.zimm at gmail.com Sun Jan 17 15:05:39 2016 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Sun, 17 Jan 2016 17:05:39 +0200 Subject: Multiple GHC sessions In-Reply-To: References: Message-ID: Yes, but this solution is bypassing the problem by using remote execution. My question is what could be done to make the remote execution unnecessary, i.e addressing the "Right now" part. Alan On Sun, Jan 17, 2016 at 4:58 PM, Bartosz Nitka wrote: > From https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi: > "We can have multiple instances of a GHC Session on the GHC API, each > running TH and/or interpreted code. Right now this is not possible because > the linker's state is global." > > Regards, > Bartosz > > 2016-01-17 14:49 GMT+00:00 Alan & Kim Zimmerman : >> >> At the moment there are issues with having multiple GHC API sessions >> in a single executable, which boil down to GHC having global >> variables. >> >> A quick grep over the GHC sources shows the following instances >> >> compiler/ghci/Linker.hs:90:GLOBAL_VAR_M(v_PersistentLinkerState, ... >> compiler/ghci/Linker.hs:91:GLOBAL_VAR(v_InitLinkerDone, .... >> >> compiler/main/StaticFlags.hs:94:GLOBAL_VAR(v_opt_C, .... >> compiler/main/StaticFlags.hs:95:GLOBAL_VAR(v_opt_C_ready, .... >> >> compiler/main/DynFlags.hs:4453:GLOBAL_VAR(v_unsafeGlobalDynFlags,.... >> >> ghc/GHCi/UI.hs:149:GLOBAL_VAR(macros_ref,.... >> >> Of these the v_unsafeGlobalDynFlags can probably be ignored, as they >> are intended to be used in very specific, limited circumstances only. >> >> So, would it be possible to create a structure housing the remaining >> ones, and somehow make it possible to access these in some kind of >> session? Or preferably get rid of them, or move them into existing >> structures such as DynFlags. >> >> This is an exploratory email, more to get a handle on what has been >> done/considered already in this space. >> >> The issue does have a major impact on tooling developers though. >> >> Regards >> Alan >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > From jan.stolarek at p.lodz.pl Sun Jan 17 15:24:52 2016 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Sun, 17 Jan 2016 16:24:52 +0100 Subject: Phab failing to apply patches In-Reply-To: References: <201601151849.14883.jan.stolarek@p.lodz.pl> <201601151906.33939.jan.stolarek@p.lodz.pl> Message-ID: <201601171624.52669.jan.stolarek@p.lodz.pl> Can we somehow force Phab to apply a patch against a base commit from which the patch was created? Current setting does not seem very useful - it will probably force me to rebase my patches once a week or so. That will be very painful. Janek Dnia pi?tek, 15 stycznia 2016, Thomas Miedema napisa?: > It changed some time last year. > > Before, Harbormaster would sometimes try to build some bizarro intermediate > mix of base commit + patch + master. See > https://ghc.haskell.org/trac/ghc/ticket/9855. > > > On Fri, Jan 15, 2016 at 7:06 PM, Jan Stolarek > > wrote: > > Somehow I always I believed that Harbormaster does not apply a patch onto > > master but onto the > > revision it was created from. Has there been any change in this behaviour > > recently? > > > > Janek > > > > Dnia pi?tek, 15 stycznia 2016, Thomas Miedema napisa?: > > > "Unable to apply patch!" means just that. Harbormaster is unable to > > > apply the patch (to master). You can test it yourself by running 'arc > > > patch --nobranch D1778` on an up-to-date checkout of the master branch, > > > and it will fail in the same way. > > > > > > Solution: rebase your patch onto master, and update the Diff. You'll > > > > notice > > > > > there are indeed merge problems. > > > > > > > > > On Fri, Jan 15, 2016 at 6:49 PM, Jan Stolarek > > > > > > wrote: > > > > It seems that Phab is once again failing to apply patches (eg. D1778, > > > > which built perfectly fine > > > > until latest update). Is anyone else experiencing this? > > > > > > > > Janek > > > > > > > > --- > > > > Politechnika ??dzka > > > > Lodz University of Technology > > > > > > > > Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla > > > > adresata. > > > > > > Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? > > > > przez pomy?k? > > > > prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. > > > > > > > > This email contains information intended solely for the use of the > > > > individual to whom it is addressed. > > > > If you are not the intended recipient or if you have received this > > > > message in error, > > > > please notify the sender and delete it from your system. > > > > _______________________________________________ > > > > 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. --- 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 Sun Jan 17 19:54:50 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Sun, 17 Jan 2016 20:54:50 +0100 Subject: Multiple GHC sessions In-Reply-To: References: Message-ID: <8737twhth1.fsf@smart-cactus.org> Alan & Kim Zimmerman writes: > At the moment there are issues with having multiple GHC API sessions > in a single executable, which boil down to GHC having global > variables. > > A quick grep over the GHC sources shows the following instances > > compiler/ghci/Linker.hs:90:GLOBAL_VAR_M(v_PersistentLinkerState, ... > compiler/ghci/Linker.hs:91:GLOBAL_VAR(v_InitLinkerDone, .... > This isn't the only global state had by the linker; have a look at rts/Linker.c. Unfortunately this would take a fair amount of work to resolve. The easiest solution here would probably be to put a lock around the linker and have all sessions in a process use the same linker. > compiler/main/StaticFlags.hs:94:GLOBAL_VAR(v_opt_C, .... > compiler/main/StaticFlags.hs:95:GLOBAL_VAR(v_opt_C_ready, .... > We've been meaning to get rid of the remaining static flags for quite some time. I was a bit surprised to find that opt_NoStateHack is static. This is a bit of an ugly one: the only user is a test in Id.isStateHackType which is buried inside several layers [1] of pure predicates that have no DynFlags. It would be a shame to pass a DynFlags through all of these calls just to support the state hack (which we threaten drop about once every six months). One option, of course, would be to merge all of the static flags into DynFlags and rework their users to use unsafeGlobalDynFlags. [1] One particular callpath is, Id.isStateHackType Id.typeOneShot CoreArity.typeArity CoreArity.exprArity CorePrep.rhsToBody CorePrep.cpeBody > compiler/main/DynFlags.hs:4453:GLOBAL_VAR(v_unsafeGlobalDynFlags,.... > The principle user of this is Outputable, which uses it to provide DynFlags for pprTrace and friends. As you say, these are rather special cases and it's probably fine if they behave a bit funky in the case of more than one session in a process. > ghc/GHCi/UI.hs:149:GLOBAL_VAR(macros_ref,.... > It is completely unclear why this is global at all. It seems like it would fit just fine in the GHCi monad. I've opened D1789 doing exactly this. There may be other global state that I'm not thinking of, but if this is everything then it seems quite possible to fix this up 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: From ezyang at mit.edu Mon Jan 18 01:13:56 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Sun, 17 Jan 2016 17:13:56 -0800 Subject: Trac internal error Message-ID: <1453079560-sup-3695@sabre> When I posted the (attached) POST request to newticket, I got the following error. It did correctly add the ticket to the database. I've elided the form token from this. Trac detected an internal error: AttributeError: 'NoneType' object has no attribute 'split' Here's the contents of the POST request (my guess is that I put something bad in the CC field): field_summary=Turn+on+SplitSections+by+default field_reporter=ezyang field_description=This+is+a+general+tracking+bug+for+what+is+blocking+us+from+turning+on+`SplitSections`+by+default,+implemented+in+#8405.+Fixing+this,+and+mandating+use+of+the+gold+linker,+will+help+solve+#11285+(split+objects+make+linking+slow),+and+will+make+ghc-split+unnecessary,+mooting+#9832. I+encountered+some+misinformation+while+talking+to+people+about+this+feature,+regarding+whether+or+not+this+feature+only+supported+by+Apple-style+linkers+(i.e.+on+Mac+OS+X)?+On+IRC+I+heard+a+claim+made+that+`--split-sections`+was+only+supported+by+Mac+OS+X.+However,+olsner+pointed+out+that+`-split-sections`+on+GHC+was+OUR+reimplementation+of+the+feature,+and+likely+does+not+work+on+Mac+OS+X.+https://github.com/snowleopard/shaking-up-ghc/issues/153#issuecomment-171078800++A+later+comment+mentioned+that+ So,+can+we+turn+on+this+feature+by+default?+Does+it+subsume+split-objs?+Does+it+work+on+all+the+tier-1+platforms?+It+would+be+nice+if+bgamari,+olsner+and+co+could+weigh+in+here.+Thanks! field_type=task field_priority=normal field_milestone=8.2.1 field_component=Build+System field_version=8.0.1-rc1 field_keywords field_cc=bgamari,+olsner field_os=Unknown/Multiple field_architecture=Unknown/Multiple field_failure=None/Unknown field_testcase field_blockedby field_blocking=#11285 field_related field_differential field_wikipage field_owner=<+default+> sfp_email sfph_mail submit=Create+ticket From conal at conal.net Mon Jan 18 02:40:14 2016 From: conal at conal.net (Conal Elliott) Date: Sun, 17 Jan 2016 18:40:14 -0800 Subject: ghci and unfoldings? Message-ID: I'm developing a GHC plugin (using HERMIT), and I'd like to use ghci to speed up development. I'm able to do so, except that my plugin critically needs access to unfoldings, which appear to be unavailable in ghci. A little experimenting with ghc shows me that "-O" is the key, but "-O" is incompatible with "--interactive" (as in ghci). Is there any way to persuade ghci to make unfoldings available? Thanks, - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Mon Jan 18 03:00:36 2016 From: allbery.b at gmail.com (Brandon Allbery) Date: Sun, 17 Jan 2016 22:00:36 -0500 Subject: ghci and unfoldings? In-Reply-To: References: Message-ID: On Sun, Jan 17, 2016 at 9:40 PM, Conal Elliott wrote: > I'm developing a GHC plugin (using HERMIT), and I'd like to use ghci to > speed up development. I'm able to do so, except that my plugin critically > needs access to unfoldings, which appear to be unavailable in ghci. A > little experimenting with ghc shows me that "-O" is the key, but "-O" is > incompatible with "--interactive" (as in ghci). Is there any way to > persuade ghci to make unfoldings available? I think unfoldings are only done as part of optimization, and the bytecode backend doesn't support optimization at all. -- 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: From conal at conal.net Mon Jan 18 06:18:49 2016 From: conal at conal.net (Conal Elliott) Date: Sun, 17 Jan 2016 22:18:49 -0800 Subject: ghci and unfoldings? In-Reply-To: References: Message-ID: Hi Brandon. Thanks for the reply. I?m not sure that it addresses what I was trying to ask. GHCi *does* invoke plugins and even reloads those plugins dynamically when their source code changes. So in this sense ghci does enable optimization, even if it doesn?t perform much optimization on its own. And of course plugins and unfolding are not just about optimization. I?m not looking for ghci to do optimization, but rather to enable me to more easily develop my GHC plugins. It?s *almost* there already. I just need access to unfoldings from other modules for my plugin?s use. For context, I?m rebuilding my Haskell-to-hardware compiler , which relies on giving a non-standard but principled interpretation of Haskell programs via a conversion through the language of cartesian closed categories (CCCs). The first back-end is hardware generation (e.g., via Verilog), and I have plans for several other CCC-based interpretations. In addition to facilitating my plugin development, hosting in ghci will make it much more pleasant for others to *use* the plugin during exploratory programming, just as with ghci use in general. With access to unfoldings, users will be able to generate circuit diagrams and Verilog like those in my compiler talk immediately and directly from within ghci. I also intend to make a GPU back-end for fast interactive graphics etc, which would be much more fun in ghci than with batch compilation. I hope this explanation clarifies my goals and motivation. I hope there?s a way to access unfoldings from ghci currently or with a small amount of effort. Regards, - Conal On Sun, Jan 17, 2016 at 7:00 PM, Brandon Allbery wrote: > On Sun, Jan 17, 2016 at 9:40 PM, Conal Elliott wrote: > >> I'm developing a GHC plugin (using HERMIT), and I'd like to use ghci to >> speed up development. I'm able to do so, except that my plugin critically >> needs access to unfoldings, which appear to be unavailable in ghci. A >> little experimenting with ghc shows me that "-O" is the key, but "-O" is >> incompatible with "--interactive" (as in ghci). Is there any way to >> persuade ghci to make unfoldings available? > > > I think unfoldings are only done as part of optimization, and the bytecode > backend doesn't support optimization at all. > > -- > 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: From ezyang at mit.edu Mon Jan 18 06:37:07 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Sun, 17 Jan 2016 22:37:07 -0800 Subject: ghci and unfoldings? In-Reply-To: References: Message-ID: <1453098976-sup-8811@sabre> Does passing -fobject-code solve your problem? Edward Excerpts from Conal Elliott's message of 2016-01-17 22:18:49 -0800: > Hi Brandon. Thanks for the reply. I?m not sure that it addresses what I was > trying to ask. GHCi *does* invoke plugins and even reloads those plugins > dynamically when their source code changes. So in this sense ghci does > enable optimization, even if it doesn?t perform much optimization on its > own. And of course plugins and unfolding are not just about optimization. > > I?m not looking for ghci to do optimization, but rather to enable me to > more easily develop my GHC plugins. It?s *almost* there already. I just > need access to unfoldings from other modules for my plugin?s use. > > For context, I?m rebuilding my Haskell-to-hardware compiler > , which relies on > giving a non-standard but principled interpretation of Haskell programs via > a conversion through the language of cartesian closed categories (CCCs). > The first back-end is hardware generation (e.g., via Verilog), and I have > plans for several other CCC-based interpretations. > > In addition to facilitating my plugin development, hosting in ghci will > make it much more pleasant for others to *use* the plugin during > exploratory programming, just as with ghci use in general. With access to > unfoldings, users will be able to generate circuit diagrams and Verilog > like those in my compiler talk immediately and directly from within ghci. I > also intend to make a GPU back-end for fast interactive graphics etc, which > would be much more fun in ghci than with batch compilation. > I hope this explanation clarifies my goals and motivation. I hope there?s a > way to access unfoldings from ghci currently or with a small amount of > effort. > > Regards, - Conal > > On Sun, Jan 17, 2016 at 7:00 PM, Brandon Allbery > wrote: > > > On Sun, Jan 17, 2016 at 9:40 PM, Conal Elliott wrote: > > > >> I'm developing a GHC plugin (using HERMIT), and I'd like to use ghci to > >> speed up development. I'm able to do so, except that my plugin critically > >> needs access to unfoldings, which appear to be unavailable in ghci. A > >> little experimenting with ghc shows me that "-O" is the key, but "-O" is > >> incompatible with "--interactive" (as in ghci). Is there any way to > >> persuade ghci to make unfoldings available? > > > > > > I think unfoldings are only done as part of optimization, and the bytecode > > backend doesn't support optimization at all. > > > > -- > > brandon s allbery kf8nh sine nomine > > associates > > allbery.b at gmail.com > > ballbery at sinenomine.net > > unix, openafs, kerberos, infrastructure, xmonad > > http://sinenomine.net > > From conal at conal.net Mon Jan 18 06:45:24 2016 From: conal at conal.net (Conal Elliott) Date: Sun, 17 Jan 2016 22:45:24 -0800 Subject: ghci and unfoldings? In-Reply-To: <1453098976-sup-8811@sabre> References: <1453098976-sup-8811@sabre> Message-ID: Thanks for the suggestion. That flag doesn't appear to help. Still no unfolding info. On Sun, Jan 17, 2016 at 10:37 PM, Edward Z. Yang wrote: > Does passing -fobject-code solve your problem? > > Edward > > Excerpts from Conal Elliott's message of 2016-01-17 22:18:49 -0800: > > Hi Brandon. Thanks for the reply. I?m not sure that it addresses what I > was > > trying to ask. GHCi *does* invoke plugins and even reloads those plugins > > dynamically when their source code changes. So in this sense ghci does > > enable optimization, even if it doesn?t perform much optimization on its > > own. And of course plugins and unfolding are not just about optimization. > > > > I?m not looking for ghci to do optimization, but rather to enable me to > > more easily develop my GHC plugins. It?s *almost* there already. I just > > need access to unfoldings from other modules for my plugin?s use. > > > > For context, I?m rebuilding my Haskell-to-hardware compiler > > , which relies > on > > giving a non-standard but principled interpretation of Haskell programs > via > > a conversion through the language of cartesian closed categories (CCCs). > > The first back-end is hardware generation (e.g., via Verilog), and I have > > plans for several other CCC-based interpretations. > > > > In addition to facilitating my plugin development, hosting in ghci will > > make it much more pleasant for others to *use* the plugin during > > exploratory programming, just as with ghci use in general. With access to > > unfoldings, users will be able to generate circuit diagrams and Verilog > > like those in my compiler talk immediately and directly from within > ghci. I > > also intend to make a GPU back-end for fast interactive graphics etc, > which > > would be much more fun in ghci than with batch compilation. > > I hope this explanation clarifies my goals and motivation. I hope > there?s a > > way to access unfoldings from ghci currently or with a small amount of > > effort. > > > > Regards, - Conal > > > > On Sun, Jan 17, 2016 at 7:00 PM, Brandon Allbery > > wrote: > > > > > On Sun, Jan 17, 2016 at 9:40 PM, Conal Elliott > wrote: > > > > > >> I'm developing a GHC plugin (using HERMIT), and I'd like to use ghci > to > > >> speed up development. I'm able to do so, except that my plugin > critically > > >> needs access to unfoldings, which appear to be unavailable in ghci. A > > >> little experimenting with ghc shows me that "-O" is the key, but "-O" > is > > >> incompatible with "--interactive" (as in ghci). Is there any way to > > >> persuade ghci to make unfoldings available? > > > > > > > > > I think unfoldings are only done as part of optimization, and the > bytecode > > > backend doesn't support optimization at all. > > > > > > -- > > > 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: From conal at conal.net Mon Jan 18 06:49:28 2016 From: conal at conal.net (Conal Elliott) Date: Sun, 17 Jan 2016 22:49:28 -0800 Subject: ghci and unfoldings? In-Reply-To: References: <1453098976-sup-8811@sabre> Message-ID: Oh! I spoke too soon. Yes, that flag does seem to make unfoldings available. Thanks! Now more experimentation. Thanks again! -- Conal On Sun, Jan 17, 2016 at 10:45 PM, Conal Elliott wrote: > Thanks for the suggestion. That flag doesn't appear to help. Still no > unfolding info. > > On Sun, Jan 17, 2016 at 10:37 PM, Edward Z. Yang wrote: > >> Does passing -fobject-code solve your problem? >> >> Edward >> >> Excerpts from Conal Elliott's message of 2016-01-17 22:18:49 -0800: >> > Hi Brandon. Thanks for the reply. I?m not sure that it addresses what I >> was >> > trying to ask. GHCi *does* invoke plugins and even reloads those plugins >> > dynamically when their source code changes. So in this sense ghci does >> > enable optimization, even if it doesn?t perform much optimization on its >> > own. And of course plugins and unfolding are not just about >> optimization. >> > >> > I?m not looking for ghci to do optimization, but rather to enable me to >> > more easily develop my GHC plugins. It?s *almost* there already. I just >> > need access to unfoldings from other modules for my plugin?s use. >> > >> > For context, I?m rebuilding my Haskell-to-hardware compiler >> > , which relies >> on >> > giving a non-standard but principled interpretation of Haskell programs >> via >> > a conversion through the language of cartesian closed categories (CCCs). >> > The first back-end is hardware generation (e.g., via Verilog), and I >> have >> > plans for several other CCC-based interpretations. >> > >> > In addition to facilitating my plugin development, hosting in ghci will >> > make it much more pleasant for others to *use* the plugin during >> > exploratory programming, just as with ghci use in general. With access >> to >> > unfoldings, users will be able to generate circuit diagrams and Verilog >> > like those in my compiler talk immediately and directly from within >> ghci. I >> > also intend to make a GPU back-end for fast interactive graphics etc, >> which >> > would be much more fun in ghci than with batch compilation. >> > I hope this explanation clarifies my goals and motivation. I hope >> there?s a >> > way to access unfoldings from ghci currently or with a small amount of >> > effort. >> > >> > Regards, - Conal >> > >> > On Sun, Jan 17, 2016 at 7:00 PM, Brandon Allbery >> > wrote: >> > >> > > On Sun, Jan 17, 2016 at 9:40 PM, Conal Elliott >> wrote: >> > > >> > >> I'm developing a GHC plugin (using HERMIT), and I'd like to use ghci >> to >> > >> speed up development. I'm able to do so, except that my plugin >> critically >> > >> needs access to unfoldings, which appear to be unavailable in ghci. A >> > >> little experimenting with ghc shows me that "-O" is the key, but >> "-O" is >> > >> incompatible with "--interactive" (as in ghci). Is there any way to >> > >> persuade ghci to make unfoldings available? >> > > >> > > >> > > I think unfoldings are only done as part of optimization, and the >> bytecode >> > > backend doesn't support optimization at all. >> > > >> > > -- >> > > 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: From conal at conal.net Mon Jan 18 07:52:20 2016 From: conal at conal.net (Conal Elliott) Date: Sun, 17 Jan 2016 23:52:20 -0800 Subject: Plugin from ghci REPL? Message-ID: Is it possible to have GHC plugins get invoked from the ghci *REPL* (in addition to loaded source modules)? I'm doing some monomorphization-based transformation, and currently I write scads of trivial monomorphic specialization definitions like > sumt6 = sum :: Tree 6 Int -> Int I'd instead love to enter "let sumt6 = sum :: Tree 6 Int -> Int" or (better) just "sum :: Tree 6 Int -> Int" into the REPL and have my plugin run, without having to keep monkeying with a source file and reloading. As I understand it, an expression is turned into "let it = ...", so maybe the expression option would come for free with the ability to run plugins on in-REPL definitions. -- Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Jan 18 10:10:40 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 18 Jan 2016 10:10:40 +0000 Subject: Multiple GHC sessions In-Reply-To: <8737twhth1.fsf@smart-cactus.org> References: <8737twhth1.fsf@smart-cactus.org> Message-ID: <77fd37bf609a4eb68b0ab2887538abed@AM3PR30MB019.064d.mgd.msft.net> I don't think the state-hack tail should wag the dog here. The nub of the problem in practice is the shared linker state isn't it? Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Ben | Gamari | Sent: 17 January 2016 19:55 | To: Alan & Kim Zimmerman ; ghc-devs at haskell.org | Subject: Re: Multiple GHC sessions | | Alan & Kim Zimmerman writes: | | > At the moment there are issues with having multiple GHC API sessions | > in a single executable, which boil down to GHC having global | > variables. | > | > A quick grep over the GHC sources shows the following instances | > | > compiler/ghci/Linker.hs:90:GLOBAL_VAR_M(v_PersistentLinkerState, ... | > compiler/ghci/Linker.hs:91:GLOBAL_VAR(v_InitLinkerDone, .... | > | This isn't the only global state had by the linker; have a look at | rts/Linker.c. Unfortunately this would take a fair amount of work to | resolve. The easiest solution here would probably be to put a lock | around the linker and have all sessions in a process use the same | linker. | | > compiler/main/StaticFlags.hs:94:GLOBAL_VAR(v_opt_C, .... | > compiler/main/StaticFlags.hs:95:GLOBAL_VAR(v_opt_C_ready, .... | > | We've been meaning to get rid of the remaining static flags for quite | some time. | | I was a bit surprised to find that opt_NoStateHack is static. This is | a bit of an ugly one: the only user is a test in Id.isStateHackType | which is buried inside several layers [1] of pure predicates that have | no DynFlags. It would be a shame to pass a DynFlags through all of | these calls just to support the state hack (which we threaten drop | about once every six months). | | One option, of course, would be to merge all of the static flags into | DynFlags and rework their users to use unsafeGlobalDynFlags. | | [1] One particular callpath is, | | Id.isStateHackType | Id.typeOneShot | CoreArity.typeArity | CoreArity.exprArity | CorePrep.rhsToBody | CorePrep.cpeBody | | | > | compiler/main/DynFlags.hs:4453:GLOBAL_VAR(v_unsafeGlobalDynFlags,.... | > | The principle user of this is Outputable, which uses it to provide | DynFlags for pprTrace and friends. As you say, these are rather | special cases and it's probably fine if they behave a bit funky in the | case of more than one session in a process. | | > ghc/GHCi/UI.hs:149:GLOBAL_VAR(macros_ref,.... | > | It is completely unclear why this is global at all. It seems like it | would fit just fine in the GHCi monad. I've opened D1789 doing exactly | this. | | There may be other global state that I'm not thinking of, but if this | is everything then it seems quite possible to fix this up for 8.2. | | Cheers, | | - Ben From simonpj at microsoft.com Mon Jan 18 10:19:17 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 18 Jan 2016 10:19:17 +0000 Subject: ghci and unfoldings? In-Reply-To: <1453098976-sup-8811@sabre> References: <1453098976-sup-8811@sabre> Message-ID: <5c482fcab11747b2aba28814f2f367d4@AM3PR30MB019.064d.mgd.msft.net> Or -fexpose-all-unfoldings? Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | Edward Z. Yang | Sent: 18 January 2016 06:37 | To: Conal Elliott | Cc: Andrew Farmer ; ghc-devs at haskell.org | Subject: Re: ghci and unfoldings? | | Does passing -fobject-code solve your problem? | | Edward | | Excerpts from Conal Elliott's message of 2016-01-17 22:18:49 -0800: | > Hi Brandon. Thanks for the reply. I?m not sure that it addresses | what | > I was trying to ask. GHCi *does* invoke plugins and even reloads | those | > plugins dynamically when their source code changes. So in this sense | > ghci does enable optimization, even if it doesn?t perform much | > optimization on its own. And of course plugins and unfolding are not | just about optimization. | > | > I?m not looking for ghci to do optimization, but rather to enable me | > to more easily develop my GHC plugins. It?s *almost* there already. | I | > just need access to unfoldings from other modules for my plugin?s | use. | > | > For context, I?m rebuilding my Haskell-to-hardware compiler | > , which | relies | > on giving a non-standard but principled interpretation of Haskell | > programs via a conversion through the language of cartesian closed | categories (CCCs). | > The first back-end is hardware generation (e.g., via Verilog), and I | > have plans for several other CCC-based interpretations. | > | > In addition to facilitating my plugin development, hosting in ghci | > will make it much more pleasant for others to *use* the plugin | during | > exploratory programming, just as with ghci use in general. With | access | > to unfoldings, users will be able to generate circuit diagrams and | > Verilog like those in my compiler talk immediately and directly from | > within ghci. I also intend to make a GPU back-end for fast | interactive | > graphics etc, which would be much more fun in ghci than with batch | compilation. | > I hope this explanation clarifies my goals and motivation. I hope | > there?s a way to access unfoldings from ghci currently or with a | small | > amount of effort. | > | > Regards, - Conal | > | > On Sun, Jan 17, 2016 at 7:00 PM, Brandon Allbery | | > wrote: | > | > > On Sun, Jan 17, 2016 at 9:40 PM, Conal Elliott | wrote: | > > | > >> I'm developing a GHC plugin (using HERMIT), and I'd like to use | > >> ghci to speed up development. I'm able to do so, except that my | > >> plugin critically needs access to unfoldings, which appear to be | > >> unavailable in ghci. A little experimenting with ghc shows me | that | > >> "-O" is the key, but "-O" is incompatible with "--interactive" | (as | > >> in ghci). Is there any way to persuade ghci to make unfoldings | available? | > > | > > | > > I think unfoldings are only done as part of optimization, and the | > > bytecode backend doesn't support optimization at all. | > > | > > -- | > > brandon s allbery kf8nh sine nomine | > > associates | > > allbery.b at gmail.com | > > ballbery at sinenomine.net | > > unix, openafs, kerberos, infrastructure, xmonad | > > | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fsine | > > | nomine.net&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cbaf2ef5 | > > | 5f8af447b42e608d31fd1cec1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sda | > > ta=qMNmL5LmkgMp0ebkr6SzPQIwhySqOicZgEdW%2fhe6Q%2b0%3d | > > | _______________________________________________ | 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%0a&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cbaf2ef55f8af | 447b42e608d31fd1cec1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=veoz | Ab6M7N9jZaJZ9tgXZ%2fI8jq7U%2b4YM1FcSXvqTcaw%3d From ben at smart-cactus.org Mon Jan 18 10:53:20 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 18 Jan 2016 11:53:20 +0100 Subject: Multiple GHC sessions In-Reply-To: <77fd37bf609a4eb68b0ab2887538abed@AM3PR30MB019.064d.mgd.msft.net> References: <8737twhth1.fsf@smart-cactus.org> <77fd37bf609a4eb68b0ab2887538abed@AM3PR30MB019.064d.mgd.msft.net> Message-ID: <87ziw3gnvj.fsf@smart-cactus.org> Simon Peyton Jones writes: > I don't think the state-hack tail should wag the dog here. The nub of > the problem in practice is the shared linker state isn't it? > I'm not sure; it's not clear to me what would break if the linker were used by more than one session at a time, even with the current GLOBAL_VAR. In fact, it arguably makes a fair bit of sense for all sessions to use the same linker state given that they are also sharing an address space. The only issue that may require a bit of care is code unloading. Consider that you have two sessions A and B, 1. A loads MyModule 2. B loads MyModule 3. They both use MyModule for a while 4. A unloads MyModule 5. B continues 6. B unloads MyModule I suspect that things will work fine up to step 6 since we don't actually unload code until the garbage collector has marked the it as dead. That being said, I suspect you would see an error from unloadObj upon attempting to unload the object the second time (and even then, the error is merely a message on stderr). Note, however, that the above conclusions have not been tested. Otherwise, it appears that things should behave fair well as the PersistentLinkerState is already wrapped in an MVar which should serve to serialize linker calls. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From alan.zimm at gmail.com Mon Jan 18 11:18:49 2016 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Mon, 18 Jan 2016 13:18:49 +0200 Subject: Multiple GHC sessions In-Reply-To: <87ziw3gnvj.fsf@smart-cactus.org> References: <8737twhth1.fsf@smart-cactus.org> <77fd37bf609a4eb68b0ab2887538abed@AM3PR30MB019.064d.mgd.msft.net> <87ziw3gnvj.fsf@smart-cactus.org> Message-ID: >From a tool writer perspective I would be happy to have GHC/Linker sessions be completely separate from each other. But I guess in practical terms a shared address space needs to be managed, making this impossible. The external interpreter for GHCI effectively solves the actual loading problem, the other things needing a GHC session are loading a module as far as type checking, for error reporting. I know this gets complicated if there is FFI involved and the loading has to go via object file generation. Alan On Mon, Jan 18, 2016 at 12:53 PM, Ben Gamari wrote: > Simon Peyton Jones writes: > >> I don't think the state-hack tail should wag the dog here. The nub of >> the problem in practice is the shared linker state isn't it? >> > I'm not sure; it's not clear to me what would break if the linker were > used by more than one session at a time, even with the current > GLOBAL_VAR. In fact, it arguably makes a fair bit of sense for all > sessions to use the same linker state given that they are also sharing > an address space. > > The only issue that may require a bit of care is code unloading. > Consider that you have two sessions A and B, > > 1. A loads MyModule > 2. B loads MyModule > 3. They both use MyModule for a while > 4. A unloads MyModule > 5. B continues > 6. B unloads MyModule > > I suspect that things will work fine up to step 6 since we don't > actually unload code until the garbage collector has marked the it as > dead. That being said, I suspect you would see an error from unloadObj > upon attempting to unload the object the second time (and even then, the > error is merely a message on stderr). Note, however, that the above > conclusions have not been tested. > > Otherwise, it appears that things should behave fair well as the > PersistentLinkerState is already wrapped in an MVar which should > serve to serialize linker calls. > > Cheers, > > - Ben > From marlowsd at gmail.com Mon Jan 18 15:18:55 2016 From: marlowsd at gmail.com (Simon Marlow) Date: Mon, 18 Jan 2016 15:18:55 +0000 Subject: Multiple GHC sessions In-Reply-To: References: <8737twhth1.fsf@smart-cactus.org> <77fd37bf609a4eb68b0ab2887538abed@AM3PR30MB019.064d.mgd.msft.net> <87ziw3gnvj.fsf@smart-cactus.org> Message-ID: On 18 January 2016 at 11:18, Alan & Kim Zimmerman wrote: > From a tool writer perspective I would be happy to have GHC/Linker > sessions be completely separate from each other. But I guess in > practical terms a shared address space needs to be managed, making > this impossible. > > The external interpreter for GHCI effectively solves the actual > loading problem, the other things needing a GHC session are loading a > module as far as type checking, for error reporting. I know this gets > complicated if there is FFI involved and the loading has to go via > object file generation. > Yes, I think -fexternal-interpreter is the basis of the right solution here. You do also need to move the PersistentLinkerState to HscEnv, but that should be a fairly straightforward refactoring. (actually I almost did this as part of the remote GHCi work, but some of the comments next to PersistentLinkerState suggested that there might be some real use cases for having the linker state be shared between multiple sessions, so I decided not to attack that problem right away.) Cheers, Simon Alan > > On Mon, Jan 18, 2016 at 12:53 PM, Ben Gamari wrote: > > Simon Peyton Jones writes: > > > >> I don't think the state-hack tail should wag the dog here. The nub of > >> the problem in practice is the shared linker state isn't it? > >> > > I'm not sure; it's not clear to me what would break if the linker were > > used by more than one session at a time, even with the current > > GLOBAL_VAR. In fact, it arguably makes a fair bit of sense for all > > sessions to use the same linker state given that they are also sharing > > an address space. > > > > The only issue that may require a bit of care is code unloading. > > Consider that you have two sessions A and B, > > > > 1. A loads MyModule > > 2. B loads MyModule > > 3. They both use MyModule for a while > > 4. A unloads MyModule > > 5. B continues > > 6. B unloads MyModule > > > > I suspect that things will work fine up to step 6 since we don't > > actually unload code until the garbage collector has marked the it as > > dead. That being said, I suspect you would see an error from unloadObj > > upon attempting to unload the object the second time (and even then, the > > error is merely a message on stderr). Note, however, that the above > > conclusions have not been tested. > > > > Otherwise, it appears that things should behave fair well as the > > PersistentLinkerState is already wrapped in an MVar which should > > serve to serialize linker calls. > > > > 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: From eir at cis.upenn.edu Mon Jan 18 15:27:19 2016 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 18 Jan 2016 10:27:19 -0500 Subject: equality relations: user-facing pretty-printing question Message-ID: <000A9614-260F-44E1-86CD-A1E681F49DFF@cis.upenn.edu> Hi devs, I've recently made a design decision for GHC 8.0 that I may wish to revisit, and I'd love some feedback. GHC 7.x has but one user-visible type equality relation, ~. The constraint (ty1 ~ ty2) is well-kinded only when ty1 and ty2 have the same kinds. And the solver works in terms of this very same equality, so error messages simply talk about ~. GHC 8.0, on the other hand, has three equality relations that might potentially appear to users. It retains ~. But it also has ~~, which is heterogeneous type equality, meaning that (ty1 ~~ ty2) is well-kinded even when ty1 and ty2 have different kinds. And it has ~#, which is the unlifted equality used in the solver. It turns out that ~~ and ~ are just wrappers around ~#. Because of all of this, GHC sometimes ends up thinking about ~~ or ~# even when the user has said ~. (See the definition of ~ in Data.Type.Equality, for example.) And it naively would print ~# a bunch in error messages. So, I put a little pretty-printing magic in that prints ~, ~~, and ~# all as ~ in user-facing output, unless the user writes -fprint-equality-relations. This design decision has kept error messages pretty. But it will be awfully confusing when someone intentionally uses ~~ and sees ~ in their output. And there's nothing to suggest -fprint-equality-relations. These sorts "hide the scary plumbing!" decisions irk me to no end when I find them in my operating system. But now I've done the same thing in GHC... which is why I want to re-examine this. What do you think? Do you see a better way to handle this? Thanks! Richard From thomasmiedema at gmail.com Mon Jan 18 16:44:46 2016 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Mon, 18 Jan 2016 17:44:46 +0100 Subject: Phab failing to apply patches In-Reply-To: <201601171624.52669.jan.stolarek@p.lodz.pl> References: <201601151849.14883.jan.stolarek@p.lodz.pl> <201601151906.33939.jan.stolarek@p.lodz.pl> <201601171624.52669.jan.stolarek@p.lodz.pl> Message-ID: On Sun, Jan 17, 2016 at 4:24 PM, Jan Stolarek wrote: > Can we somehow force Phab to apply a patch against a base commit from > which the patch was created? > I don't know about "somehow", maybe Austin knows a way. The current default should not be changed though, in my opinion. We expect contributors to make their patches against HEAD, and we want to review them against HEAD. So Harbormaster should also try to build them against HEAD. If you are working from an old base commit, either rebase your patch before submitting to Phabricator (painful? you will have to do it before pushing anyway, might as well do it now), or ignore the Harbormaster validate result. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.stolarek at p.lodz.pl Mon Jan 18 16:49:17 2016 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Mon, 18 Jan 2016 17:49:17 +0100 Subject: Phab failing to apply patches In-Reply-To: References: <201601151849.14883.jan.stolarek@p.lodz.pl> <201601171624.52669.jan.stolarek@p.lodz.pl> Message-ID: <201601181749.17735.jan.stolarek@p.lodz.pl> > If you are working from an old base commit, either rebase your patch before > submitting to Phabricator (painful? you will have to do it before pushing > anyway, might as well do it now), or ignore the Harbormaster validate > result. I am typically working on some non-trivial features (ie. rebases tend to be painful). Having Harbormaster build results is a useful way of telling whether I broke something or not. Even if it is for some older commit. Rebases take time and if I know my feature will not be finished in the next couple of weeks I want to save myself from unnecessary rebasing. Why rebase all the time if I can do it just once at the end? Janek --- Politechnika ??dzka Lodz University of Technology Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system. From thomasmiedema at gmail.com Mon Jan 18 17:09:23 2016 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Mon, 18 Jan 2016 18:09:23 +0100 Subject: Phab failing to apply patches In-Reply-To: <201601181749.17735.jan.stolarek@p.lodz.pl> References: <201601151849.14883.jan.stolarek@p.lodz.pl> <201601171624.52669.jan.stolarek@p.lodz.pl> <201601181749.17735.jan.stolarek@p.lodz.pl> Message-ID: On Mon, Jan 18, 2016 at 5:49 PM, Jan Stolarek wrote: > > If you are working from an old base commit, either rebase your patch > before > > submitting to Phabricator (painful? you will have to do it before pushing > > anyway, might as well do it now), or ignore the Harbormaster validate > > result. > I am typically working on some non-trivial features (ie. rebases tend to > be painful). Having > Harbormaster build results is a useful way of telling whether I broke > something or not. Even if > it is for some older commit. Rebases take time and if I know my feature > will not be finished in > the next couple of weeks I want to save myself from unnecessary rebasing. > Why rebase all the time > if I can do it just once at the end? > There are a few options: * you validate locally (in a different build directory, so you can keep using build flavour = devel2 in your development directory) * fork the ghc github repository, push your branch there, and let Travis validate it: https://ghc.haskell.org/trac/ghc/wiki/TestingPatches#Travis * ask Austin for some special Phabricator syntax that you could add when you submit the patch, to request Harbormaster not to rebase onto HEAD before validating Side note: I think we should go back to using Phabricator for finished patches only. It slows the review process down, when there are 50 patches in the queue waiting-for-review-but-not-really: https://phabricator.haskell.org/differential/query/bITEu.ig1Hep/ Sometimes it leads to finished patches actually getting ignored for a long time, because the reviewers still think the author is working on them. But other might think differently, and maybe it's not a big deal. > > Janek > > --- > Politechnika ??dzka > Lodz University of Technology > > Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. > Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez > pomy?k? > prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. > > This email contains information intended solely for the use of the > individual to whom it is addressed. > If you are not the intended recipient or if you have received this message > in error, > please notify the sender and delete it from your system. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Mon Jan 18 17:17:11 2016 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 18 Jan 2016 12:17:11 -0500 Subject: Phab failing to apply patches In-Reply-To: References: <201601151849.14883.jan.stolarek@p.lodz.pl> <201601171624.52669.jan.stolarek@p.lodz.pl> <201601181749.17735.jan.stolarek@p.lodz.pl> Message-ID: Just to chime in here: I agree with Janek that the current requirement that Phab always cherry-picks changes against master is annoying. I have a limited amount of computing power available locally, and it's much easier to push to Phab than to slow down my primary dev machine for 2+ hours. (Yes, it takes my machine 2+ hours to validate.) And rebasing a big patch frequently is even more annoying, even though it inevitably must be done in the end. That said, I also agree that we wish to accept patches that validate only when compared against HEAD. So, I wonder if a diff in Phab can have a new state, WIP. A WIP patch doesn't show up in the review queue and validates against its own base commit. When the author is ready for a full review, the author changes the state to Please Review, which then shows up in queues and validates only against master. Thomas's suggestion is essentially "don't post WIP patches". But posting a WIP patch is very helpful, serving two needs: 1) Validation that doesn't tie up a local machine. 2) Allows for early feedback on a patch. Several times, I've had some work-in-progress that has benefitted from an early review. And I've provided early reviews that saved the author time from burrowing down the wrong hole. Is this possible? Is this desirable to others, too? Thanks, Richard On Jan 18, 2016, at 12:09 PM, Thomas Miedema wrote: > > > On Mon, Jan 18, 2016 at 5:49 PM, Jan Stolarek wrote: > > If you are working from an old base commit, either rebase your patch before > > submitting to Phabricator (painful? you will have to do it before pushing > > anyway, might as well do it now), or ignore the Harbormaster validate > > result. > I am typically working on some non-trivial features (ie. rebases tend to be painful). Having > Harbormaster build results is a useful way of telling whether I broke something or not. Even if > it is for some older commit. Rebases take time and if I know my feature will not be finished in > the next couple of weeks I want to save myself from unnecessary rebasing. Why rebase all the time > if I can do it just once at the end? > > There are a few options: > > * you validate locally (in a different build directory, so you can keep using build flavour = devel2 in your development directory) > * fork the ghc github repository, push your branch there, and let Travis validate it: https://ghc.haskell.org/trac/ghc/wiki/TestingPatches#Travis > * ask Austin for some special Phabricator syntax that you could add when you submit the patch, to request Harbormaster not to rebase onto HEAD before validating > > > Side note: I think we should go back to using Phabricator for finished patches only. It slows the review process down, when there are 50 patches in the queue waiting-for-review-but-not-really: https://phabricator.haskell.org/differential/query/bITEu.ig1Hep/ Sometimes it leads to finished patches actually getting ignored for a long time, because the reviewers still think the author is working on them. But other might think differently, and maybe it's not a big deal. > > > > > > Janek > > --- > Politechnika ??dzka > Lodz University of Technology > > Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. > Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k? > prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. > > This email contains information intended solely for the use of the individual to whom it is addressed. > If you are not the intended recipient or if you have received this message in error, > please notify the sender and delete it from your system. > > _______________________________________________ > 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: From jan.stolarek at p.lodz.pl Mon Jan 18 17:20:17 2016 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Mon, 18 Jan 2016 18:20:17 +0100 Subject: Phab failing to apply patches In-Reply-To: References: <201601151849.14883.jan.stolarek@p.lodz.pl> <201601181749.17735.jan.stolarek@p.lodz.pl> Message-ID: <201601181820.18345.jan.stolarek@p.lodz.pl> > * you validate locally (in a different build directory, so you can keep > using build flavour = devel2 in your development directory) > * fork the ghc github repository, push your branch there, and let Travis > validate it: https://ghc.haskell.org/trac/ghc/wiki/TestingPatches#Travis > * ask Austin for some special Phabricator syntax that you could add when > you submit the patch, to request Harbormaster not to rebase onto HEAD > before validating Second option is an acceptable workaround for me, but having the third one would be even better. I definitely want to avoid the first one - computing power of my machine is limited. > Side note: I think we should go back to using Phabricator for finished > patches only. What if we could set the default state of upload patch to "planned changes"? This way patches would end up in the review queue only when someone explicitly sets them to "Request Review". Wouldn't that solve the problem? Janek --- Politechnika ??dzka Lodz University of Technology Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system. From ryan.gl.scott at gmail.com Mon Jan 18 17:24:17 2016 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Mon, 18 Jan 2016 12:24:17 -0500 Subject: equality relations: user-facing pretty-printing question Message-ID: In my ideal world, GHC would remember as much as what the user wrote as possible in printing error messages. So if the user writes: f :: Int ~ Char => ... Then GHC would remember that the context was written with a single tilde, and print out Int ~ Char in the error message explicitly wherever the full type signature of f is printed. What it sounds like, though, is that deep in the guts of the type inferencer, there's a chance that single-tilde equality might turn into double-tilde or tilde-hash equality at some point. In those cases, printing out the particular brand of tilde might get confusing. In such cases, we might compromise and print out something neutral like "is equal to". I suppose this would always be the case if you didn't explicitly write a ~ b and had to infer it. I'm not sure about the technical details of this though, i.e., if GHC actually remembers a ~ b all the way through the typechecking/inferencing pipeline. Ryan S. From jan.stolarek at p.lodz.pl Mon Jan 18 17:24:34 2016 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Mon, 18 Jan 2016 18:24:34 +0100 Subject: Phab failing to apply patches In-Reply-To: References: <201601151849.14883.jan.stolarek@p.lodz.pl> Message-ID: <201601181824.34831.jan.stolarek@p.lodz.pl> I agree with everything Richard said. Janek Dnia poniedzia?ek, 18 stycznia 2016, Richard Eisenberg napisa?: > Just to chime in here: I agree with Janek that the current requirement that > Phab always cherry-picks changes against master is annoying. I have a > limited amount of computing power available locally, and it's much easier > to push to Phab than to slow down my primary dev machine for 2+ hours. > (Yes, it takes my machine 2+ hours to validate.) And rebasing a big patch > frequently is even more annoying, even though it inevitably must be done in > the end. > > That said, I also agree that we wish to accept patches that validate only > when compared against HEAD. > > So, I wonder if a diff in Phab can have a new state, WIP. A WIP patch > doesn't show up in the review queue and validates against its own base > commit. When the author is ready for a full review, the author changes the > state to Please Review, which then shows up in queues and validates only > against master. > > Thomas's suggestion is essentially "don't post WIP patches". But posting a > WIP patch is very helpful, serving two needs: 1) Validation that doesn't > tie up a local machine. > 2) Allows for early feedback on a patch. Several times, I've had some > work-in-progress that has benefitted from an early review. And I've > provided early reviews that saved the author time from burrowing down the > wrong hole. > > Is this possible? Is this desirable to others, too? > > Thanks, > Richard > > On Jan 18, 2016, at 12:09 PM, Thomas Miedema wrote: > > On Mon, Jan 18, 2016 at 5:49 PM, Jan Stolarek wrote: > > > If you are working from an old base commit, either rebase your patch > > > before submitting to Phabricator (painful? you will have to do it > > > before pushing anyway, might as well do it now), or ignore the > > > Harbormaster validate result. > > > > I am typically working on some non-trivial features (ie. rebases tend to > > be painful). Having Harbormaster build results is a useful way of telling > > whether I broke something or not. Even if it is for some older commit. > > Rebases take time and if I know my feature will not be finished in the > > next couple of weeks I want to save myself from unnecessary rebasing. Why > > rebase all the time if I can do it just once at the end? > > > > There are a few options: > > > > * you validate locally (in a different build directory, so you can keep > > using build flavour = devel2 in your development directory) * fork the > > ghc github repository, push your branch there, and let Travis validate > > it: https://ghc.haskell.org/trac/ghc/wiki/TestingPatches#Travis * ask > > Austin for some special Phabricator syntax that you could add when you > > submit the patch, to request Harbormaster not to rebase onto HEAD before > > validating > > > > > > Side note: I think we should go back to using Phabricator for finished > > patches only. It slows the review process down, when there are 50 patches > > in the queue waiting-for-review-but-not-really: > > https://phabricator.haskell.org/differential/query/bITEu.ig1Hep/ > > Sometimes it leads to finished patches actually getting ignored for a > > long time, because the reviewers still think the author is working on > > them. But other might think differently, and maybe it's not a big deal. > > > > > > > > > > > > Janek > > > > --- > > Politechnika ??dzka > > Lodz University of Technology > > > > Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. > > Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez > > pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. > > > > This email contains information intended solely for the use of the > > individual to whom it is addressed. If you are not the intended recipient > > or if you have received this message in error, please notify the sender > > and delete it from your system. > > > > _______________________________________________ > > 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 conal at conal.net Mon Jan 18 17:46:48 2016 From: conal at conal.net (Conal Elliott) Date: Mon, 18 Jan 2016 09:46:48 -0800 Subject: ghci and unfoldings? In-Reply-To: <5c482fcab11747b2aba28814f2f367d4@AM3PR30MB019.064d.mgd.msft.net> References: <1453098976-sup-8811@sabre> <5c482fcab11747b2aba28814f2f367d4@AM3PR30MB019.064d.mgd.msft.net> Message-ID: That's the flag I would expect. It doesn't seem to help or hinder availability of unfoldings in GHCi. Do you think it should? And Happy Birthday, Simon! Warmly, - Conal On Monday, January 18, 2016, Simon Peyton Jones wrote: > Or -fexpose-all-unfoldings? > > Simon > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of > | Edward Z. Yang > | Sent: 18 January 2016 06:37 > | To: Conal Elliott > | Cc: Andrew Farmer ; ghc-devs at haskell.org > | Subject: Re: ghci and unfoldings? > | > | Does passing -fobject-code solve your problem? > | > | Edward > | > | Excerpts from Conal Elliott's message of 2016-01-17 22:18:49 -0800: > | > Hi Brandon. Thanks for the reply. I?m not sure that it addresses > | what > | > I was trying to ask. GHCi *does* invoke plugins and even reloads > | those > | > plugins dynamically when their source code changes. So in this sense > | > ghci does enable optimization, even if it doesn?t perform much > | > optimization on its own. And of course plugins and unfolding are not > | just about optimization. > | > > | > I?m not looking for ghci to do optimization, but rather to enable me > | > to more easily develop my GHC plugins. It?s *almost* there already. > | I > | > just need access to unfoldings from other modules for my plugin?s > | use. > | > > | > For context, I?m rebuilding my Haskell-to-hardware compiler > | > , which > | relies > | > on giving a non-standard but principled interpretation of Haskell > | > programs via a conversion through the language of cartesian closed > | categories (CCCs). > | > The first back-end is hardware generation (e.g., via Verilog), and I > | > have plans for several other CCC-based interpretations. > | > > | > In addition to facilitating my plugin development, hosting in ghci > | > will make it much more pleasant for others to *use* the plugin > | during > | > exploratory programming, just as with ghci use in general. With > | access > | > to unfoldings, users will be able to generate circuit diagrams and > | > Verilog like those in my compiler talk immediately and directly from > | > within ghci. I also intend to make a GPU back-end for fast > | interactive > | > graphics etc, which would be much more fun in ghci than with batch > | compilation. > | > I hope this explanation clarifies my goals and motivation. I hope > | > there?s a way to access unfoldings from ghci currently or with a > | small > | > amount of effort. > | > > | > Regards, - Conal > | > > | > On Sun, Jan 17, 2016 at 7:00 PM, Brandon Allbery > | > | > wrote: > | > > | > > On Sun, Jan 17, 2016 at 9:40 PM, Conal Elliott > | wrote: > | > > > | > >> I'm developing a GHC plugin (using HERMIT), and I'd like to use > | > >> ghci to speed up development. I'm able to do so, except that my > | > >> plugin critically needs access to unfoldings, which appear to be > | > >> unavailable in ghci. A little experimenting with ghc shows me > | that > | > >> "-O" is the key, but "-O" is incompatible with "--interactive" > | (as > | > >> in ghci). Is there any way to persuade ghci to make unfoldings > | available? > | > > > | > > > | > > I think unfoldings are only done as part of optimization, and the > | > > bytecode backend doesn't support optimization at all. > | > > > | > > -- > | > > brandon s allbery kf8nh sine nomine > | > > associates > | > > allbery.b at gmail.com > | > > ballbery at sinenomine.net > | > > unix, openafs, kerberos, infrastructure, xmonad > | > > > | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fsine > | > > > | nomine.net&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cbaf2ef5 > | > > > | 5f8af447b42e608d31fd1cec1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sda > | > > ta=qMNmL5LmkgMp0ebkr6SzPQIwhySqOicZgEdW%2fhe6Q%2b0%3d > | > > > | _______________________________________________ > | 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%0a&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cbaf2ef55f8af > | 447b42e608d31fd1cec1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=veoz > | Ab6M7N9jZaJZ9tgXZ%2fI8jq7U%2b4YM1FcSXvqTcaw%3d > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iavor.diatchki at gmail.com Mon Jan 18 17:52:36 2016 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Mon, 18 Jan 2016 09:52:36 -0800 Subject: equality relations: user-facing pretty-printing question In-Reply-To: References: Message-ID: Hello, What's the difference between `~~` and `~#` (I assume `~#` is heterogeneous)? As for the rest, as far as I understand, `~` is a strict subset of `~~` in the sense that: 1. if `a ~ b`, then `a ~~ b` 2. if `not (a ~ b)`, then `not (a ~~ b)` 3. if `a ~ b` is a kind error (i.e., the kind of `a` is known to be different from the kind of `b`), then `not (a ~~ b)` So, perhaps it makes sense to have a "smart" pretty printer for `a ~ b`: if kindOf a == kindOf b then `a ~ b` else `a ~~ b` -Iavor On Mon, Jan 18, 2016 at 9:24 AM, Ryan Scott wrote: > In my ideal world, GHC would remember as much as what the user wrote > as possible in printing error messages. So if the user writes: > > f :: Int ~ Char => ... > > Then GHC would remember that the context was written with a single > tilde, and print out Int ~ Char in the error message explicitly > wherever the full type signature of f is printed. > > What it sounds like, though, is that deep in the guts of the type > inferencer, there's a chance that single-tilde equality might turn > into double-tilde or tilde-hash equality at some point. In those > cases, printing out the particular brand of tilde might get confusing. > In such cases, we might compromise and print out something neutral > like "is equal to". I suppose this would always be the case if you > didn't explicitly write a ~ b and had to infer it. > > I'm not sure about the technical details of this though, i.e., if GHC > actually remembers a ~ b all the way through the > typechecking/inferencing pipeline. > > Ryan S. > _______________________________________________ > 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: From eir at cis.upenn.edu Mon Jan 18 17:55:34 2016 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 18 Jan 2016 12:55:34 -0500 Subject: equality relations: user-facing pretty-printing question In-Reply-To: References: Message-ID: <0F29F548-B67E-4C9B-80AB-DEB44F2158FF@cis.upenn.edu> I like that idea. Do others? Yes, agreed about the difference between ~ and ~~. ~# is unlifted, and is now the type that the solver works on. ~~ is lifted. That's the only difference. But the fact that ~~ is lifted is what allows you to put it in a constraint, because all constraints are lifted. Users should never bother with ~#, but they might with ~~. Richard On Jan 18, 2016, at 12:52 PM, Iavor Diatchki wrote: > Hello, > > What's the difference between `~~` and `~#` (I assume `~#` is heterogeneous)? > > As for the rest, as far as I understand, `~` is a strict subset of `~~` in the sense that: > 1. if `a ~ b`, then `a ~~ b` > 2. if `not (a ~ b)`, then `not (a ~~ b)` > 3. if `a ~ b` is a kind error (i.e., the kind of `a` is known to be different from the kind of `b`), then `not (a ~~ b)` > > So, perhaps it makes sense to have a "smart" pretty printer for `a ~ b`: > > if kindOf a == kindOf b then `a ~ b` else `a ~~ b` > > -Iavor > > > > > > > > On Mon, Jan 18, 2016 at 9:24 AM, Ryan Scott wrote: > In my ideal world, GHC would remember as much as what the user wrote > as possible in printing error messages. So if the user writes: > > f :: Int ~ Char => ... > > Then GHC would remember that the context was written with a single > tilde, and print out Int ~ Char in the error message explicitly > wherever the full type signature of f is printed. > > What it sounds like, though, is that deep in the guts of the type > inferencer, there's a chance that single-tilde equality might turn > into double-tilde or tilde-hash equality at some point. In those > cases, printing out the particular brand of tilde might get confusing. > In such cases, we might compromise and print out something neutral > like "is equal to". I suppose this would always be the case if you > didn't explicitly write a ~ b and had to infer it. > > I'm not sure about the technical details of this though, i.e., if GHC > actually remembers a ~ b all the way through the > typechecking/inferencing pipeline. > > Ryan S. > _______________________________________________ > 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: From kane at kane.cx Mon Jan 18 18:02:25 2016 From: kane at kane.cx (David Kraeutmann) Date: Mon, 18 Jan 2016 19:02:25 +0100 Subject: equality relations: user-facing pretty-printing question In-Reply-To: <0F29F548-B67E-4C9B-80AB-DEB44F2158FF@cis.upenn.edu> References: <0F29F548-B67E-4C9B-80AB-DEB44F2158FF@cis.upenn.edu> Message-ID: <569D28B1.8020909@kane.cx> If ~# is hidden from the user, I think it's reasonable to hide it as an implementation detail. The idea Iavor had sounds good, but we can get (potentially) confusing error messages when writing `Int ~~ Char => ...` -- the smart pretty printer would print `Int ~ Char`. Might get a bit messy. On 1/18/2016 6:55 PM, Richard Eisenberg wrote: > I like that idea. Do others? > > Yes, agreed about the difference between ~ and ~~. > > ~# is unlifted, and is now the type that the solver works on. ~~ is lifted. That's the only difference. But the fact that ~~ is lifted is what allows you to put it in a constraint, because all constraints are lifted. Users should never bother with ~#, but they might with ~~. > > Richard > > On Jan 18, 2016, at 12:52 PM, Iavor Diatchki wrote: > > > Hello, > > > > What's the difference between `~~` and `~#` (I assume `~#` is heterogeneous)? > > > > As for the rest, as far as I understand, `~` is a strict subset of `~~` in the sense that: > > 1. if `a ~ b`, then `a ~~ b` > > 2. if `not (a ~ b)`, then `not (a ~~ b)` > > 3. if `a ~ b` is a kind error (i.e., the kind of `a` is known to be different from the kind of `b`), then `not (a ~~ b)` > > > > So, perhaps it makes sense to have a "smart" pretty printer for `a ~ b`: > > > > if kindOf a == kindOf b then `a ~ b` else `a ~~ b` > > > > -Iavor > > > > > > > > > > > > > > > > On Mon, Jan 18, 2016 at 9:24 AM, Ryan Scott wrote: > > In my ideal world, GHC would remember as much as what the user wrote > > as possible in printing error messages. So if the user writes: > > > > f :: Int ~ Char => ... > > > > Then GHC would remember that the context was written with a single > > tilde, and print out Int ~ Char in the error message explicitly > > wherever the full type signature of f is printed. > > > > What it sounds like, though, is that deep in the guts of the type > > inferencer, there's a chance that single-tilde equality might turn > > into double-tilde or tilde-hash equality at some point. In those > > cases, printing out the particular brand of tilde might get confusing. > > In such cases, we might compromise and print out something neutral > > like "is equal to". I suppose this would always be the case if you > > didn't explicitly write a ~ b and had to infer it. > > > > I'm not sure about the technical details of this though, i.e., if GHC > > actually remembers a ~ b all the way through the > > typechecking/inferencing pipeline. > > > > Ryan S. > > _______________________________________________ > > 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4291 bytes Desc: S/MIME Cryptographic Signature URL: From ryan.gl.scott at gmail.com Mon Jan 18 18:02:47 2016 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Mon, 18 Jan 2016 13:02:47 -0500 Subject: equality relations: user-facing pretty-printing question In-Reply-To: <0F29F548-B67E-4C9B-80AB-DEB44F2158FF@cis.upenn.edu> References: <0F29F548-B67E-4C9B-80AB-DEB44F2158FF@cis.upenn.edu> Message-ID: That sounds like a great idea to me. Ryan S. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at seidel.io Mon Jan 18 18:12:24 2016 From: eric at seidel.io (Eric Seidel) Date: Mon, 18 Jan 2016 10:12:24 -0800 Subject: kind of type equalities (was: equality relations: user-facing pretty-printing question) In-Reply-To: <0F29F548-B67E-4C9B-80AB-DEB44F2158FF@cis.upenn.edu> References: <0F29F548-B67E-4C9B-80AB-DEB44F2158FF@cis.upenn.edu> Message-ID: <1453140744.285827.495475898.4D6AEE7D@webmail.messagingengine.com> This is a bit tangential, but I find it odd that we care about whether a type equality has kind Lifted or Unlifted. As I understand, the Lifted/Unlifted distinction exists so that we know whether we have a thunk (and by extension a pointer of a constant size) or the thing itself (the size depends on the type). So Lifted/Unlifted is primarily important for code-gen and runtime purposes. Type equalities, on the other hand, shouldn't exist at runtime as the types are erased. So why do we care whether a type equality is a thunk? My guess is that we only care because type equalities *do* exist in Core as proof terms, so they need to be well-kinded, but this isn't a very satisfying answer. On Mon, Jan 18, 2016, at 09:55, Richard Eisenberg wrote: > I like that idea. Do others? > > Yes, agreed about the difference between ~ and ~~. > > ~# is unlifted, and is now the type that the solver works on. ~~ is > lifted. That's the only difference. But the fact that ~~ is lifted is > what allows you to put it in a constraint, because all constraints are > lifted. Users should never bother with ~#, but they might with ~~. > > Richard > > On Jan 18, 2016, at 12:52 PM, Iavor Diatchki > wrote: > > > Hello, > > > > What's the difference between `~~` and `~#` (I assume `~#` is heterogeneous)? > > > > As for the rest, as far as I understand, `~` is a strict subset of `~~` in the sense that: > > 1. if `a ~ b`, then `a ~~ b` > > 2. if `not (a ~ b)`, then `not (a ~~ b)` > > 3. if `a ~ b` is a kind error (i.e., the kind of `a` is known to be different from the kind of `b`), then `not (a ~~ b)` > > > > So, perhaps it makes sense to have a "smart" pretty printer for `a ~ b`: > > > > if kindOf a == kindOf b then `a ~ b` else `a ~~ b` > > > > -Iavor > > > > > > > > > > > > > > > > On Mon, Jan 18, 2016 at 9:24 AM, Ryan Scott wrote: > > In my ideal world, GHC would remember as much as what the user wrote > > as possible in printing error messages. So if the user writes: > > > > f :: Int ~ Char => ... > > > > Then GHC would remember that the context was written with a single > > tilde, and print out Int ~ Char in the error message explicitly > > wherever the full type signature of f is printed. > > > > What it sounds like, though, is that deep in the guts of the type > > inferencer, there's a chance that single-tilde equality might turn > > into double-tilde or tilde-hash equality at some point. In those > > cases, printing out the particular brand of tilde might get confusing. > > In such cases, we might compromise and print out something neutral > > like "is equal to". I suppose this would always be the case if you > > didn't explicitly write a ~ b and had to infer it. > > > > I'm not sure about the technical details of this though, i.e., if GHC > > actually remembers a ~ b all the way through the > > typechecking/inferencing pipeline. > > > > Ryan S. > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From eir at cis.upenn.edu Mon Jan 18 18:26:48 2016 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 18 Jan 2016 13:26:48 -0500 Subject: kind of type equalities (was: equality relations: user-facing pretty-printing question) In-Reply-To: <1453140744.285827.495475898.4D6AEE7D@webmail.messagingengine.com> References: <0F29F548-B67E-4C9B-80AB-DEB44F2158FF@cis.upenn.edu> <1453140744.285827.495475898.4D6AEE7D@webmail.messagingengine.com> Message-ID: <02CB6B1B-F0CC-483A-8A6C-FFA52B9311DB@cis.upenn.edu> And lifted ones can exist at runtime, via deferred type errors. With deferred type errors, a lifted equality might be a thunk that evaluates to a type error. I also think that "because Core needs it" is a satisfying answer. That's why we have coercions. If we didn't care about type-checking Core, we could just omit very large swathes of GHC. But then we'd have a non-working compiler. :) Richard On Jan 18, 2016, at 1:12 PM, Eric Seidel wrote: > This is a bit tangential, but I find it odd that we care about whether a > type equality has kind Lifted or Unlifted. > > As I understand, the Lifted/Unlifted distinction exists so that we know > whether we have a thunk (and by extension a pointer of a constant size) > or the thing itself (the size depends on the type). So Lifted/Unlifted > is primarily important for code-gen and runtime purposes. Type > equalities, on the other hand, shouldn't exist at runtime as the types > are erased. > > So why do we care whether a type equality is a thunk? My guess is that > we only care because type equalities *do* exist in Core as proof terms, > so they need to be well-kinded, but this isn't a very satisfying answer. > > > On Mon, Jan 18, 2016, at 09:55, Richard Eisenberg wrote: >> I like that idea. Do others? >> >> Yes, agreed about the difference between ~ and ~~. >> >> ~# is unlifted, and is now the type that the solver works on. ~~ is >> lifted. That's the only difference. But the fact that ~~ is lifted is >> what allows you to put it in a constraint, because all constraints are >> lifted. Users should never bother with ~#, but they might with ~~. >> >> Richard >> >> On Jan 18, 2016, at 12:52 PM, Iavor Diatchki >> wrote: >> >>> Hello, >>> >>> What's the difference between `~~` and `~#` (I assume `~#` is heterogeneous)? >>> >>> As for the rest, as far as I understand, `~` is a strict subset of `~~` in the sense that: >>> 1. if `a ~ b`, then `a ~~ b` >>> 2. if `not (a ~ b)`, then `not (a ~~ b)` >>> 3. if `a ~ b` is a kind error (i.e., the kind of `a` is known to be different from the kind of `b`), then `not (a ~~ b)` >>> >>> So, perhaps it makes sense to have a "smart" pretty printer for `a ~ b`: >>> >>> if kindOf a == kindOf b then `a ~ b` else `a ~~ b` >>> >>> -Iavor >>> >>> >>> >>> >>> >>> >>> >>> On Mon, Jan 18, 2016 at 9:24 AM, Ryan Scott wrote: >>> In my ideal world, GHC would remember as much as what the user wrote >>> as possible in printing error messages. So if the user writes: >>> >>> f :: Int ~ Char => ... >>> >>> Then GHC would remember that the context was written with a single >>> tilde, and print out Int ~ Char in the error message explicitly >>> wherever the full type signature of f is printed. >>> >>> What it sounds like, though, is that deep in the guts of the type >>> inferencer, there's a chance that single-tilde equality might turn >>> into double-tilde or tilde-hash equality at some point. In those >>> cases, printing out the particular brand of tilde might get confusing. >>> In such cases, we might compromise and print out something neutral >>> like "is equal to". I suppose this would always be the case if you >>> didn't explicitly write a ~ b and had to infer it. >>> >>> I'm not sure about the technical details of this though, i.e., if GHC >>> actually remembers a ~ b all the way through the >>> typechecking/inferencing pipeline. >>> >>> Ryan S. >>> _______________________________________________ >>> 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 > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From conal at conal.net Mon Jan 18 18:28:37 2016 From: conal at conal.net (Conal Elliott) Date: Mon, 18 Jan 2016 10:28:37 -0800 Subject: ghci and unfoldings? In-Reply-To: References: <1453098976-sup-8811@sabre> <5c482fcab11747b2aba28814f2f367d4@AM3PR30MB019.064d.mgd.msft.net> Message-ID: The minimum flags I've found to get ghci to provide unfoldings are -O and -object-code. And it appears that both flags need to be present the first time I load a module into GHCi. (I'm putting the flags in an OPTIONS_GHC pragma.) On Mon, Jan 18, 2016 at 9:46 AM, Conal Elliott wrote: > That's the flag I would expect. It doesn't seem to help or hinder > availability of unfoldings in GHCi. Do you think it should? > > And Happy Birthday, Simon! > > Warmly, - Conal > > > On Monday, January 18, 2016, Simon Peyton Jones > wrote: > >> Or -fexpose-all-unfoldings? >> >> Simon >> >> | -----Original Message----- >> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of >> | Edward Z. Yang >> | Sent: 18 January 2016 06:37 >> | To: Conal Elliott >> | Cc: Andrew Farmer ; ghc-devs at haskell.org >> | Subject: Re: ghci and unfoldings? >> | >> | Does passing -fobject-code solve your problem? >> | >> | Edward >> | >> | Excerpts from Conal Elliott's message of 2016-01-17 22:18:49 -0800: >> | > Hi Brandon. Thanks for the reply. I?m not sure that it addresses >> | what >> | > I was trying to ask. GHCi *does* invoke plugins and even reloads >> | those >> | > plugins dynamically when their source code changes. So in this sense >> | > ghci does enable optimization, even if it doesn?t perform much >> | > optimization on its own. And of course plugins and unfolding are not >> | just about optimization. >> | > >> | > I?m not looking for ghci to do optimization, but rather to enable me >> | > to more easily develop my GHC plugins. It?s *almost* there already. >> | I >> | > just need access to unfoldings from other modules for my plugin?s >> | use. >> | > >> | > For context, I?m rebuilding my Haskell-to-hardware compiler >> | > , which >> | relies >> | > on giving a non-standard but principled interpretation of Haskell >> | > programs via a conversion through the language of cartesian closed >> | categories (CCCs). >> | > The first back-end is hardware generation (e.g., via Verilog), and I >> | > have plans for several other CCC-based interpretations. >> | > >> | > In addition to facilitating my plugin development, hosting in ghci >> | > will make it much more pleasant for others to *use* the plugin >> | during >> | > exploratory programming, just as with ghci use in general. With >> | access >> | > to unfoldings, users will be able to generate circuit diagrams and >> | > Verilog like those in my compiler talk immediately and directly from >> | > within ghci. I also intend to make a GPU back-end for fast >> | interactive >> | > graphics etc, which would be much more fun in ghci than with batch >> | compilation. >> | > I hope this explanation clarifies my goals and motivation. I hope >> | > there?s a way to access unfoldings from ghci currently or with a >> | small >> | > amount of effort. >> | > >> | > Regards, - Conal >> | > >> | > On Sun, Jan 17, 2016 at 7:00 PM, Brandon Allbery >> | >> | > wrote: >> | > >> | > > On Sun, Jan 17, 2016 at 9:40 PM, Conal Elliott >> | wrote: >> | > > >> | > >> I'm developing a GHC plugin (using HERMIT), and I'd like to use >> | > >> ghci to speed up development. I'm able to do so, except that my >> | > >> plugin critically needs access to unfoldings, which appear to be >> | > >> unavailable in ghci. A little experimenting with ghc shows me >> | that >> | > >> "-O" is the key, but "-O" is incompatible with "--interactive" >> | (as >> | > >> in ghci). Is there any way to persuade ghci to make unfoldings >> | available? >> | > > >> | > > >> | > > I think unfoldings are only done as part of optimization, and the >> | > > bytecode backend doesn't support optimization at all. >> | > > >> | > > -- >> | > > brandon s allbery kf8nh sine nomine >> | > > associates >> | > > allbery.b at gmail.com >> | > > ballbery at sinenomine.net >> | > > unix, openafs, kerberos, infrastructure, xmonad >> | > > >> | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fsine >> | > > >> | nomine.net&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cbaf2ef5 >> | > > >> | 5f8af447b42e608d31fd1cec1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sda >> | > > ta=qMNmL5LmkgMp0ebkr6SzPQIwhySqOicZgEdW%2fhe6Q%2b0%3d >> | > > >> | _______________________________________________ >> | 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%0a&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cbaf2ef55f8af >> | 447b42e608d31fd1cec1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=veoz >> | Ab6M7N9jZaJZ9tgXZ%2fI8jq7U%2b4YM1FcSXvqTcaw%3d >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at seidel.io Mon Jan 18 18:45:35 2016 From: eric at seidel.io (Eric Seidel) Date: Mon, 18 Jan 2016 10:45:35 -0800 Subject: kind of type equalities (was: equality relations: user-facing pretty-printing question) In-Reply-To: <02CB6B1B-F0CC-483A-8A6C-FFA52B9311DB@cis.upenn.edu> References: <0F29F548-B67E-4C9B-80AB-DEB44F2158FF@cis.upenn.edu> <1453140744.285827.495475898.4D6AEE7D@webmail.messagingengine.com> <02CB6B1B-F0CC-483A-8A6C-FFA52B9311DB@cis.upenn.edu> Message-ID: <1453142735.292218.495506050.7D899DFE@webmail.messagingengine.com> On Mon, Jan 18, 2016, at 10:26, Richard Eisenberg wrote: > And lifted ones can exist at runtime, via deferred type errors. With > deferred type errors, a lifted equality might be a thunk that evaluates > to a type error. Ah, fair point. > I also think that "because Core needs it" is a satisfying answer. That's > why we have coercions. If we didn't care about type-checking Core, we > could just omit very large swathes of GHC. But then we'd have a > non-working compiler. :) I should have elaborated on why I find it unsatisfying :) My point was not that type-checking Core is not desirable enough to warrant tracking the kind of a type equality, rather that perhaps there's a simpler way that doesn't include runtime concerns. For example, perhaps type equalities could have their own kind. But it sounds like we can't actually separate equalities from code-gen/runtime. From allbery.b at gmail.com Mon Jan 18 19:52:00 2016 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 18 Jan 2016 14:52:00 -0500 Subject: Phab failing to apply patches In-Reply-To: References: <201601151849.14883.jan.stolarek@p.lodz.pl> <201601171624.52669.jan.stolarek@p.lodz.pl> <201601181749.17735.jan.stolarek@p.lodz.pl> Message-ID: On Mon, Jan 18, 2016 at 12:09 PM, Thomas Miedema wrote: > * you validate locally (in a different build directory, so you can keep > using build flavour = devel2 in your development directory) > * fork the ghc github repository, push your branch there, and let Travis > validate it: https://ghc.haskell.org/trac/ghc/wiki/TestingPatches#Travis > > * ask Austin for some special Phabricator syntax that you could add when > you submit the patch, to request Harbormaster not to rebase onto HEAD > before validating > Seems to me that, if Harbormaster is already overloaded, the second option should be preferred. Offloading from one limited resource (local machine) to another that is also shared seems like a lose for everyone. -- 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: From omeragacan at gmail.com Mon Jan 18 20:10:49 2016 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Mon, 18 Jan 2016 15:10:49 -0500 Subject: How to build profiled stage1? Message-ID: I'm trying to debug my stage1 compiler and as a last resort I'm trying to build stage1 compiler using `-prof -fprof-auto` to be able to do `+RTS -xc -RTS` during the stage2 build. I tried couple of things but they all failed in different ways. As far as I understand, both SRC_HC_OPTS and GhcStage1HcOpts are passed to system-wide installed ghc during the stage1 build and libraries. So I do one of these changes: SRC_HC_OPTS = -O -H64m -prof -fprof-auto GhcStage1HcOpts = -O0 -DDEBUG -prof -fprof-auto The second change I want to make is I want to pass `+RTS -xc -RTS` to ghc-stage1, for that I'm making this change: GhcLibHcOpts = -O -dcore-lint -prof -fprof-auto But, no matter what else I change, I can't get past this stage: "/usr/local/bin/ghc" -hisuf hi -osuf o -hcsuf hc -static -O -H64m -Wall -package-db libraries/bootstrapping.conf -this-package-key ghc-8.1 -hide-all-packages -i -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage1/build -icompiler/stage1/build/autogen -Icompiler/stage1/build -Icompiler/stage1/build/autogen -Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/stage1 -optP-include -optPcompiler/stage1/build/autogen/cabal_macros.h -package-id array-0.5.1.0-960bf9ae8875cc30355e086f8853a049 -package-id base-4.8.2.0-0d6d1084fbc041e1cded9228e80e264d -package-id binary-0.8.0.0 -package-id bytestring-0.10.6.0-9a873bcf33d6ce2fd2698ce69e2c1c66 -package-id containers-0.5.6.2-59326c33e30ec8f6afd574cbac625bbb -package-id directory-1.2.2.0-660a7a83a753ed85c8a374c15dae2b97 -package-id filepath-1.4.0.0-f97d1e4aebfd7a03be6980454fe31d6e -package-id ghc-boot-8.1 -package-id hoopl-3.10.2.1 -package-id hpc-0.6.0.3 -package-id process-1.2.3.0-a22328103774f0499a990653944cbf99 -package-id template-haskell-2.11.0.0 -package-id time-1.5.0.1-1b9a502bb07a3e6f4d6935fbf9db7181 -package-id transformers-0.5.0.0 -package-id unix-2.7.1.0-bb54ee8f9f6b2600aae7a748eb88a610 -Wall -fno-warn-name-shadowing -this-package-key ghc -XHaskell2010 -DSTAGE=1 -Rghc-timing -O0 -DDEBUG -prof -fprof-auto -no-user-package-db -rtsopts -odir compiler/stage1/build -hidir compiler/stage1/build -stubdir compiler/stage1/build -c compiler/utils/Exception.hs -o compiler/stage1/build/Exception.o compiler/utils/Exception.hs:10:1: Failed to load interface for ?Control.Monad.IO.Class? Perhaps you haven't installed the profiling libraries for package ?transformers-0.5.0.0?? Use -v to see a list of the files searched for. <> I tried enabling library-profiling in my global Cabal config, but that didn't help. Any ideas how to do this? If it matters, I'm on Linux. NOTE: If I pass -v to GHC, it lists this place in the list of locations searched: /home/omer/haskell/ghc_unboxed_sums/libraries/transformers/dist-boot/build/Control/Monad/IO/Class.p_hi Indeed, the file is not there. When I look at all the command the build system run at this point, I see lines like this: "/usr/local/bin/ghc-pkg" update --force --package-db=libraries/bootstrapping.conf libraries/transformers/dist-boot/inplace-pkg-config Reading package info from "libraries/transformers/dist-boot/inplace-pkg-config" ... done. transformers-0.5.0.0: Warning: Unrecognized field abi on line 47 transformers-0.5.0.0: Warning: haddock-interfaces: /home/omer/haskell/ghc_unboxed_sums/libraries/transformers/dist-boot/doc/html/transformers/transformers.haddock doesn't exist or isn't a file transformers-0.5.0.0: cannot find any of ["Control/Applicative/Backwards.hi","Control/Applicative/Backwards.p_hi","Control/Applicative/Backwards.dyn_hi"] (ignoring) transformers-0.5.0.0: cannot find any of ["Control/Applicative/Lift.hi","Control/Applicative/Lift.p_hi","Control/Applicative/Lift.dyn_hi"] (ignoring) transformers-0.5.0.0: cannot find any of ["Control/Monad/Signatures.hi","Control/Monad/Signatures.p_hi","Control/Monad/Signatures.dyn_hi"] (ignoring) transformers-0.5.0.0: cannot find any of ["Control/Monad/Trans/Class.hi","Control/Monad/Trans/Class.p_hi","Control/Monad/Trans/Class.dyn_hi"] (ignoring) transformers-0.5.0.0: cannot find any of ["Control/Monad/Trans/Cont.hi","Control/Monad/Trans/Cont.p_hi","Control/Monad/Trans/Cont.dyn_hi"] (ignoring) transformers-0.5.0.0: cannot find any of ["Control/Monad/Trans/Except.hi","Control/Monad/Trans/Except.p_hi","Control/Monad/Trans/Except.dyn_hi"] (ignoring) transformers-0.5.0.0: cannot find any of ["Control/Monad/Trans/Error.hi","Control/Monad/Trans/Error.p_hi","Control/Monad/Trans/Error.dyn_hi"] (ignoring) transformers-0.5.0.0: cannot find any of ["Control/Monad/Trans/Identity.hi","Control/Monad/Trans/Identity.p_hi","Control/Monad/Trans/Identity.dyn_hi"] (ignoring) Then, after a while it's building transformers in a different way, using arguments like `-dep-makefile` etc. which are as far as I can see not documented in the GHC man page. When I look libraries/transformers I only see a directory named "dist-boot" with some weird files with ".haskell" extensions. I'm quite confused about how this is supposed to work. Can any of the build system experts help me here? This wiki page https://ghc.haskell.org/trac/ghc/wiki/Debugging/Compiler#Addingdebuggingcodetothecompiler says "if you have built a profiling compiler ..." but it doesn't say anything about how to actually build it. Thanks. From dsf at seereason.com Mon Jan 18 20:16:44 2016 From: dsf at seereason.com (David Fox) Date: Mon, 18 Jan 2016 12:16:44 -0800 Subject: equality relations: user-facing pretty-printing question In-Reply-To: <0F29F548-B67E-4C9B-80AB-DEB44F2158FF@cis.upenn.edu> References: <0F29F548-B67E-4C9B-80AB-DEB44F2158FF@cis.upenn.edu> Message-ID: It is better, but you still might write ~~ and see an error message with ~, right? On Mon, Jan 18, 2016 at 9:55 AM, Richard Eisenberg wrote: > I like that idea. Do others? > > Yes, agreed about the difference between ~ and ~~. > > ~# is unlifted, and is now the type that the solver works on. ~~ is > lifted. That's the only difference. But the fact that ~~ is lifted is what > allows you to put it in a constraint, because all constraints are lifted. > Users should never bother with ~#, but they might with ~~. > > Richard > > On Jan 18, 2016, at 12:52 PM, Iavor Diatchki > wrote: > > Hello, > > What's the difference between `~~` and `~#` (I assume `~#` is > heterogeneous)? > > As for the rest, as far as I understand, `~` is a strict subset of `~~` in > the sense that: > 1. if `a ~ b`, then `a ~~ b` > 2. if `not (a ~ b)`, then `not (a ~~ b)` > 3. if `a ~ b` is a kind error (i.e., the kind of `a` is known to be > different from the kind of `b`), then `not (a ~~ b)` > > So, perhaps it makes sense to have a "smart" pretty printer for `a ~ b`: > > if kindOf a == kindOf b then `a ~ b` else `a ~~ b` > > -Iavor > > > > > > > > On Mon, Jan 18, 2016 at 9:24 AM, Ryan Scott > wrote: > >> In my ideal world, GHC would remember as much as what the user wrote >> as possible in printing error messages. So if the user writes: >> >> f :: Int ~ Char => ... >> >> Then GHC would remember that the context was written with a single >> tilde, and print out Int ~ Char in the error message explicitly >> wherever the full type signature of f is printed. >> >> What it sounds like, though, is that deep in the guts of the type >> inferencer, there's a chance that single-tilde equality might turn >> into double-tilde or tilde-hash equality at some point. In those >> cases, printing out the particular brand of tilde might get confusing. >> In such cases, we might compromise and print out something neutral >> like "is equal to". I suppose this would always be the case if you >> didn't explicitly write a ~ b and had to infer it. >> >> I'm not sure about the technical details of this though, i.e., if GHC >> actually remembers a ~ b all the way through the >> typechecking/inferencing pipeline. >> >> Ryan S. >> _______________________________________________ >> 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: From simonpj at microsoft.com Tue Jan 19 00:22:00 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 19 Jan 2016 00:22:00 +0000 Subject: Birthday greetings Message-ID: <24cb1cf0044b4144bebb2a1a7b7efd6a@DB4PR30MB030.064d.mgd.msft.net> Dear GHC devs (all 600+ of you), It?s my birthday (well it was a few minutes ago, but I became distracted by #11379). I am 58. GHC is alive and well and, happily, so am I. However, of late I have found that my GHC inbox, which I used to be able to keep under control, just grows and grows. Mostly this is good; it reflects the fact that GHC has lots of users, that they vigorously expand up to (and often well beyond) the limits of what GHC can do, and that increasingly GHC a lot of developers contributing actively to its code base. But it has its downsides. I used to be able to keep up with the Trac and email traffic. Trusty techniques like ?delete anything mentioning ?dynamic linking? or ?Unicode?? would cut the traffic in half. But that doesn?t work any more. Too many interesting things are happening. So this email is to say three things: ? First, thank you to the increasingly large number of you who are contributing actively to GHC?s development. GHC is a big system, and no one person can be on top of all of it. GHC no longer depends on one of two people: it depends on all of you. You know who you are ? thank you. ? Second, apologies to anyone who is stuck waiting for me. Although there are large chunks of GHC that I know little about, there are other parts that are dear to my heart: the renamer, typechecker, Core, optimisation, and so on. I write code most days and enjoy it. So I do want to continue to play a very active supporting and reviewing role, as well as authoring, in these parts. But I?m conscious that doing so puts me in a lot of critical paths. Here?s a suggestion: if you are blocked on something from me, email me directly. By all means copy ghc-devs if you want others in the conversation, but make it clear that you need my input. That?ll work better than putting up a Phab review, or a Trac comment, and hoping I?ll see it. I probably will, but it won?t stick out from other 20 Phab reviews that I would like to do. I don?t promise to turn everything around fast, but it?ll increase the chances! ? Third, in a vain attempt to at least keep some kind of handle on the state of play, I keep an ill-organised page of tickets that I?m interested in. A cursory glance will confirm that there is zero chance that I will attend to them all. So please do pick up some of them and dig in. Not many are trivial; most require some investigation, some design work, some discussion of alternatives, etc. But most of them would benefit from love and attention. If you are looking for suggestions for things to do, that might be a good place to start. Thanks! Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From chak at justtesting.org Tue Jan 19 01:50:44 2016 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Tue, 19 Jan 2016 12:50:44 +1100 Subject: Birthday greetings In-Reply-To: <24cb1cf0044b4144bebb2a1a7b7efd6a@DB4PR30MB030.064d.mgd.msft.net> References: <24cb1cf0044b4144bebb2a1a7b7efd6a@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <3FE3DDB1-7FB4-4FB5-96ED-502E99AA89A1@justtesting.org> Dear Simon! Happy Birthday!!! :) Thank you so much for all the incredible work that you have done and the guidance that you have provided over the many years. I personally have profited enormously from your kindness, and I am very grateful for that. In addition, your unwavering enthusiasm for and work on GHC, in particular, and functional programming, in general, have always been a great inspiration. Thank you very much and all the best for this and many more years!! Manuel PS: I have declared email defeat long ago. I am impressed that you could keep up with it for so long. > Simon Peyton Jones : > > Dear GHC devs (all 600+ of you), > > It?s my birthday (well it was a few minutes ago, but I became distracted by #11379). I am 58. GHC is alive and well and, happily, so am I. > > However, of late I have found that my GHC inbox, which I used to be able to keep under control, just grows and grows. Mostly this is good; it reflects the fact that GHC has lots of users, that they vigorously expand up to (and often well beyond) the limits of what GHC can do, and that increasingly GHC a lot of developers contributing actively to its code base. > > But it has its downsides. I used to be able to keep up with the Trac and email traffic. Trusty techniques like ?delete anything mentioning ?dynamic linking? or ?Unicode?? would cut the traffic in half. But that doesn?t work any more. Too many interesting things are happening. > > So this email is to say three things: > > ? First, thank you to the increasingly large number of you who are contributing actively to GHC?s development. GHC is a big system, and no one person can be on top of all of it. GHC no longer depends on one of two people: it depends on all of you. You know who you are ? thank you. > > ? Second, apologies to anyone who is stuck waiting for me. Although there are large chunks of GHC that I know little about, there are other parts that are dear to my heart: the renamer, typechecker, Core, optimisation, and so on. I write code most days and enjoy it. So I do want to continue to play a very active supporting and reviewing role, as well as authoring, in these parts. But I?m conscious that doing so puts me in a lot of critical paths. > > Here?s a suggestion: if you are blocked on something from me, email me directly. By all means copy ghc-devs if you want others in the conversation, but make it clear that you need my input. That?ll work better than putting up a Phab review, or a Trac comment, and hoping I?ll see it. I probably will, but it won?t stick out from other 20 Phab reviews that I would like to do. I don?t promise to turn everything around fast, but it?ll increase the chances! > > ? Third, in a vain attempt to at least keep some kind of handle on the state of play, I keep an ill-organised page of tickets that I?m interested in . A cursory glance will confirm that there is zero chance that I will attend to them all. So please do pick up some of them and dig in. Not many are trivial; most require some investigation, some design work, some discussion of alternatives, etc. But most of them would benefit from love and attention. If you are looking for suggestions for things to do, that might be a good place to start. > > Thanks! > > Simon > > > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From cma at bitemyapp.com Tue Jan 19 02:01:36 2016 From: cma at bitemyapp.com (Christopher Allen) Date: Mon, 18 Jan 2016 20:01:36 -0600 Subject: Birthday greetings In-Reply-To: <24cb1cf0044b4144bebb2a1a7b7efd6a@DB4PR30MB030.064d.mgd.msft.net> References: <24cb1cf0044b4144bebb2a1a7b7efd6a@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Happy Birthday! Haskell is all the better for your work and direction and we've all benefited thereby. Your work has made computing more enjoyable for many :) On Mon, Jan 18, 2016 at 6:22 PM, Simon Peyton Jones wrote: > Dear GHC devs (all 600+ of you), > > It?s my birthday (well it was a few minutes ago, but I became distracted > by #11379). I am 58. GHC is alive and well and, happily, so am I. > > However, of late I have found that my GHC inbox, which I used to be able > to keep under control, just grows and grows. Mostly this is good; it > reflects the fact that GHC has lots of users, that they vigorously expand > up to (and often well beyond) the limits of what GHC can do, and that > increasingly GHC a lot of developers contributing actively to its code > base. > > But it has its downsides. I used to be able to keep up with the Trac and > email traffic. Trusty techniques like ?delete anything mentioning ?dynamic > linking? or ?Unicode?? would cut the traffic in half. But that doesn?t > work any more. Too many interesting things are happening. > > So this email is to say three things: > > ? First,* thank you* to the increasingly large number of you who > are contributing actively to GHC?s development. GHC is a big system, and > no one person can be on top of all of it. GHC no longer depends on one of > two people: it depends on all of you. You know who you are ? thank you. > > ? Second,* apologies* to anyone who is stuck waiting for me. > Although there are large chunks of GHC that I know little about, there are > other parts that are dear to my heart: the renamer, typechecker, Core, > optimisation, and so on. I write code most days and enjoy it. So I do > want to continue to play a very active supporting and reviewing role, as > well as authoring, in these parts. But I?m conscious that doing so puts me > in a lot of critical paths. > > Here?s a suggestion: if you are blocked on something from me, email me > directly. By all means copy ghc-devs if you want others in the > conversation, but make it clear that you need my input. That?ll work > better than putting up a Phab review, or a Trac comment, and hoping I?ll > see it. I probably will, but it won?t stick out from other 20 Phab reviews > that I would like to do. I don?t promise to turn everything around fast, > but it?ll increase the chances! > > ? Third, in a vain attempt to at least keep some kind of handle > on the state of play, I keep an ill-organised *page of tickets that I?m > interested in *. > A cursory glance will confirm that there is zero chance that I will attend > to them all. So please do pick up some of them and dig in. Not many are > trivial; most require some investigation, some design work, some discussion > of alternatives, etc. But most of them would benefit from love and > attention. If you are looking for suggestions for things to do, that might > be a good place to start. > > Thanks! > > Simon > > > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -- Chris Allen Currently working on http://haskellbook.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From raichoo at googlemail.com Tue Jan 19 08:31:43 2016 From: raichoo at googlemail.com (raichoo) Date: Tue, 19 Jan 2016 09:31:43 +0100 Subject: Birthday greetings In-Reply-To: <24cb1cf0044b4144bebb2a1a7b7efd6a@DB4PR30MB030.064d.mgd.msft.net> References: <24cb1cf0044b4144bebb2a1a7b7efd6a@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Happy Birthday! Thanks for all your work, I'm very happy with Haskell and GHC, especially now that I can use it at work :D. I've been digging through GHC for months now, hoping to contribute something back this year :) Kind regards, raichoo -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Tue Jan 19 09:48:07 2016 From: johan.tibell at gmail.com (Johan Tibell) Date: Tue, 19 Jan 2016 10:48:07 +0100 Subject: Birthday greetings In-Reply-To: References: <24cb1cf0044b4144bebb2a1a7b7efd6a@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Happy birthday! On Tue, Jan 19, 2016 at 9:31 AM, raichoo wrote: > Happy Birthday! > > Thanks for all your work, I'm very happy with Haskell and GHC, especially > now that I > can use it at work :D. > > I've been digging through GHC for months now, hoping to contribute > something back this year :) > > Kind regards, > raichoo > > _______________________________________________ > 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: From matthewtpickering at gmail.com Tue Jan 19 11:29:33 2016 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Tue, 19 Jan 2016 11:29:33 +0000 Subject: Improving trac notifications In-Reply-To: <874meq8s53.fsf@smart-cactus.org> References: <87twn297mm.fsf@smart-cactus.org> <874meq8s53.fsf@smart-cactus.org> Message-ID: Have you had any chance to think about this yet Herbert? Matt On Wed, Jan 6, 2016 at 6:44 PM, Ben Gamari wrote: > Ben Gamari writes: > >> Matthew Pickering writes: >> >>> I subscribe to the ghc-tickets[1] mailing list which provides updates >>> to all trac tickets. This is very useful, however when a ticket >>> description is updated the whole description is included in the email >>> which makes it hard to see what actually changed. The web interface >>> shows a nice diff[2] of the changes, I think it would be good if >>> emails could also include a diff rather than the current quite useless >>> output. >>> >> I think this would be a great improvement. I, for one, am quite guilty >> of incrementally editing ticket descriptions and the current email >> notifications are nearly useless in this case. >> >>> After a bit of investigation, it appears that the easiest way to >>> achieve this is apply a simple patch to our copy of trac. The current >>> format is hard coded on line 558 in this module, it seems easy to >>> modify this section to instead provide a diff. >>> >> Herbert, perhaps we could do something along these lines? >> > Ping. > > Cheers, > > - Ben From marlowsd at gmail.com Tue Jan 19 14:01:41 2016 From: marlowsd at gmail.com (Simon Marlow) Date: Tue, 19 Jan 2016 14:01:41 +0000 Subject: Serialized module Message-ID: As part of the recent Remote GHCi changes, I moved the module Serialized from the ghc package to ghc-boot. This is because it is shared by the ghci package and ghc itself. The only way to arrange that it was available to both ghc in stage1 and the ghci package (which is not a dependency of the stage1 ghc), was to put it in ghc-boot. Unfortunately this introduces some breakage because some external code import Serialized. I just ran across hint which fails to compile. I can fix this by re-introducing a Serialized module that re-exports module GHC.Serialized. But is that the right thing to do? Serialized is also re-exported by GhcPlugins. Should we be asking people to import that instead? Cheers, Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Tue Jan 19 14:07:05 2016 From: marlowsd at gmail.com (Simon Marlow) Date: Tue, 19 Jan 2016 14:07:05 +0000 Subject: ghci and unfoldings? In-Reply-To: References: <1453098976-sup-8811@sabre> <5c482fcab11747b2aba28814f2f367d4@AM3PR30MB019.064d.mgd.msft.net> Message-ID: -fno-ignore-interface-pragmas might work. However the problem is really that the interpreter cannot compile the full intermediate language of GHC (it can't handle arbitrary unboxed tuples), and we work around that in a fairly fragile way by disabling -O. By enabling unfoldings you might expose the interpreter to some unboxed tuples which would cause it to panic. It's unlikely this will get fixed in the near term, if I recall correctly it's pretty hard to fix. So I think the best fix is probably to use -fobject-code. Cheers, Simon On 18 January 2016 at 18:28, Conal Elliott wrote: > The minimum flags I've found to get ghci to provide unfoldings are -O and > -object-code. And it appears that both flags need to be present the first > time I load a module into GHCi. (I'm putting the flags in an OPTIONS_GHC > pragma.) > > On Mon, Jan 18, 2016 at 9:46 AM, Conal Elliott wrote: > >> That's the flag I would expect. It doesn't seem to help or hinder >> availability of unfoldings in GHCi. Do you think it should? >> >> And Happy Birthday, Simon! >> >> Warmly, - Conal >> >> >> On Monday, January 18, 2016, Simon Peyton Jones >> wrote: >> >>> Or -fexpose-all-unfoldings? >>> >>> Simon >>> >>> | -----Original Message----- >>> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of >>> | Edward Z. Yang >>> | Sent: 18 January 2016 06:37 >>> | To: Conal Elliott >>> | Cc: Andrew Farmer ; ghc-devs at haskell.org >>> | Subject: Re: ghci and unfoldings? >>> | >>> | Does passing -fobject-code solve your problem? >>> | >>> | Edward >>> | >>> | Excerpts from Conal Elliott's message of 2016-01-17 22:18:49 -0800: >>> | > Hi Brandon. Thanks for the reply. I?m not sure that it addresses >>> | what >>> | > I was trying to ask. GHCi *does* invoke plugins and even reloads >>> | those >>> | > plugins dynamically when their source code changes. So in this sense >>> | > ghci does enable optimization, even if it doesn?t perform much >>> | > optimization on its own. And of course plugins and unfolding are not >>> | just about optimization. >>> | > >>> | > I?m not looking for ghci to do optimization, but rather to enable me >>> | > to more easily develop my GHC plugins. It?s *almost* there already. >>> | I >>> | > just need access to unfoldings from other modules for my plugin?s >>> | use. >>> | > >>> | > For context, I?m rebuilding my Haskell-to-hardware compiler >>> | > , which >>> | relies >>> | > on giving a non-standard but principled interpretation of Haskell >>> | > programs via a conversion through the language of cartesian closed >>> | categories (CCCs). >>> | > The first back-end is hardware generation (e.g., via Verilog), and I >>> | > have plans for several other CCC-based interpretations. >>> | > >>> | > In addition to facilitating my plugin development, hosting in ghci >>> | > will make it much more pleasant for others to *use* the plugin >>> | during >>> | > exploratory programming, just as with ghci use in general. With >>> | access >>> | > to unfoldings, users will be able to generate circuit diagrams and >>> | > Verilog like those in my compiler talk immediately and directly from >>> | > within ghci. I also intend to make a GPU back-end for fast >>> | interactive >>> | > graphics etc, which would be much more fun in ghci than with batch >>> | compilation. >>> | > I hope this explanation clarifies my goals and motivation. I hope >>> | > there?s a way to access unfoldings from ghci currently or with a >>> | small >>> | > amount of effort. >>> | > >>> | > Regards, - Conal >>> | > >>> | > On Sun, Jan 17, 2016 at 7:00 PM, Brandon Allbery >>> | >>> | > wrote: >>> | > >>> | > > On Sun, Jan 17, 2016 at 9:40 PM, Conal Elliott >>> | wrote: >>> | > > >>> | > >> I'm developing a GHC plugin (using HERMIT), and I'd like to use >>> | > >> ghci to speed up development. I'm able to do so, except that my >>> | > >> plugin critically needs access to unfoldings, which appear to be >>> | > >> unavailable in ghci. A little experimenting with ghc shows me >>> | that >>> | > >> "-O" is the key, but "-O" is incompatible with "--interactive" >>> | (as >>> | > >> in ghci). Is there any way to persuade ghci to make unfoldings >>> | available? >>> | > > >>> | > > >>> | > > I think unfoldings are only done as part of optimization, and the >>> | > > bytecode backend doesn't support optimization at all. >>> | > > >>> | > > -- >>> | > > brandon s allbery kf8nh sine nomine >>> | > > associates >>> | > > allbery.b at gmail.com >>> | > > ballbery at sinenomine.net >>> | > > unix, openafs, kerberos, infrastructure, xmonad >>> | > > >>> | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fsine >>> | > > >>> | nomine.net&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cbaf2ef5 >>> | > > >>> | 5f8af447b42e608d31fd1cec1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sda >>> | > > ta=qMNmL5LmkgMp0ebkr6SzPQIwhySqOicZgEdW%2fhe6Q%2b0%3d >>> | > > >>> | _______________________________________________ >>> | 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%0a&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com >>> %7cbaf2ef55f8af >>> | 447b42e608d31fd1cec1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=veoz >>> | Ab6M7N9jZaJZ9tgXZ%2fI8jq7U%2b4YM1FcSXvqTcaw%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: From marlowsd at gmail.com Tue Jan 19 14:12:47 2016 From: marlowsd at gmail.com (Simon Marlow) Date: Tue, 19 Jan 2016 14:12:47 +0000 Subject: Birthday greetings In-Reply-To: <24cb1cf0044b4144bebb2a1a7b7efd6a@DB4PR30MB030.064d.mgd.msft.net> References: <24cb1cf0044b4144bebb2a1a7b7efd6a@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Happy Birthday Simon :) And well done for keeping on top of things for so long. I reached the overload point quite a while ago and I no longer read all the mailing lists. So the same goes for me: I'm not going to see a ticket or a diff unless you explicitly CC me on it - but please feel free to do that if you think I ought to take a look. Cheers Simon On 19 January 2016 at 00:22, Simon Peyton Jones wrote: > Dear GHC devs (all 600+ of you), > > It?s my birthday (well it was a few minutes ago, but I became distracted > by #11379). I am 58. GHC is alive and well and, happily, so am I. > > However, of late I have found that my GHC inbox, which I used to be able > to keep under control, just grows and grows. Mostly this is good; it > reflects the fact that GHC has lots of users, that they vigorously expand > up to (and often well beyond) the limits of what GHC can do, and that > increasingly GHC a lot of developers contributing actively to its code > base. > > But it has its downsides. I used to be able to keep up with the Trac and > email traffic. Trusty techniques like ?delete anything mentioning ?dynamic > linking? or ?Unicode?? would cut the traffic in half. But that doesn?t > work any more. Too many interesting things are happening. > > So this email is to say three things: > > ? First,* thank you* to the increasingly large number of you who > are contributing actively to GHC?s development. GHC is a big system, and > no one person can be on top of all of it. GHC no longer depends on one of > two people: it depends on all of you. You know who you are ? thank you. > > ? Second,* apologies* to anyone who is stuck waiting for me. > Although there are large chunks of GHC that I know little about, there are > other parts that are dear to my heart: the renamer, typechecker, Core, > optimisation, and so on. I write code most days and enjoy it. So I do > want to continue to play a very active supporting and reviewing role, as > well as authoring, in these parts. But I?m conscious that doing so puts me > in a lot of critical paths. > > Here?s a suggestion: if you are blocked on something from me, email me > directly. By all means copy ghc-devs if you want others in the > conversation, but make it clear that you need my input. That?ll work > better than putting up a Phab review, or a Trac comment, and hoping I?ll > see it. I probably will, but it won?t stick out from other 20 Phab reviews > that I would like to do. I don?t promise to turn everything around fast, > but it?ll increase the chances! > > ? Third, in a vain attempt to at least keep some kind of handle > on the state of play, I keep an ill-organised *page of tickets that I?m > interested in *. > A cursory glance will confirm that there is zero chance that I will attend > to them all. So please do pick up some of them and dig in. Not many are > trivial; most require some investigation, some design work, some discussion > of alternatives, etc. But most of them would benefit from love and > attention. If you are looking for suggestions for things to do, that might > be a good place to start. > > Thanks! > > Simon > > > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From omeragacan at gmail.com Tue Jan 19 15:00:53 2016 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Tue, 19 Jan 2016 10:00:53 -0500 Subject: Fixing #11444 - OK-for-speculation check rejects valid program? Message-ID: I found one of the problems with #11444, but I don't know how to fix it. The problem is that the desugarer is generating this function: ptrEq [InlPrag=NOINLINE] :: forall a_a1wc. a_a1wc -> a_a1wc -> Bool [LclIdX, Str=DmdType] ptrEq = \ (@ a_a1Ts) (x_a1we :: a_a1Ts) (y_a1wf :: a_a1Ts) -> case x_a1we of x_X1wq { __DEFAULT -> case y_a1wf of y_X1ws { __DEFAULT -> == @ Int GHC.Classes.$fEqInt (case reallyUnsafePtrEquality# @ a_a1Ts x_X1wq y_X1ws of wild_00 { __DEFAULT -> GHC.Types.I# wild_00 }) (GHC.Types.I# 1#) } } Which is lint-safe. Then, the optimizer is transforming this into: ptrEq [InlPrag=NOINLINE] :: forall a_a1wc. a_a1wc -> a_a1wc -> Bool [LclIdX, Arity=2, Str=DmdType, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [20 20] 71 0}] ptrEq = \ (@ a_a1Ts) (x_a1we :: a_a1Ts) (y_a1wf :: a_a1Ts) -> case x_a1we of x_X1wq { __DEFAULT -> case y_a1wf of y_X1ws { __DEFAULT -> eqInt (I# (reallyUnsafePtrEquality# @ a_a1Ts x_X1wq y_X1ws)) (I# 1#) } } The problem with this, according to the linter, is the argument of I# is not OK-for-speculation (the expression `reallyUnsafePtrEquality# @ a_a1Ts x_X1wq y_X1ws`). The reason is because arguments of `reallyUnsafePtrEquality#` are not OK-for-speculation, because their types are polymorphic, and variables with polymorphic types are not OK for speculation. However, I think this expression should be OK-for-speculation, because it can't fail, the primop is not out-of-line etc. I think all the requirements for being OK for speculation hold here. So my questions are: - Does that look like a correct optimization transformation? (it looked OK to me, but wanted to make sure) - Am I right that this expression should be OK for speculation? - What's a good way to make this code lint-safe? Thanks.. From omeragacan at gmail.com Tue Jan 19 16:27:54 2016 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Tue, 19 Jan 2016 11:27:54 -0500 Subject: How to build profiled stage1? In-Reply-To: References: Message-ID: An update: If I just clone from scratch, set the flavor "prof" and run make, it doesn't work. But this is another problem, my original problem is about building profiling stage1, rather than stage2. 2016-01-18 15:10 GMT-05:00 ?mer Sinan A?acan : > I'm trying to debug my stage1 compiler and as a last resort I'm trying to build > stage1 compiler using `-prof -fprof-auto` to be able to do `+RTS -xc -RTS` > during the stage2 build. > > I tried couple of things but they all failed in different ways. > > As far as I understand, both SRC_HC_OPTS and GhcStage1HcOpts are passed to > system-wide installed ghc during the stage1 build and libraries. So I do one of > these changes: > > SRC_HC_OPTS = -O -H64m -prof -fprof-auto > GhcStage1HcOpts = -O0 -DDEBUG -prof -fprof-auto > > The second change I want to make is I want to pass `+RTS -xc -RTS` to > ghc-stage1, for that I'm making this change: > > GhcLibHcOpts = -O -dcore-lint -prof -fprof-auto > > But, no matter what else I change, I can't get past this stage: > > "/usr/local/bin/ghc" -hisuf hi -osuf o -hcsuf hc -static -O > -H64m -Wall -package-db libraries/bootstrapping.conf > -this-package-key ghc-8.1 -hide-all-packages -i -icompiler/basicTypes > -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn > -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface > -icompiler/llvmGen -icompiler/main -icompiler/nativeGen > -icompiler/parser -icompiler/prelude -icompiler/profiling > -icompiler/rename -icompiler/simplCore -icompiler/simplStg > -icompiler/specialise -icompiler/stgSyn -icompiler/stranal > -icompiler/typecheck -icompiler/types -icompiler/utils > -icompiler/vectorise -icompiler/stage1/build > -icompiler/stage1/build/autogen -Icompiler/stage1/build > -Icompiler/stage1/build/autogen -Icompiler/. -Icompiler/parser > -Icompiler/utils -Icompiler/stage1 -optP-include > -optPcompiler/stage1/build/autogen/cabal_macros.h -package-id > array-0.5.1.0-960bf9ae8875cc30355e086f8853a049 -package-id > base-4.8.2.0-0d6d1084fbc041e1cded9228e80e264d -package-id > binary-0.8.0.0 -package-id > bytestring-0.10.6.0-9a873bcf33d6ce2fd2698ce69e2c1c66 -package-id > containers-0.5.6.2-59326c33e30ec8f6afd574cbac625bbb -package-id > directory-1.2.2.0-660a7a83a753ed85c8a374c15dae2b97 -package-id > filepath-1.4.0.0-f97d1e4aebfd7a03be6980454fe31d6e -package-id > ghc-boot-8.1 -package-id hoopl-3.10.2.1 -package-id hpc-0.6.0.3 > -package-id process-1.2.3.0-a22328103774f0499a990653944cbf99 > -package-id template-haskell-2.11.0.0 -package-id > time-1.5.0.1-1b9a502bb07a3e6f4d6935fbf9db7181 -package-id > transformers-0.5.0.0 -package-id > unix-2.7.1.0-bb54ee8f9f6b2600aae7a748eb88a610 -Wall > -fno-warn-name-shadowing -this-package-key ghc -XHaskell2010 -DSTAGE=1 > -Rghc-timing -O0 -DDEBUG -prof -fprof-auto -no-user-package-db > -rtsopts -odir compiler/stage1/build -hidir > compiler/stage1/build -stubdir compiler/stage1/build -c > compiler/utils/Exception.hs -o compiler/stage1/build/Exception.o > > compiler/utils/Exception.hs:10:1: > Failed to load interface for ?Control.Monad.IO.Class? > Perhaps you haven't installed the profiling libraries for > package ?transformers-0.5.0.0?? > Use -v to see a list of the files searched for. > < residency (2 samples), 46M in use, 0.000 INIT (0.001 elapsed), 0.003 > MUT (0.005 elapsed), 0.015 GC (0.019 elapsed) :ghc>> > > I tried enabling library-profiling in my global Cabal config, but that didn't > help. Any ideas how to do this? > > If it matters, I'm on Linux. > > NOTE: If I pass -v to GHC, it lists this place in the list of > locations searched: > > /home/omer/haskell/ghc_unboxed_sums/libraries/transformers/dist-boot/build/Control/Monad/IO/Class.p_hi > > Indeed, the file is not there. When I look at all the command the build system > run at this point, I see lines like this: > > "/usr/local/bin/ghc-pkg" update --force > --package-db=libraries/bootstrapping.conf > libraries/transformers/dist-boot/inplace-pkg-config > Reading package info from > "libraries/transformers/dist-boot/inplace-pkg-config" ... done. > transformers-0.5.0.0: Warning: Unrecognized field abi on line 47 > transformers-0.5.0.0: Warning: haddock-interfaces: > /home/omer/haskell/ghc_unboxed_sums/libraries/transformers/dist-boot/doc/html/transformers/transformers.haddock > doesn't exist or isn't a file > transformers-0.5.0.0: cannot find any of > ["Control/Applicative/Backwards.hi","Control/Applicative/Backwards.p_hi","Control/Applicative/Backwards.dyn_hi"] > (ignoring) > transformers-0.5.0.0: cannot find any of > ["Control/Applicative/Lift.hi","Control/Applicative/Lift.p_hi","Control/Applicative/Lift.dyn_hi"] > (ignoring) > transformers-0.5.0.0: cannot find any of > ["Control/Monad/Signatures.hi","Control/Monad/Signatures.p_hi","Control/Monad/Signatures.dyn_hi"] > (ignoring) > transformers-0.5.0.0: cannot find any of > ["Control/Monad/Trans/Class.hi","Control/Monad/Trans/Class.p_hi","Control/Monad/Trans/Class.dyn_hi"] > (ignoring) > transformers-0.5.0.0: cannot find any of > ["Control/Monad/Trans/Cont.hi","Control/Monad/Trans/Cont.p_hi","Control/Monad/Trans/Cont.dyn_hi"] > (ignoring) > transformers-0.5.0.0: cannot find any of > ["Control/Monad/Trans/Except.hi","Control/Monad/Trans/Except.p_hi","Control/Monad/Trans/Except.dyn_hi"] > (ignoring) > transformers-0.5.0.0: cannot find any of > ["Control/Monad/Trans/Error.hi","Control/Monad/Trans/Error.p_hi","Control/Monad/Trans/Error.dyn_hi"] > (ignoring) > transformers-0.5.0.0: cannot find any of > ["Control/Monad/Trans/Identity.hi","Control/Monad/Trans/Identity.p_hi","Control/Monad/Trans/Identity.dyn_hi"] > (ignoring) > > Then, after a while it's building transformers in a different way, using > arguments like `-dep-makefile` etc. which are as far as I can see not > documented in the GHC man page. When I look libraries/transformers I only see a > directory named "dist-boot" with some weird files with ".haskell" extensions. > I'm quite confused about how this is supposed to work. Can any of the build > system experts help me here? > > This wiki page > https://ghc.haskell.org/trac/ghc/wiki/Debugging/Compiler#Addingdebuggingcodetothecompiler > says "if you have built a profiling compiler ..." but it doesn't say > anything about > how to actually build it. > > Thanks. From john_ericson at brown.edu Tue Jan 19 23:15:15 2016 From: john_ericson at brown.edu (Ericson, John) Date: Tue, 19 Jan 2016 15:15:15 -0800 Subject: Fwd: Host-Oriented Template Haskell In-Reply-To: <87si1t2pts.fsf@gnu.org> References: <87si1t2pts.fsf@gnu.org> Message-ID: Cross-posting this as was suggested on the Haskell-Cafe list. While I envision this as normal feature that anyone can use, in practice its biggest consumers would be GHC devs. John ---------- Forwarded message ---------- From: Ericson, John Date: Tue, Jan 19, 2016 at 1:17 PM Subject: Host-Oriented Template Haskell To: Haskell-Cafe As is well known, TH and cross-compiling do not get along. There are various proposals on how to make this interaction less annoying, and I am not against them. But as I see it, the problem is largely inherent to the design of TH itself: since values can (usually) be lifted from compile-time to run-time, and normal definitions from upstream modules to downstream modules' TH, TH and normal code must "live in the same world". Now this restriction in turn bequeaths TH with much expressive power, and I wouldn't advocate getting rid of it. But many tasks do not need it, and in some cases, say in bootstrapping compilers[1] themselves, it is impossible to use TH because of it, even were all the current proposals implemented. For these reason, I propose a new TH variant which has much harsher phase separation. Normal definitions from upstream modules can not be used, lifting values is either not permitted or is allowed to fail (because of missing/incompatible definitions), and IO is defined to match the behavior of the host, not target, platform (in the cross compiling case). The only interaction between the two phases is that quoted syntax is resolved against the the run-time phase's definitions (just like today). Some of you may find this a shoddy substitute for defining a subset of Haskell which behaves identically on all platforms, and optionally constraining TH to it. But the big feature that my proposal offers and that one doesn't is to be able to independently specify compile-time dependencies for the host-oriented TH---this is analogous to the newish `Setup.hs` dependencies. That in turns leads to what I think is the "killer app" for Host-Oriented TH: exposing the various prepossessors we use (alex, happy, hsc2hs, even CPP) into libraries, and side-stepping any need for "executable dependencies" in Cabal. Note also that at least hsc2hs additionally requires host-IO---there may not even exist a C compiler on the target platform at all. Finally, forgive me if this has been brought up before. I've been thinking about this a while, and did a final pass over the GHC wiki to make sure it wasn't already proposed, but I could have missed something (this is also my first post to the list). John [1]: https://github.com/ghcjs/ghcjs/blob/master/lib/ghcjs-prim/GHCJS/Prim/Internal/Build.hs From ezyang at mit.edu Tue Jan 19 23:20:12 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Tue, 19 Jan 2016 15:20:12 -0800 Subject: Fwd: Host-Oriented Template Haskell In-Reply-To: References: <87si1t2pts.fsf@gnu.org> Message-ID: <1453245573-sup-5512@sabre> Hello John You may find this implementation ticket of interest: https://ghc.haskell.org/trac/ghc/ticket/11378 Edward Excerpts from Ericson, John's message of 2016-01-19 15:15:15 -0800: > Cross-posting this as was suggested on the Haskell-Cafe list. While I > envision this as normal feature that anyone can use, in practice its > biggest consumers would be GHC devs. > > John > > ---------- Forwarded message ---------- > From: Ericson, John > Date: Tue, Jan 19, 2016 at 1:17 PM > Subject: Host-Oriented Template Haskell > To: Haskell-Cafe > > > As is well known, TH and cross-compiling do not get along. There are > various proposals on how to make this interaction less annoying, and I > am not against them. But as I see it, the problem is largely inherent > to the design of TH itself: since values can (usually) be lifted from > compile-time to run-time, and normal definitions from upstream modules > to downstream modules' TH, TH and normal code must "live in the same > world". > > Now this restriction in turn bequeaths TH with much expressive power, > and I wouldn't advocate getting rid of it. But many tasks do not need > it, and in some cases, say in bootstrapping compilers[1] themselves, > it is impossible to use TH because of it, even were all the current > proposals implemented. > > For these reason, I propose a new TH variant which has much harsher > phase separation. Normal definitions from upstream modules can not be > used, lifting values is either not permitted or is allowed to fail > (because of missing/incompatible definitions), and IO is defined to > match the behavior of the host, not target, platform (in the cross > compiling case). The only interaction between the two phases is that > quoted syntax is resolved against the the run-time phase's definitions > (just like today). > > Some of you may find this a shoddy substitute for defining a subset of > Haskell which behaves identically on all platforms, and optionally > constraining TH to it. But the big feature that my proposal offers and > that one doesn't is to be able to independently specify compile-time > dependencies for the host-oriented TH---this is analogous to the > newish `Setup.hs` dependencies. That in turns leads to what I think is > the "killer app" for Host-Oriented TH: exposing the various > prepossessors we use (alex, happy, hsc2hs, even CPP) into libraries, > and side-stepping any need for "executable dependencies" in Cabal. > Note also that at least hsc2hs additionally requires host-IO---there > may not even exist a C compiler on the target platform at all. > > Finally, forgive me if this has been brought up before. I've been > thinking about this a while, and did a final pass over the GHC wiki to > make sure it wasn't already proposed, but I could have missed > something (this is also my first post to the list). > > John > > [1]: https://github.com/ghcjs/ghcjs/blob/master/lib/ghcjs-prim/GHCJS/Prim/Internal/Build.hs From john_ericson at brown.edu Tue Jan 19 23:59:47 2016 From: john_ericson at brown.edu (Ericson, John) Date: Tue, 19 Jan 2016 15:59:47 -0800 Subject: Fwd: Host-Oriented Template Haskell In-Reply-To: <1453245573-sup-5512@sabre> References: <87si1t2pts.fsf@gnu.org> <1453245573-sup-5512@sabre> Message-ID: Ah thanks for the link. Template Haskell with only {-# TH-ONLY #-} imports is precisely equivalent to what I propose. I find a clean separation with that and normal TH useful, however, precisely so the stage2 compiler's source can include such a thing. On Tue, Jan 19, 2016 at 3:20 PM, Edward Z. Yang wrote: > Hello John > > You may find this implementation ticket of interest: > https://ghc.haskell.org/trac/ghc/ticket/11378 > > Edward > > Excerpts from Ericson, John's message of 2016-01-19 15:15:15 -0800: >> Cross-posting this as was suggested on the Haskell-Cafe list. While I >> envision this as normal feature that anyone can use, in practice its >> biggest consumers would be GHC devs. >> >> John >> >> ---------- Forwarded message ---------- >> From: Ericson, John >> Date: Tue, Jan 19, 2016 at 1:17 PM >> Subject: Host-Oriented Template Haskell >> To: Haskell-Cafe >> >> >> As is well known, TH and cross-compiling do not get along. There are >> various proposals on how to make this interaction less annoying, and I >> am not against them. But as I see it, the problem is largely inherent >> to the design of TH itself: since values can (usually) be lifted from >> compile-time to run-time, and normal definitions from upstream modules >> to downstream modules' TH, TH and normal code must "live in the same >> world". >> >> Now this restriction in turn bequeaths TH with much expressive power, >> and I wouldn't advocate getting rid of it. But many tasks do not need >> it, and in some cases, say in bootstrapping compilers[1] themselves, >> it is impossible to use TH because of it, even were all the current >> proposals implemented. >> >> For these reason, I propose a new TH variant which has much harsher >> phase separation. Normal definitions from upstream modules can not be >> used, lifting values is either not permitted or is allowed to fail >> (because of missing/incompatible definitions), and IO is defined to >> match the behavior of the host, not target, platform (in the cross >> compiling case). The only interaction between the two phases is that >> quoted syntax is resolved against the the run-time phase's definitions >> (just like today). >> >> Some of you may find this a shoddy substitute for defining a subset of >> Haskell which behaves identically on all platforms, and optionally >> constraining TH to it. But the big feature that my proposal offers and >> that one doesn't is to be able to independently specify compile-time >> dependencies for the host-oriented TH---this is analogous to the >> newish `Setup.hs` dependencies. That in turns leads to what I think is >> the "killer app" for Host-Oriented TH: exposing the various >> prepossessors we use (alex, happy, hsc2hs, even CPP) into libraries, >> and side-stepping any need for "executable dependencies" in Cabal. >> Note also that at least hsc2hs additionally requires host-IO---there >> may not even exist a C compiler on the target platform at all. >> >> Finally, forgive me if this has been brought up before. I've been >> thinking about this a while, and did a final pass over the GHC wiki to >> make sure it wasn't already proposed, but I could have missed >> something (this is also my first post to the list). >> >> John >> >> [1]: https://github.com/ghcjs/ghcjs/blob/master/lib/ghcjs-prim/GHCJS/Prim/Internal/Build.hs > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From john_ericson at brown.edu Wed Jan 20 00:13:24 2016 From: john_ericson at brown.edu (Ericson, John) Date: Tue, 19 Jan 2016 16:13:24 -0800 Subject: Fwd: Host-Oriented Template Haskell In-Reply-To: References: <87si1t2pts.fsf@gnu.org> <1453245573-sup-5512@sabre> Message-ID: >From #11378: > Can we actually link against the old version of ghc? Yes we can! All we need is > (1) for it to have been built with a different IPID, and > (2) to use module renaming to rename the relevant modules to a different > module name, so that we can import them without a conflict. If I understand this, you are saying stage1 links stage0 (the normal, non-cross-compiler used to build stage1), to build stage2? I agree that should work, but if stage1 is multi-target isn't that level of complexity not even needed? I'm not too familiar with GHC or its build system, but a multi-target compiler that doesn't support normal TH doesn't seem that hard to build in principle. John On Tue, Jan 19, 2016 at 3:59 PM, Ericson, John wrote: > Ah thanks for the link. Template Haskell with only {-# TH-ONLY #-} > imports is precisely equivalent to what I propose. I find a clean > separation with that and normal TH useful, however, precisely so the > stage2 compiler's source can include such a thing. > > On Tue, Jan 19, 2016 at 3:20 PM, Edward Z. Yang wrote: >> Hello John >> >> You may find this implementation ticket of interest: >> https://ghc.haskell.org/trac/ghc/ticket/11378 >> >> Edward >> >> Excerpts from Ericson, John's message of 2016-01-19 15:15:15 -0800: >>> Cross-posting this as was suggested on the Haskell-Cafe list. While I >>> envision this as normal feature that anyone can use, in practice its >>> biggest consumers would be GHC devs. >>> >>> John >>> >>> ---------- Forwarded message ---------- >>> From: Ericson, John >>> Date: Tue, Jan 19, 2016 at 1:17 PM >>> Subject: Host-Oriented Template Haskell >>> To: Haskell-Cafe >>> >>> >>> As is well known, TH and cross-compiling do not get along. There are >>> various proposals on how to make this interaction less annoying, and I >>> am not against them. But as I see it, the problem is largely inherent >>> to the design of TH itself: since values can (usually) be lifted from >>> compile-time to run-time, and normal definitions from upstream modules >>> to downstream modules' TH, TH and normal code must "live in the same >>> world". >>> >>> Now this restriction in turn bequeaths TH with much expressive power, >>> and I wouldn't advocate getting rid of it. But many tasks do not need >>> it, and in some cases, say in bootstrapping compilers[1] themselves, >>> it is impossible to use TH because of it, even were all the current >>> proposals implemented. >>> >>> For these reason, I propose a new TH variant which has much harsher >>> phase separation. Normal definitions from upstream modules can not be >>> used, lifting values is either not permitted or is allowed to fail >>> (because of missing/incompatible definitions), and IO is defined to >>> match the behavior of the host, not target, platform (in the cross >>> compiling case). The only interaction between the two phases is that >>> quoted syntax is resolved against the the run-time phase's definitions >>> (just like today). >>> >>> Some of you may find this a shoddy substitute for defining a subset of >>> Haskell which behaves identically on all platforms, and optionally >>> constraining TH to it. But the big feature that my proposal offers and >>> that one doesn't is to be able to independently specify compile-time >>> dependencies for the host-oriented TH---this is analogous to the >>> newish `Setup.hs` dependencies. That in turns leads to what I think is >>> the "killer app" for Host-Oriented TH: exposing the various >>> prepossessors we use (alex, happy, hsc2hs, even CPP) into libraries, >>> and side-stepping any need for "executable dependencies" in Cabal. >>> Note also that at least hsc2hs additionally requires host-IO---there >>> may not even exist a C compiler on the target platform at all. >>> >>> Finally, forgive me if this has been brought up before. I've been >>> thinking about this a while, and did a final pass over the GHC wiki to >>> make sure it wasn't already proposed, but I could have missed >>> something (this is also my first post to the list). >>> >>> John >>> >>> [1]: https://github.com/ghcjs/ghcjs/blob/master/lib/ghcjs-prim/GHCJS/Prim/Internal/Build.hs >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From eir at cis.upenn.edu Wed Jan 20 05:39:32 2016 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Wed, 20 Jan 2016 00:39:32 -0500 Subject: CallStack naming Message-ID: <96F502AD-4AC6-40FA-BD9C-C9C063C2DDE0@cis.upenn.edu> Hi devs, I'm sure there's an easy answer to this, but I'm wondering: why is the CallStack feature implemented with implicit parameters instead of just a magical constraint? Whenever I use this feature, I don't want to have to enable -XImplicitParams and then make sure I get the name right. What would be wrong with, e.g., > undefined :: AppendsCallStack => a Seems simpler. Is it problems with a nullary class? Thanks, Richard From mail at joachim-breitner.de Wed Jan 20 09:07:42 2016 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 20 Jan 2016 10:07:42 +0100 Subject: CallStack naming In-Reply-To: <96F502AD-4AC6-40FA-BD9C-C9C063C2DDE0@cis.upenn.edu> References: <96F502AD-4AC6-40FA-BD9C-C9C063C2DDE0@cis.upenn.edu> Message-ID: <1453280862.1610.8.camel@joachim-breitner.de> Hi, Am Mittwoch, den 20.01.2016, 00:39 -0500 schrieb Richard Eisenberg: > I'm sure there's an easy answer to this, but I'm wondering: why is > the CallStack feature implemented with implicit parameters instead of > just a magical constraint? Whenever I use this feature, I don't want > to have to enable -XImplicitParams and then make sure I get the name > right. What would be wrong with, e.g., > > > undefined :: AppendsCallStack => a > > Seems simpler. Is it problems with a nullary class? I tried to construct this using what we have right now: ==> AppendCallStack.hs <== {-# LANGUAGE ConstraintKinds, ImplicitParams #-} module AppendCallStack (AppendsCallStack) where import GHC.Stack type AppendsCallStack = ?x::CallStack ==> Bar.hs <== module Bar where import AppendCallStack foo x :: AppendsCallStack => a -> a foo x = error "Test" But with GHC-7.10 I get [1 of 2] Compiling AppendCallStack??( AppendCallStack.hs, AppendCallStack.o ) [2 of 2] Compiling Bar??????????????( Bar.hs, Bar.o ) Bar.hs:5:1: ????Invalid type signature: foo x :: AppendsCallStack => a -> a ????Should be of form :: although the constraint seems to be a constraint all right: *AppendCallStack> :kind AppendsCallStack? AppendsCallStack :: GHC.Prim.Constraint and with GHC HEAD I get [1 of 2] Compiling AppendCallStack??( AppendCallStack.hs, AppendCallStack.o ) AppendCallStack.hs:6:1: error: ????? Illegal implicit parameter ??x::CallStack? ????? In the type synonym declaration for ?AppendsCallStack? Too bad... Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From simonpj at microsoft.com Wed Jan 20 10:25:47 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 20 Jan 2016 10:25:47 +0000 Subject: CallStack naming In-Reply-To: <96F502AD-4AC6-40FA-BD9C-C9C063C2DDE0@cis.upenn.edu> References: <96F502AD-4AC6-40FA-BD9C-C9C063C2DDE0@cis.upenn.edu> Message-ID: <659dc968669143e0972602a72fb7753e@DB4PR30MB030.064d.mgd.msft.net> | I'm sure there's an easy answer to this, but I'm wondering: why is the | CallStack feature implemented with implicit parameters instead of just | a magical constraint? Whenever I use this feature, I don't want to | have to enable -XImplicitParams and then make sure I get the name | right. What would be wrong with, e.g., | | > undefined :: AppendsCallStack => a | | Seems simpler. Is it problems with a nullary class? Hmm. Actually I think that's quite a good idea. The call-stack idea started here https://ghc.haskell.org/trac/ghc/wiki/ExplicitCallStack/ImplicitLocations. We want to be able to get hold of the current call stack. It obviously doesn't make sense to say currentCallStack :: CallStack But as the call stack is an implicit parameter (operationally), it obviously DOES make sense to say ?currentStack :: (?currentStack :: CallStack) => CallStack if ?currentStack is an implicit parameter. And it went from there. There are disadvantages: * Need to use -XImplicitParams (Richard's point) * Need to align two names: foo :: (?loc :: CallStack) => Int -> Int foo x = if x<0 then error "urk" else -x won't work, because 'error' needs (?callStack :: CallStack) * The special cases in the type checker need a 2-level pattern match: for the magic "IP" class, and then the magic "CallStack" type * In principle you might have multiple call stacks kicking around at the same time boo :: (?a::CallStack, ?b::CallStack) => Int -> Int Now I'm not really sure what is supposed to happen about solving these constraints. Perhaps it could be a feature, but it's not one anyone has asked for, and even having to think about it makes my head hurt. Your alternative suggestion is to have a magic nullary class, the ICallStack class ("I" for implicit) so that class ICallStack where callStack :: CallStack At least that's is the implementation, but all the user can see is the overloaded function callStack :: ICallStack => CallStack The solving rules, the CallStack type, and functions for printing it, would be precisely as now. I like this. What about others? (We'd have to think about what to do for 8.0 but first lets see what we want.) Simon From simonpj at microsoft.com Wed Jan 20 10:32:20 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 20 Jan 2016 10:32:20 +0000 Subject: CallStack naming In-Reply-To: <1453280862.1610.8.camel@joachim-breitner.de> References: <96F502AD-4AC6-40FA-BD9C-C9C063C2DDE0@cis.upenn.edu> <1453280862.1610.8.camel@joachim-breitner.de> Message-ID: | foo x :: AppendsCallStack => a -> a Remove the "x"! S | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | Joachim Breitner | Sent: 20 January 2016 09:08 | To: ghc-devs at haskell.org | Subject: Re: CallStack naming | | Hi, | | Am Mittwoch, den 20.01.2016, 00:39 -0500 schrieb Richard Eisenberg: | > I'm sure there's an easy answer to this, but I'm wondering: why is | the | > CallStack feature implemented with implicit parameters instead of | just | > a magical constraint? Whenever I use this feature, I don't want to | > have to enable -XImplicitParams and then make sure I get the name | > right. What would be wrong with, e.g., | > | > > undefined :: AppendsCallStack => a | > | > Seems simpler. Is it problems with a nullary class? | | I tried to construct this using what we have right now: | | ==> AppendCallStack.hs <== | {-# LANGUAGE ConstraintKinds, ImplicitParams #-} module | AppendCallStack (AppendsCallStack) where | | import GHC.Stack | | type AppendsCallStack = ?x::CallStack | | ==> Bar.hs <== | module Bar where | | import AppendCallStack | | foo x :: AppendsCallStack => a -> a | foo x = error "Test" | | But with GHC-7.10 I get | | [1 of 2] Compiling AppendCallStack??( AppendCallStack.hs, | AppendCallStack.o ) | [2 of 2] Compiling Bar??????????????( Bar.hs, Bar.o ) | Bar.hs:5:1: | ????Invalid type signature: foo x :: AppendsCallStack => a -> a | ????Should be of form :: | | although the constraint seems to be a constraint all right: | | *AppendCallStack> :kind AppendsCallStack | AppendsCallStack :: GHC.Prim.Constraint | | and with GHC HEAD I get | | [1 of 2] Compiling AppendCallStack??( AppendCallStack.hs, | AppendCallStack.o ) | | AppendCallStack.hs:6:1: error: | ????? Illegal implicit parameter ??x::CallStack? | ????? In the type synonym declaration for ?AppendsCallStack? | | Too bad... | | Greetings, | Joachim | | -- | Joachim ?nomeata? Breitner | mail at joachim-breitner.de ? | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.jo | achim- | breitner.de%2f&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cd5d44 | 2348f364bcc8a0108d321792a7c%7c72f988bf86f141af91ab2d7cd011db47%7c1&sda | ta=5KAXu5980%2bc4CchVNfWyo1mlD6D8%2bQKn9Qjp6ypv0eE%3d | Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F | Debian Developer: nomeata at debian.org From voldermort at hotmail.com Wed Jan 20 11:20:42 2016 From: voldermort at hotmail.com (Harry .) Date: Wed, 20 Jan 2016 11:20:42 +0000 Subject: Proposal: Longer Testing Cycle Message-ID: "Glasgow Haskell Compiler 8.0.1, release candidate 1" was recently announced, with a caveat that "This release candidate in particular is known to suffer from a few significant issues which are being actively worked upon ... In the coming weeks we will continue to iterate on these issues. We will also look at Trac tickets marked with "highest" priority on the release status page." This leads me to wonder whether release management know what the words "release" and "candidate" mean! I would like to propose that the builds which are currently branded "release candidate" be rebranded as "beta", seeing as that is what they actually are. When the release manager has a build which s/he feels is ready for release, it should be published as a release candidate. If after a couple of weeks or so the same build is still considered suitable for release, it can be released as is, otherwise a new release candidate and testing period are required. From ben at well-typed.com Wed Jan 20 11:30:25 2016 From: ben at well-typed.com (Ben Gamari) Date: Wed, 20 Jan 2016 12:30:25 +0100 Subject: Proposal: Longer Testing Cycle In-Reply-To: References: Message-ID: <874me8h4j2.fsf@smart-cactus.org> "Harry ." writes: > "Glasgow Haskell Compiler 8.0.1, release candidate 1" was recently > announced, with a caveat that "This release candidate in particular is > known to suffer from a few significant issues which are being actively > worked upon ... In the coming weeks we will continue to iterate on > these issues. We will also look at Trac tickets marked with "highest" > priority on the release status page." > > This leads me to wonder whether release management know what the words > "release" and "candidate" mean! > > I would like to propose that the builds which are currently branded > "release candidate" be rebranded as "beta", seeing as that is what > they actually are. When the release manager has a build which s/he > feels is ready for release, it should be published as a release > candidate. If after a couple of weeks or so the same build is still > considered suitable for release, it can be released as is, otherwise a > new release candidate and testing period are required. > Indeed we do use these words very loosely for reasons that are largely historical. I would be open to changing the way we refer to these early "releases" if the current misuse is causing confusion (although not for 8.0, lest we spur even more confusion). I envision we'd probably have one or more "beta" release (beta1, beta2, ...) , followed by hopefully only one "release candidate" (rc1), followed by the release. Would this address your concern? Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From mail at joachim-breitner.de Wed Jan 20 11:50:46 2016 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 20 Jan 2016 12:50:46 +0100 Subject: CallStack naming In-Reply-To: References: <96F502AD-4AC6-40FA-BD9C-C9C063C2DDE0@cis.upenn.edu> <1453280862.1610.8.camel@joachim-breitner.de> Message-ID: <1453290646.1610.38.camel@joachim-breitner.de> Hi, Am Mittwoch, den 20.01.2016, 10:32 +0000 schrieb Simon Peyton Jones: > > ?foo x :: AppendsCallStack => a -> a > > Remove the "x"! heh. Silly me. So let?s try again: With 7.10 it now works: ==> AppendCallStack.hs <== {-# LANGUAGE ConstraintKinds, ImplicitParams #-} module AppendCallStack (AppendsCallStack) where import GHC.Stack type AppendsCallStack = ?callStack::CallStack ==> Bar.hs <== {-# LANGUAGE FlexibleContexts #-} module Main where import AppendCallStack import MyError foo :: AppendsCallStack => a -> a foo x = myerror "Test" main = print (foo ()) ==> MyError.hs <== {-# LANGUAGE ImplicitParams #-} module MyError where import GHC.Stack myerror :: (?callStack :: CallStack) => String -> a myerror msg = error (msg ++ ": " ++ showCallStack ?callStack) Note that I need FlexibleContexts on the usage site to be able to use this, otherwise I get ?? ? Non type-variable argument ? ? ? in the constraint: ?callStack::GHC.Stack.CallStack See it in action: $ ghc --make Bar && ./Bar Bar: Test: ?callStack, called at ./MyError.hs:7:51 in main:MyError ? myerror, called at Bar.hs:8:9 in main:Main ? foo, called at Bar.hs:10:15 in main:Main With GHC-HEAD, it compiles no longer(!): [1 of 2] Compiling AppendCallStack??( AppendCallStack.hs, AppendCallStack.o ) AppendCallStack.hs:6:1: error: ????? Illegal implicit parameter ??callStack::CallStack? ????? In the type synonym declaration for ?AppendsCallStack? So Richard, does it do what you want with GHC-7.10? And given that GHC HEAD rejects it, was 7.10 wrong or is there a bug in HEAD? Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From voldermort at hotmail.com Wed Jan 20 13:13:50 2016 From: voldermort at hotmail.com (Harry .) Date: Wed, 20 Jan 2016 13:13:50 +0000 Subject: Proposal: Longer Testing Cycle In-Reply-To: <874me8h4j2.fsf@smart-cactus.org> References: , <874me8h4j2.fsf@smart-cactus.org> Message-ID: > From: ben at well-typed.com > Subject: Re: Proposal: Longer Testing Cycle > Date: Wed, 20 Jan 2016 12:30:25 +0100 > > I would be open to changing the way we refer to these early "releases" > if the current misuse is causing confusion (although not for 8.0, lest > we spur even more confusion). > > I envision we'd probably have one or more "beta" release (beta1, beta2, > ...) , followed by hopefully only one "release candidate" (rc1), > followed by the release. > > Would this address your concern? Yes, if the "release candidate" really is a release candidate, i.e. this is exactly what we'll publish if no show-stoppers are found. From matthewtpickering at gmail.com Wed Jan 20 13:15:33 2016 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Wed, 20 Jan 2016 13:15:33 +0000 Subject: Improving trac notifications In-Reply-To: References: <87twn297mm.fsf@smart-cactus.org> <874meq8s53.fsf@smart-cactus.org> Message-ID: I attach a patch which should improve the notifications. Here is an example of the new output. https://www.irccloud.com/pastebin/HdlVbQt4/ Matt On Tue, Jan 19, 2016 at 11:29 AM, Matthew Pickering wrote: > Have you had any chance to think about this yet Herbert? > > Matt > > On Wed, Jan 6, 2016 at 6:44 PM, Ben Gamari wrote: >> Ben Gamari writes: >> >>> Matthew Pickering writes: >>> >>>> I subscribe to the ghc-tickets[1] mailing list which provides updates >>>> to all trac tickets. This is very useful, however when a ticket >>>> description is updated the whole description is included in the email >>>> which makes it hard to see what actually changed. The web interface >>>> shows a nice diff[2] of the changes, I think it would be good if >>>> emails could also include a diff rather than the current quite useless >>>> output. >>>> >>> I think this would be a great improvement. I, for one, am quite guilty >>> of incrementally editing ticket descriptions and the current email >>> notifications are nearly useless in this case. >>> >>>> After a bit of investigation, it appears that the easiest way to >>>> achieve this is apply a simple patch to our copy of trac. The current >>>> format is hard coded on line 558 in this module, it seems easy to >>>> modify this section to instead provide a diff. >>>> >>> Herbert, perhaps we could do something along these lines? >>> >> Ping. >> >> Cheers, >> >> - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-delta-to-ticket-modification-notification.patch Type: text/x-patch Size: 2207 bytes Desc: not available URL: From simonpj at microsoft.com Wed Jan 20 13:32:00 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 20 Jan 2016 13:32:00 +0000 Subject: Library tests failing Message-ID: <1b29c662ac644fca832e624f58520e5f@DB4PR30MB030.064d.mgd.msft.net> I?m getting this collection of failing tests, all of a sudden (below). What?s up? I?m pretty sure it?s not my modifications. The failures ae =====> random1283(normal) 1 of 1 [0, 0, 0] cd . && "/5playpen/simonpj/HEAD-4/inplace/test spaces/ghc-stage2" -o random1283 random1283.hs -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-warn-missed-specialisations -fno-ghci-history -package containers > random1283.comp.stderr 2>&1 Compile failed (status 256) errors were: [1 of 1] Compiling Main ( random1283.hs, random1283.o ) random1283.hs:4:1: error: Failed to load interface for ?System.Random? Use -v to see a list of the files searched for. and in STM =====> stm050(normal) 1 of 1 [0, 0, 0] cd . && "/5playpen/simonpj/HEAD-4/inplace/test spaces/ghc-stage2" -o stm050 stm050.hs -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-warn-missed-specialisations -fno-ghci-history -package stm > stm050.comp.stderr 2>&1 Compile failed (status 256) errors were: : cannot satisfy -package stm (use -v for more information) Simon Unexpected failures: ../../libraries/random/tests random1283 [exit code non-0] (normal) ../../libraries/random/tests rangeTest [exit code non-0] (normal) ../../libraries/stm/tests T2411 [exit code non-0] (normal) ../../libraries/stm/tests T3049 [exit code non-0] (normal) ../../libraries/stm/tests T4057 [exit code non-0] (normal) ../../libraries/stm/tests cloneTChan001 [exit code non-0] (normal) ../../libraries/stm/tests stm050 [exit code non-0] (normal) ../../libraries/stm/tests stm054 [exit code non-0] (normal) ../../libraries/stm/tests stm055 [exit code non-0] (normal) ../../libraries/stm/tests stm056 [exit code non-0] (threaded1) ../../libraries/stm/tests stm060 [exit code non-0] (normal) ../../libraries/stm/tests stm061 [exit code non-0] (normal) ../../libraries/stm/tests stm062 [exit code non-0] (normal) ../../libraries/stm/tests stm064 [exit code non-0] (normal) ../../libraries/stm/tests stm065 [exit code non-0] (normal) -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Wed Jan 20 14:56:48 2016 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Wed, 20 Jan 2016 09:56:48 -0500 Subject: CallStack naming In-Reply-To: <1453290646.1610.38.camel@joachim-breitner.de> References: <96F502AD-4AC6-40FA-BD9C-C9C063C2DDE0@cis.upenn.edu> <1453280862.1610.8.camel@joachim-breitner.de> <1453290646.1610.38.camel@joachim-breitner.de> Message-ID: <059D6583-52B7-4E91-B022-62D47BFE21B9@cis.upenn.edu> On Jan 20, 2016, at 6:50 AM, Joachim Breitner wrote: > With GHC-HEAD, it compiles no longer(!): > > [1 of 2] Compiling AppendCallStack ( AppendCallStack.hs, > AppendCallStack.o ) > > AppendCallStack.hs:6:1: error: > ? Illegal implicit parameter ??callStack::CallStack? > ? In the type synonym declaration for ?AppendsCallStack? > > > So Richard, does it do what you want with GHC-7.10? And given that GHC > HEAD rejects it, was 7.10 wrong or is there a bug in HEAD? Eek. That's a bug. :( Richard > > Greetings, > Joachim > > -- > Joachim ?nomeata? Breitner > mail at joachim-breitner.de ? http://www.joachim-breitner.de/ > Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F > Debian Developer: nomeata at debian.org > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From mail at joachim-breitner.de Wed Jan 20 15:33:27 2016 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 20 Jan 2016 16:33:27 +0100 Subject: CallStack naming In-Reply-To: <059D6583-52B7-4E91-B022-62D47BFE21B9@cis.upenn.edu> References: <96F502AD-4AC6-40FA-BD9C-C9C063C2DDE0@cis.upenn.edu> <1453280862.1610.8.camel@joachim-breitner.de> <1453290646.1610.38.camel@joachim-breitner.de> <059D6583-52B7-4E91-B022-62D47BFE21B9@cis.upenn.edu> Message-ID: <1453304007.1610.42.camel@joachim-breitner.de> Hi, Am Mittwoch, den 20.01.2016, 09:56 -0500 schrieb Richard Eisenberg: > Eek. That's a bug. :( There we go:?https://ghc.haskell.org/trac/ghc/ticket/11466 Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From simonpj at microsoft.com Wed Jan 20 15:46:25 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 20 Jan 2016 15:46:25 +0000 Subject: ghci and unfoldings? In-Reply-To: References: <1453098976-sup-8811@sabre> <5c482fcab11747b2aba28814f2f367d4@AM3PR30MB019.064d.mgd.msft.net> Message-ID: <14724789a99248fba86548ca4208c249@DB4PR30MB030.064d.mgd.msft.net> Ah?.It seems that to get unfoldings exposed in the module you are compiling you need both ? -fno-omit-interface-pragmas ? -fexpose-all-unfoldings And GHCi and ?O0 both imply ?fomit-interface-pragmas. To see the unfoldings on imported functions you need ?fno-ignore-interface pragmas. Arguably ?fexpose-all-unfoldings should override ?fomit-interface-pragmas, which it doesn?t at the moment. Open a ticket if you think that would be useful and important. I can give guidance about the places. Simon From: conal.elliott at gmail.com [mailto:conal.elliott at gmail.com] On Behalf Of Conal Elliott Sent: 18 January 2016 17:47 To: Simon Peyton Jones Cc: Edward Z. Yang ; Andrew Farmer ; ghc-devs at haskell.org Subject: Re: ghci and unfoldings? That's the flag I would expect. It doesn't seem to help or hinder availability of unfoldings in GHCi. Do you think it should? And Happy Birthday, Simon! Warmly, - Conal On Monday, January 18, 2016, Simon Peyton Jones > wrote: Or -fexpose-all-unfoldings? Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | Edward Z. Yang | Sent: 18 January 2016 06:37 | To: Conal Elliott > | Cc: Andrew Farmer >; ghc-devs at haskell.org | Subject: Re: ghci and unfoldings? | | Does passing -fobject-code solve your problem? | | Edward | | Excerpts from Conal Elliott's message of 2016-01-17 22:18:49 -0800: | > Hi Brandon. Thanks for the reply. I?m not sure that it addresses | what | > I was trying to ask. GHCi *does* invoke plugins and even reloads | those | > plugins dynamically when their source code changes. So in this sense | > ghci does enable optimization, even if it doesn?t perform much | > optimization on its own. And of course plugins and unfolding are not | just about optimization. | > | > I?m not looking for ghci to do optimization, but rather to enable me | > to more easily develop my GHC plugins. It?s *almost* there already. | I | > just need access to unfoldings from other modules for my plugin?s | use. | > | > For context, I?m rebuilding my Haskell-to-hardware compiler | > , which | relies | > on giving a non-standard but principled interpretation of Haskell | > programs via a conversion through the language of cartesian closed | categories (CCCs). | > The first back-end is hardware generation (e.g., via Verilog), and I | > have plans for several other CCC-based interpretations. | > | > In addition to facilitating my plugin development, hosting in ghci | > will make it much more pleasant for others to *use* the plugin | during | > exploratory programming, just as with ghci use in general. With | access | > to unfoldings, users will be able to generate circuit diagrams and | > Verilog like those in my compiler talk immediately and directly from | > within ghci. I also intend to make a GPU back-end for fast | interactive | > graphics etc, which would be much more fun in ghci than with batch | compilation. | > I hope this explanation clarifies my goals and motivation. I hope | > there?s a way to access unfoldings from ghci currently or with a | small | > amount of effort. | > | > Regards, - Conal | > | > On Sun, Jan 17, 2016 at 7:00 PM, Brandon Allbery | > | > wrote: | > | > > On Sun, Jan 17, 2016 at 9:40 PM, Conal Elliott > | wrote: | > > | > >> I'm developing a GHC plugin (using HERMIT), and I'd like to use | > >> ghci to speed up development. I'm able to do so, except that my | > >> plugin critically needs access to unfoldings, which appear to be | > >> unavailable in ghci. A little experimenting with ghc shows me | that | > >> "-O" is the key, but "-O" is incompatible with "--interactive" | (as | > >> in ghci). Is there any way to persuade ghci to make unfoldings | available? | > > | > > | > > I think unfoldings are only done as part of optimization, and the | > > bytecode backend doesn't support optimization at all. | > > | > > -- | > > brandon s allbery kf8nh sine nomine | > > associates | > > allbery.b at gmail.com | > > ballbery at sinenomine.net | > > unix, openafs, kerberos, infrastructure, xmonad | > > | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fsine | > > | nomine.net&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cbaf2ef5 | > > | 5f8af447b42e608d31fd1cec1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sda | > > ta=qMNmL5LmkgMp0ebkr6SzPQIwhySqOicZgEdW%2fhe6Q%2b0%3d | > > | _______________________________________________ | 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%0a&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cbaf2ef55f8af | 447b42e608d31fd1cec1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=veoz | Ab6M7N9jZaJZ9tgXZ%2fI8jq7U%2b4YM1FcSXvqTcaw%3d -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at seidel.io Wed Jan 20 16:05:47 2016 From: eric at seidel.io (Eric Seidel) Date: Wed, 20 Jan 2016 08:05:47 -0800 Subject: CallStack naming In-Reply-To: <659dc968669143e0972602a72fb7753e@DB4PR30MB030.064d.mgd.msft.net> References: <96F502AD-4AC6-40FA-BD9C-C9C063C2DDE0@cis.upenn.edu> <659dc968669143e0972602a72fb7753e@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <1453305947.1797061.497600914.32732A90@webmail.messagingengine.com> On Wed, Jan 20, 2016, at 02:25, Simon Peyton Jones wrote: > | > undefined :: AppendsCallStack => a > | > | Seems simpler. Is it problems with a nullary class? > > Hmm. Actually I think that's quite a good idea. I agree, this is much nicer than enabling ImplicitParams and having to remember the naming convention! However, it seems to me that we could implement this as a constraint synonym (pending Joachim's bug #11466). So the main benefit from giving CallStack its own class would be in simplifying the implementation. > There are disadvantages: > > * The special cases in the type checker need a 2-level pattern > match: for the magic "IP" class, and then the magic "CallStack" type I don't think this is so bad, we already have a function isCallStackCt that encapsulates the logic. > * In principle you might have multiple call stacks kicking around > at the same time > boo :: (?a::CallStack, ?b::CallStack) => Int -> Int > Now I'm not really sure what is supposed to happen about solving > these constraints. Perhaps it could be a feature, but it's not > one anyone has asked for, and even having to think about it makes > my head hurt. Ugh, I don't want to think about this either. > Your alternative suggestion is to have a magic nullary class, the > ICallStack class ("I" for implicit) so that > > class ICallStack where > callStack :: CallStack > > At least that's is the implementation, but all the user can see is the > overloaded function > > callStack :: ICallStack => CallStack > > The solving rules, the CallStack type, and functions for printing it, > would be precisely as now. > > I like this. What about others? I think there's a problem with this approach. The new ability to freeze CallStacks relies on being able to construct new dictionaries on-the-fly for ImplicitParams. So if we were to re-implement CallStacks with their own class, we would have to copy the shadowing logic that we already have for ImplicitParams. So I'm in favor of Joachim's constraint synonym. Eric From simonpj at microsoft.com Wed Jan 20 16:14:53 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 20 Jan 2016 16:14:53 +0000 Subject: CallStack naming In-Reply-To: <1453305947.1797061.497600914.32732A90@webmail.messagingengine.com> References: <96F502AD-4AC6-40FA-BD9C-C9C063C2DDE0@cis.upenn.edu> <659dc968669143e0972602a72fb7753e@DB4PR30MB030.064d.mgd.msft.net> <1453305947.1797061.497600914.32732A90@webmail.messagingengine.com> Message-ID: <13f3ddc1d01a4f46ac15a051cc8ff049@DB4PR30MB030.064d.mgd.msft.net> | > * In principle you might have multiple call stacks kicking around | > at the same time | > boo :: (?a::CallStack, ?b::CallStack) => Int -> Int | > Now I'm not really sure what is supposed to happen about solving | > these constraints. Perhaps it could be a feature, but it's not | > one anyone has asked for, and even having to think about it makes | > my head hurt. | | Ugh, I don't want to think about this either. But if it's just a synonym, this is entirely possible to do. | > class ICallStack where | > callStack :: CallStack | I think there's a problem with this approach. The new ability to | freeze CallStacks relies on being able to construct new dictionaries | on-the-fly for ImplicitParams. So if we were to re-implement | CallStacks with their own class, we would have to copy the shadowing | logic that we already have for ImplicitParams. I don't understand the problem. Can you be more specific. Regardless, it sounds as though we agreeing that the *user-visible* aspect should use this API. So no more '?callstack' in the user API. Right? Would you like to start amending the wiki page with the proposed new design, from the user point of view. We can continue to argue about implementation! | So I'm in favor of Joachim's constraint synonym. Currently I'm not :-) Simon From eric at seidel.io Wed Jan 20 17:24:07 2016 From: eric at seidel.io (Eric Seidel) Date: Wed, 20 Jan 2016 09:24:07 -0800 Subject: CallStack naming In-Reply-To: <13f3ddc1d01a4f46ac15a051cc8ff049@DB4PR30MB030.064d.mgd.msft.net> References: <96F502AD-4AC6-40FA-BD9C-C9C063C2DDE0@cis.upenn.edu> <659dc968669143e0972602a72fb7753e@DB4PR30MB030.064d.mgd.msft.net> <1453305947.1797061.497600914.32732A90@webmail.messagingengine.com> <13f3ddc1d01a4f46ac15a051cc8ff049@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <1453310647.1815559.497698170.68A46486@webmail.messagingengine.com> On Wed, Jan 20, 2016, at 08:14, Simon Peyton Jones wrote: > | > * In principle you might have multiple call stacks kicking around > | > at the same time > | > boo :: (?a::CallStack, ?b::CallStack) => Int -> Int > | > Now I'm not really sure what is supposed to happen about solving > | > these constraints. Perhaps it could be a feature, but it's not > | > one anyone has asked for, and even having to think about it makes > | > my head hurt. > | > | Ugh, I don't want to think about this either. > > But if it's just a synonym, this is entirely possible to do. True. I don't think it would cause problems for the solver, but it could certainly be a pitfall for users. > | > class ICallStack where > | > callStack :: CallStack > > > | I think there's a problem with this approach. The new ability to > | freeze CallStacks relies on being able to construct new dictionaries > | on-the-fly for ImplicitParams. So if we were to re-implement > | CallStacks with their own class, we would have to copy the shadowing > | logic that we already have for ImplicitParams. > > I don't understand the problem. Can you be more specific. I've written up a few notes about the proposal on the wiki. https://ghc.haskell.org/trac/ghc/wiki/ExplicitCallStack/ImplicitLocations#AlternateProposal The problem is that I don't know how to implement `withFrozenCallStack` (included in the wiki) as a Haskell function if CallStacks aren't implicit parameters under-the-hood. > Regardless, it sounds as though we agreeing that the *user-visible* > aspect should use this API. So no more '?callstack' in the user API. > Right? Indeed! From jan.stolarek at p.lodz.pl Wed Jan 20 18:42:18 2016 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Wed, 20 Jan 2016 19:42:18 +0100 Subject: Special treatment of family and role in the parser Message-ID: <201601201942.18508.jan.stolarek@p.lodz.pl> Richard, I still don't fully understand special treatment of 'role' and 'family' in the parser I asked about recently on Skype. Say I have: foo :: role -> role foo role = role This results in parse error of type signature, regardless of enabling or disabling -XRoleAnnotations. Using `role` as a variable name (not type variable) is fine though. This is a consequence of explicitly listing 'role' lexeme in the varid production in the parser, but not in tyvarid production. But if I add 'role' to tyvarid production (or, even better, push it to special_id production used both by varid and tyvarid) everything works perfectly, I can use `role` both as variable and type variable name. Role annotations also work. The only downside is a small increase in number of shift/reduce conflicts. If I treat 'family' in the same way (ie. add it to tyvarid production) the increase in shift/reduce conflicts really becomes significant: from 37 to 129. Is this the only reason we don't do it? As you can guess this question is related to open kinds work: I need to add 'kind' lexeme to special_id to make sure it is accepted as a variable and type variable name. Janek --- Politechnika ??dzka Lodz University of Technology Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system. From eir at cis.upenn.edu Wed Jan 20 19:25:24 2016 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Wed, 20 Jan 2016 14:25:24 -0500 Subject: Special treatment of family and role in the parser In-Reply-To: <201601201942.18508.jan.stolarek@p.lodz.pl> References: <201601201942.18508.jan.stolarek@p.lodz.pl> Message-ID: <7357C36F-D281-4DFC-8FF0-85B78BEB28BF@cis.upenn.edu> From your email, you understand everything I do about this. :) I think the challenge really is just understanding and eliminating these conflicts. See the commentary at the top of Parser.y to see how to get an analysis of the conflicts. While you're in the area, you may want to look at #11267. It's not quite related, but it's also about parsing types. Richard On Jan 20, 2016, at 1:42 PM, Jan Stolarek wrote: > Richard, I still don't fully understand special treatment of 'role' and 'family' in the parser I > asked about recently on Skype. Say I have: > > foo :: role -> role > foo role = role > > This results in parse error of type signature, regardless of enabling or > disabling -XRoleAnnotations. Using `role` as a variable name (not type variable) is fine though. > This is a consequence of explicitly listing 'role' lexeme in the varid production in the parser, > but not in tyvarid production. But if I add 'role' to tyvarid production (or, even better, push > it to special_id production used both by varid and tyvarid) everything works perfectly, I can use > `role` both as variable and type variable name. Role annotations also work. The only downside is > a small increase in number of shift/reduce conflicts. If I treat 'family' in the same way (ie. > add it to tyvarid production) the increase in shift/reduce conflicts really becomes significant: > from 37 to 129. Is this the only reason we don't do it? As you can guess this question is related > to open kinds work: I need to add 'kind' lexeme to special_id to make sure it is accepted as a > variable and type variable name. > > Janek > > --- > Politechnika ??dzka > Lodz University of Technology > > Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. > Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k? > prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. > > This email contains information intended solely for the use of the individual to whom it is addressed. > If you are not the intended recipient or if you have received this message in error, > please notify the sender and delete it from your system. From thomasmiedema at gmail.com Wed Jan 20 20:10:17 2016 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Wed, 20 Jan 2016 21:10:17 +0100 Subject: Special treatment of family and role in the parser In-Reply-To: <7357C36F-D281-4DFC-8FF0-85B78BEB28BF@cis.upenn.edu> References: <201601201942.18508.jan.stolarek@p.lodz.pl> <7357C36F-D281-4DFC-8FF0-85B78BEB28BF@cis.upenn.edu> Message-ID: CC Ulya Trofimovich (skvadrik), who removed the remaining reduce/reduce conflicts from the parser last year, and can maybe also help out here. Ulya: see email from Jan below. On Wed, Jan 20, 2016 at 8:25 PM, Richard Eisenberg wrote: > From your email, you understand everything I do about this. :) > > I think the challenge really is just understanding and eliminating these > conflicts. See the commentary at the top of Parser.y to see how to get an > analysis of the conflicts. > > While you're in the area, you may want to look at #11267. It's not quite > related, but it's also about parsing types. > > Richard > > On Jan 20, 2016, at 1:42 PM, Jan Stolarek wrote: > > > Richard, I still don't fully understand special treatment of 'role' and > 'family' in the parser I > > asked about recently on Skype. Say I have: > > > > foo :: role -> role > > foo role = role > > > > This results in parse error of type signature, regardless of enabling or > > disabling -XRoleAnnotations. Using `role` as a variable name (not type > variable) is fine though. > > This is a consequence of explicitly listing 'role' lexeme in the varid > production in the parser, > > but not in tyvarid production. But if I add 'role' to tyvarid production > (or, even better, push > > it to special_id production used both by varid and tyvarid) everything > works perfectly, I can use > > `role` both as variable and type variable name. Role annotations also > work. The only downside is > > a small increase in number of shift/reduce conflicts. If I treat > 'family' in the same way (ie. > > add it to tyvarid production) the increase in shift/reduce conflicts > really becomes significant: > > from 37 to 129. Is this the only reason we don't do it? As you can guess > this question is related > > to open kinds work: I need to add 'kind' lexeme to special_id to make > sure it is accepted as a > > variable and type variable name. > > > > Janek > > > > --- > > Politechnika ??dzka > > Lodz University of Technology > > > > Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. > > Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez > pomy?k? > > prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. > > > > This email contains information intended solely for the use of the > individual to whom it is addressed. > > If you are not the intended recipient or if you have received this > message in error, > > please notify the sender and delete it from your system. > > _______________________________________________ > 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: From conal at conal.net Thu Jan 21 00:11:42 2016 From: conal at conal.net (Conal Elliott) Date: Wed, 20 Jan 2016 16:11:42 -0800 Subject: ghci and unfoldings? In-Reply-To: <14724789a99248fba86548ca4208c249@DB4PR30MB030.064d.mgd.msft.net> References: <1453098976-sup-8811@sabre> <5c482fcab11747b2aba28814f2f367d4@AM3PR30MB019.064d.mgd.msft.net> <14724789a99248fba86548ca4208c249@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Thanks for the additional tips. I'm having very inconsistent results with unfolding definitions from other modules in ghci, even with all of these flags. I'll keep poking at it until I have some consistent info and questions. -- Conal On Wed, Jan 20, 2016 at 7:46 AM, Simon Peyton Jones wrote: > Ah?.It seems that to get unfoldings exposed in the *module you are > compiling* you need *both* > > ? -fno-omit-interface-pragmas > > ? -fexpose-all-unfoldings > > > > And GHCi and ?O0 both imply ?fomit-interface-pragmas. > > > > To see the unfoldings on *imported* functions you need > ?fno-ignore-interface pragmas. > > > > Arguably ?fexpose-all-unfoldings should override ?fomit-interface-pragmas, > which it doesn?t at the moment. Open a ticket if you think that would be > useful and important. I can give guidance about the places. > > > > Simon > > > > > > *From:* conal.elliott at gmail.com [mailto:conal.elliott at gmail.com] *On > Behalf Of *Conal Elliott > *Sent:* 18 January 2016 17:47 > *To:* Simon Peyton Jones > *Cc:* Edward Z. Yang ; Andrew Farmer ; > ghc-devs at haskell.org > > *Subject:* Re: ghci and unfoldings? > > > > That's the flag I would expect. It doesn't seem to help or hinder > availability of unfoldings in GHCi. Do you think it should? > > And Happy Birthday, Simon! > > Warmly, - Conal > > > On Monday, January 18, 2016, Simon Peyton Jones > wrote: > > Or -fexpose-all-unfoldings? > > Simon > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org > ] On Behalf Of > | Edward Z. Yang > | Sent: 18 January 2016 06:37 > | To: Conal Elliott > | Cc: Andrew Farmer ; ghc-devs at haskell.org > | Subject: Re: ghci and unfoldings? > | > | Does passing -fobject-code solve your problem? > | > | Edward > | > | Excerpts from Conal Elliott's message of 2016-01-17 22:18:49 -0800: > | > Hi Brandon. Thanks for the reply. I?m not sure that it addresses > | what > | > I was trying to ask. GHCi *does* invoke plugins and even reloads > | those > | > plugins dynamically when their source code changes. So in this sense > | > ghci does enable optimization, even if it doesn?t perform much > | > optimization on its own. And of course plugins and unfolding are not > | just about optimization. > | > > | > I?m not looking for ghci to do optimization, but rather to enable me > | > to more easily develop my GHC plugins. It?s *almost* there already. > | I > | > just need access to unfoldings from other modules for my plugin?s > | use. > | > > | > For context, I?m rebuilding my Haskell-to-hardware compiler > | > , which > | relies > | > on giving a non-standard but principled interpretation of Haskell > | > programs via a conversion through the language of cartesian closed > | categories (CCCs). > | > The first back-end is hardware generation (e.g., via Verilog), and I > | > have plans for several other CCC-based interpretations. > | > > | > In addition to facilitating my plugin development, hosting in ghci > | > will make it much more pleasant for others to *use* the plugin > | during > | > exploratory programming, just as with ghci use in general. With > | access > | > to unfoldings, users will be able to generate circuit diagrams and > | > Verilog like those in my compiler talk immediately and directly from > | > within ghci. I also intend to make a GPU back-end for fast > | interactive > | > graphics etc, which would be much more fun in ghci than with batch > | compilation. > | > I hope this explanation clarifies my goals and motivation. I hope > | > there?s a way to access unfoldings from ghci currently or with a > | small > | > amount of effort. > | > > | > Regards, - Conal > | > > | > On Sun, Jan 17, 2016 at 7:00 PM, Brandon Allbery > | > | > wrote: > | > > | > > On Sun, Jan 17, 2016 at 9:40 PM, Conal Elliott > | wrote: > | > > > | > >> I'm developing a GHC plugin (using HERMIT), and I'd like to use > | > >> ghci to speed up development. I'm able to do so, except that my > | > >> plugin critically needs access to unfoldings, which appear to be > | > >> unavailable in ghci. A little experimenting with ghc shows me > | that > | > >> "-O" is the key, but "-O" is incompatible with "--interactive" > | (as > | > >> in ghci). Is there any way to persuade ghci to make unfoldings > | available? > | > > > | > > > | > > I think unfoldings are only done as part of optimization, and the > | > > bytecode backend doesn't support optimization at all. > | > > > | > > -- > | > > brandon s allbery kf8nh sine nomine > | > > associates > | > > allbery.b at gmail.com > | > > ballbery at sinenomine.net > | > > unix, openafs, kerberos, infrastructure, xmonad > | > > > | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fsine > | > > > | nomine.net > > &data=01%7c01%7csimonpj%40064d.mgd.microsoft.com > > %7cbaf2ef5 > | > > > | 5f8af447b42e608d31fd1cec1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sda > | > > ta=qMNmL5LmkgMp0ebkr6SzPQIwhySqOicZgEdW%2fhe6Q%2b0%3d > | > > > | _______________________________________________ > | 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%0a&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com > > %7cbaf2ef55f8af > | 447b42e608d31fd1cec1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=veoz > | Ab6M7N9jZaJZ9tgXZ%2fI8jq7U%2b4YM1FcSXvqTcaw%3d > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewtpickering at gmail.com Thu Jan 21 00:17:46 2016 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Thu, 21 Jan 2016 00:17:46 +0000 Subject: Improving trac notifications In-Reply-To: References: <87twn297mm.fsf@smart-cactus.org> <874meq8s53.fsf@smart-cactus.org> Message-ID: Herbert now seems to have applied the patch. Hopefully this will improve the email situation for everyone. Matt On 20 Jan 2016 1:15 pm, "Matthew Pickering" wrote: > I attach a patch which should improve the notifications. > > Here is an example of the new output. > > https://www.irccloud.com/pastebin/HdlVbQt4/ > > Matt > > On Tue, Jan 19, 2016 at 11:29 AM, Matthew Pickering > wrote: > > Have you had any chance to think about this yet Herbert? > > > > Matt > > > > On Wed, Jan 6, 2016 at 6:44 PM, Ben Gamari wrote: > >> Ben Gamari writes: > >> > >>> Matthew Pickering writes: > >>> > >>>> I subscribe to the ghc-tickets[1] mailing list which provides updates > >>>> to all trac tickets. This is very useful, however when a ticket > >>>> description is updated the whole description is included in the email > >>>> which makes it hard to see what actually changed. The web interface > >>>> shows a nice diff[2] of the changes, I think it would be good if > >>>> emails could also include a diff rather than the current quite useless > >>>> output. > >>>> > >>> I think this would be a great improvement. I, for one, am quite guilty > >>> of incrementally editing ticket descriptions and the current email > >>> notifications are nearly useless in this case. > >>> > >>>> After a bit of investigation, it appears that the easiest way to > >>>> achieve this is apply a simple patch to our copy of trac. The current > >>>> format is hard coded on line 558 in this module, it seems easy to > >>>> modify this section to instead provide a diff. > >>>> > >>> Herbert, perhaps we could do something along these lines? > >>> > >> Ping. > >> > >> Cheers, > >> > >> - Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Thu Jan 21 04:37:52 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Wed, 20 Jan 2016 20:37:52 -0800 Subject: Fwd: Host-Oriented Template Haskell In-Reply-To: References: <87si1t2pts.fsf@gnu.org> <1453245573-sup-5512@sabre> Message-ID: <1453350334-sup-7919@sabre> Hello John, Almost! As you point out, if you just want a cross-compiler, you don't need to build stage2. The real problem is that we want stage0 to be *the same version* as stage1, so that stage0 has the correct API in order to load stage0 libraries which are going to be used for TH, plugins, etc. (Alternately, build a non-cross-compiler stage1, and then a cross-compiler stage2--NOT a cross compiled stage 2.) Edward Excerpts from Ericson, John's message of 2016-01-19 16:13:24 -0800: > From #11378: > > > Can we actually link against the old version of ghc? Yes we can! All we need is > > (1) for it to have been built with a different IPID, and > > (2) to use module renaming to rename the relevant modules to a different > > module name, so that we can import them without a conflict. > > > If I understand this, you are saying stage1 links stage0 (the normal, > non-cross-compiler used to build stage1), to build stage2? I agree > that should work, but if stage1 is multi-target isn't that level of > complexity not even needed? I'm not too familiar with GHC or its build > system, but a multi-target compiler that doesn't support normal TH > doesn't seem that hard to build in principle. > > John > > On Tue, Jan 19, 2016 at 3:59 PM, Ericson, John wrote: > > Ah thanks for the link. Template Haskell with only {-# TH-ONLY #-} > > imports is precisely equivalent to what I propose. I find a clean > > separation with that and normal TH useful, however, precisely so the > > stage2 compiler's source can include such a thing. > > > > On Tue, Jan 19, 2016 at 3:20 PM, Edward Z. Yang wrote: > >> Hello John > >> > >> You may find this implementation ticket of interest: > >> https://ghc.haskell.org/trac/ghc/ticket/11378 > >> > >> Edward > >> > >> Excerpts from Ericson, John's message of 2016-01-19 15:15:15 -0800: > >>> Cross-posting this as was suggested on the Haskell-Cafe list. While I > >>> envision this as normal feature that anyone can use, in practice its > >>> biggest consumers would be GHC devs. > >>> > >>> John > >>> > >>> ---------- Forwarded message ---------- > >>> From: Ericson, John > >>> Date: Tue, Jan 19, 2016 at 1:17 PM > >>> Subject: Host-Oriented Template Haskell > >>> To: Haskell-Cafe > >>> > >>> > >>> As is well known, TH and cross-compiling do not get along. There are > >>> various proposals on how to make this interaction less annoying, and I > >>> am not against them. But as I see it, the problem is largely inherent > >>> to the design of TH itself: since values can (usually) be lifted from > >>> compile-time to run-time, and normal definitions from upstream modules > >>> to downstream modules' TH, TH and normal code must "live in the same > >>> world". > >>> > >>> Now this restriction in turn bequeaths TH with much expressive power, > >>> and I wouldn't advocate getting rid of it. But many tasks do not need > >>> it, and in some cases, say in bootstrapping compilers[1] themselves, > >>> it is impossible to use TH because of it, even were all the current > >>> proposals implemented. > >>> > >>> For these reason, I propose a new TH variant which has much harsher > >>> phase separation. Normal definitions from upstream modules can not be > >>> used, lifting values is either not permitted or is allowed to fail > >>> (because of missing/incompatible definitions), and IO is defined to > >>> match the behavior of the host, not target, platform (in the cross > >>> compiling case). The only interaction between the two phases is that > >>> quoted syntax is resolved against the the run-time phase's definitions > >>> (just like today). > >>> > >>> Some of you may find this a shoddy substitute for defining a subset of > >>> Haskell which behaves identically on all platforms, and optionally > >>> constraining TH to it. But the big feature that my proposal offers and > >>> that one doesn't is to be able to independently specify compile-time > >>> dependencies for the host-oriented TH---this is analogous to the > >>> newish `Setup.hs` dependencies. That in turns leads to what I think is > >>> the "killer app" for Host-Oriented TH: exposing the various > >>> prepossessors we use (alex, happy, hsc2hs, even CPP) into libraries, > >>> and side-stepping any need for "executable dependencies" in Cabal. > >>> Note also that at least hsc2hs additionally requires host-IO---there > >>> may not even exist a C compiler on the target platform at all. > >>> > >>> Finally, forgive me if this has been brought up before. I've been > >>> thinking about this a while, and did a final pass over the GHC wiki to > >>> make sure it wasn't already proposed, but I could have missed > >>> something (this is also my first post to the list). > >>> > >>> John > >>> > >>> [1]: https://github.com/ghcjs/ghcjs/blob/master/lib/ghcjs-prim/GHCJS/Prim/Internal/Build.hs > >> _______________________________________________ > >> ghc-devs mailing list > >> ghc-devs at haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From john_ericson at brown.edu Thu Jan 21 05:23:28 2016 From: john_ericson at brown.edu (Ericson, John) Date: Wed, 20 Jan 2016 21:23:28 -0800 Subject: Fwd: Fwd: Host-Oriented Template Haskell In-Reply-To: References: <87si1t2pts.fsf@gnu.org> <1453245573-sup-5512@sabre> <1453350334-sup-7919@sabre> Message-ID: Oops, Sent just to Edward by mistake. ---- That all sounds good to me---I think what I was thinking all along in fact, unless I am still missing some nuance :). My idea of using a multi-target compiler was to avoid needing stage0 to be the same version as stage1 (or adding a new stage, stage1 as in your alternative). The cross compiler is multi-target so it doesn't need to link another compiler to load plugins / run "host-oriented Template Haskell". I mentioned the usecase of trying to build a stage2 which needs plugins / Host-Oriented Template Haskell, but it could well apply to building anything else with the need for those to things (and not normal TH, which cannot be built with a cross compiler) In diagrams, rather than: > stage0 (version foo, platform-x -> platform-x) > ==> stage1 (version foo, platform-x -> platform-y) > ==> some program (with plugins, with host-oriented TH, without normal TH) or > stage0 (version bar, platform-x -> platform-x) > ==> stage1 (version foo, platform-x -> platform-x) -> > ==> stage2 (version foo, platform-x -> platform-y) -> > ==> some program (with plugins, with host-oriented TH, without normal TH) do just > stage0 (version bar, platform-x -> platform-x) > ==> stage1 (version foo, platform-x -> {platform-x, platform-y}) > ==> some program (with plugins, with host-oriented TH, without normal TH) Now it may be that building such a multi-target compiler today is just as arduous as making sure one has a native compiler of the same version before building the cross compiler, so my idea is of no practical value. But if so, I hope in the long term that could be fixed. John On Wed, Jan 20, 2016 at 8:37 PM, Edward Z. Yang wrote: > Hello John, > > Almost! > > As you point out, if you just want a cross-compiler, you don't > need to build stage2. The real problem is that we want stage0 > to be *the same version* as stage1, so that stage0 has the correct > API in order to load stage0 libraries which are going to be used > for TH, plugins, etc. (Alternately, build a non-cross-compiler > stage1, and then a cross-compiler stage2--NOT a cross compiled > stage 2.) > > Edward > > Excerpts from Ericson, John's message of 2016-01-19 16:13:24 -0800: >> From #11378: >> >> > Can we actually link against the old version of ghc? Yes we can! All we need is >> > (1) for it to have been built with a different IPID, and >> > (2) to use module renaming to rename the relevant modules to a different >> > module name, so that we can import them without a conflict. >> >> >> If I understand this, you are saying stage1 links stage0 (the normal, >> non-cross-compiler used to build stage1), to build stage2? I agree >> that should work, but if stage1 is multi-target isn't that level of >> complexity not even needed? I'm not too familiar with GHC or its build >> system, but a multi-target compiler that doesn't support normal TH >> doesn't seem that hard to build in principle. >> >> John >> >> On Tue, Jan 19, 2016 at 3:59 PM, Ericson, John wrote: >> > Ah thanks for the link. Template Haskell with only {-# TH-ONLY #-} >> > imports is precisely equivalent to what I propose. I find a clean >> > separation with that and normal TH useful, however, precisely so the >> > stage2 compiler's source can include such a thing. >> > >> > On Tue, Jan 19, 2016 at 3:20 PM, Edward Z. Yang wrote: >> >> Hello John >> >> >> >> You may find this implementation ticket of interest: >> >> https://ghc.haskell.org/trac/ghc/ticket/11378 >> >> >> >> Edward >> >> >> >> Excerpts from Ericson, John's message of 2016-01-19 15:15:15 -0800: >> >>> Cross-posting this as was suggested on the Haskell-Cafe list. While I >> >>> envision this as normal feature that anyone can use, in practice its >> >>> biggest consumers would be GHC devs. >> >>> >> >>> John >> >>> >> >>> ---------- Forwarded message ---------- >> >>> From: Ericson, John >> >>> Date: Tue, Jan 19, 2016 at 1:17 PM >> >>> Subject: Host-Oriented Template Haskell >> >>> To: Haskell-Cafe >> >>> >> >>> >> >>> As is well known, TH and cross-compiling do not get along. There are >> >>> various proposals on how to make this interaction less annoying, and I >> >>> am not against them. But as I see it, the problem is largely inherent >> >>> to the design of TH itself: since values can (usually) be lifted from >> >>> compile-time to run-time, and normal definitions from upstream modules >> >>> to downstream modules' TH, TH and normal code must "live in the same >> >>> world". >> >>> >> >>> Now this restriction in turn bequeaths TH with much expressive power, >> >>> and I wouldn't advocate getting rid of it. But many tasks do not need >> >>> it, and in some cases, say in bootstrapping compilers[1] themselves, >> >>> it is impossible to use TH because of it, even were all the current >> >>> proposals implemented. >> >>> >> >>> For these reason, I propose a new TH variant which has much harsher >> >>> phase separation. Normal definitions from upstream modules can not be >> >>> used, lifting values is either not permitted or is allowed to fail >> >>> (because of missing/incompatible definitions), and IO is defined to >> >>> match the behavior of the host, not target, platform (in the cross >> >>> compiling case). The only interaction between the two phases is that >> >>> quoted syntax is resolved against the the run-time phase's definitions >> >>> (just like today). >> >>> >> >>> Some of you may find this a shoddy substitute for defining a subset of >> >>> Haskell which behaves identically on all platforms, and optionally >> >>> constraining TH to it. But the big feature that my proposal offers and >> >>> that one doesn't is to be able to independently specify compile-time >> >>> dependencies for the host-oriented TH---this is analogous to the >> >>> newish `Setup.hs` dependencies. That in turns leads to what I think is >> >>> the "killer app" for Host-Oriented TH: exposing the various >> >>> prepossessors we use (alex, happy, hsc2hs, even CPP) into libraries, >> >>> and side-stepping any need for "executable dependencies" in Cabal. >> >>> Note also that at least hsc2hs additionally requires host-IO---there >> >>> may not even exist a C compiler on the target platform at all. >> >>> >> >>> Finally, forgive me if this has been brought up before. I've been >> >>> thinking about this a while, and did a final pass over the GHC wiki to >> >>> make sure it wasn't already proposed, but I could have missed >> >>> something (this is also my first post to the list). >> >>> >> >>> John >> >>> >> >>> [1]: https://github.com/ghcjs/ghcjs/blob/master/lib/ghcjs-prim/GHCJS/Prim/Internal/Build.hs >> >> _______________________________________________ >> >> ghc-devs mailing list >> >> ghc-devs at haskell.org >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From ezyang at mit.edu Thu Jan 21 06:44:55 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Wed, 20 Jan 2016 22:44:55 -0800 Subject: Fwd: Fwd: Host-Oriented Template Haskell In-Reply-To: References: <87si1t2pts.fsf@gnu.org> <1453245573-sup-5512@sabre> <1453350334-sup-7919@sabre> Message-ID: <1453357380-sup-6390@sabre> Yes, in principle, a compiler that supports cross-compiling to many targets without needing to be configured (at build time) which target it should support is ideal. Unfortunately, currently GHC relies on autoconf to determine all of the necessary parameters for a cross-compile. I am not sure how feasible it would be to allow these parameters to be configured at runtime: it might be easy, it might be hard! (And of course you have to arrange to have cross-compiled all the boot libraries too...) In any case, I think that a GHC that permits changing cross-compilation targets at runtime is a fine goal, and if it is supported, then we would only have to make adjustments to GHC internally to distinguish between the interfaces/objects for various targets (including itself.) Edward Excerpts from Ericson, John's message of 2016-01-20 21:23:28 -0800: > Oops, Sent just to Edward by mistake. > > ---- > > That all sounds good to me---I think what I was thinking all along in > fact, unless I am still missing some nuance :). > > My idea of using a multi-target compiler was to avoid needing stage0 > to be the same version as stage1 (or adding a new stage, stage1 as in > your alternative). The cross compiler is multi-target so it doesn't > need to link another compiler to load plugins / run "host-oriented > Template Haskell". I mentioned the usecase of trying to build a stage2 > which needs plugins / Host-Oriented Template Haskell, but it could > well apply to building anything else with the need for those to things > (and not normal TH, which cannot be built with a cross compiler) > > In diagrams, rather than: > > > stage0 (version foo, platform-x -> platform-x) > > ==> stage1 (version foo, platform-x -> platform-y) > > ==> some program (with plugins, with host-oriented TH, without normal TH) > > or > > > stage0 (version bar, platform-x -> platform-x) > > ==> stage1 (version foo, platform-x -> platform-x) -> > > ==> stage2 (version foo, platform-x -> platform-y) -> > > ==> some program (with plugins, with host-oriented TH, without normal TH) > > do just > > > stage0 (version bar, platform-x -> platform-x) > > ==> stage1 (version foo, platform-x -> {platform-x, platform-y}) > > ==> some program (with plugins, with host-oriented TH, without normal TH) > > Now it may be that building such a multi-target compiler today is just > as arduous as making sure one has a native compiler of the same > version before building the cross compiler, so my idea is of no > practical value. But if so, I hope in the long term that could be > fixed. > > John > > On Wed, Jan 20, 2016 at 8:37 PM, Edward Z. Yang wrote: > > Hello John, > > > > Almost! > > > > As you point out, if you just want a cross-compiler, you don't > > need to build stage2. The real problem is that we want stage0 > > to be *the same version* as stage1, so that stage0 has the correct > > API in order to load stage0 libraries which are going to be used > > for TH, plugins, etc. (Alternately, build a non-cross-compiler > > stage1, and then a cross-compiler stage2--NOT a cross compiled > > stage 2.) > > > > Edward > > > > Excerpts from Ericson, John's message of 2016-01-19 16:13:24 -0800: > >> From #11378: > >> > >> > Can we actually link against the old version of ghc? Yes we can! All we need is > >> > (1) for it to have been built with a different IPID, and > >> > (2) to use module renaming to rename the relevant modules to a different > >> > module name, so that we can import them without a conflict. > >> > >> > >> If I understand this, you are saying stage1 links stage0 (the normal, > >> non-cross-compiler used to build stage1), to build stage2? I agree > >> that should work, but if stage1 is multi-target isn't that level of > >> complexity not even needed? I'm not too familiar with GHC or its build > >> system, but a multi-target compiler that doesn't support normal TH > >> doesn't seem that hard to build in principle. > >> > >> John > >> > >> On Tue, Jan 19, 2016 at 3:59 PM, Ericson, John wrote: > >> > Ah thanks for the link. Template Haskell with only {-# TH-ONLY #-} > >> > imports is precisely equivalent to what I propose. I find a clean > >> > separation with that and normal TH useful, however, precisely so the > >> > stage2 compiler's source can include such a thing. > >> > > >> > On Tue, Jan 19, 2016 at 3:20 PM, Edward Z. Yang wrote: > >> >> Hello John > >> >> > >> >> You may find this implementation ticket of interest: > >> >> https://ghc.haskell.org/trac/ghc/ticket/11378 > >> >> > >> >> Edward > >> >> > >> >> Excerpts from Ericson, John's message of 2016-01-19 15:15:15 -0800: > >> >>> Cross-posting this as was suggested on the Haskell-Cafe list. While I > >> >>> envision this as normal feature that anyone can use, in practice its > >> >>> biggest consumers would be GHC devs. > >> >>> > >> >>> John > >> >>> > >> >>> ---------- Forwarded message ---------- > >> >>> From: Ericson, John > >> >>> Date: Tue, Jan 19, 2016 at 1:17 PM > >> >>> Subject: Host-Oriented Template Haskell > >> >>> To: Haskell-Cafe > >> >>> > >> >>> > >> >>> As is well known, TH and cross-compiling do not get along. There are > >> >>> various proposals on how to make this interaction less annoying, and I > >> >>> am not against them. But as I see it, the problem is largely inherent > >> >>> to the design of TH itself: since values can (usually) be lifted from > >> >>> compile-time to run-time, and normal definitions from upstream modules > >> >>> to downstream modules' TH, TH and normal code must "live in the same > >> >>> world". > >> >>> > >> >>> Now this restriction in turn bequeaths TH with much expressive power, > >> >>> and I wouldn't advocate getting rid of it. But many tasks do not need > >> >>> it, and in some cases, say in bootstrapping compilers[1] themselves, > >> >>> it is impossible to use TH because of it, even were all the current > >> >>> proposals implemented. > >> >>> > >> >>> For these reason, I propose a new TH variant which has much harsher > >> >>> phase separation. Normal definitions from upstream modules can not be > >> >>> used, lifting values is either not permitted or is allowed to fail > >> >>> (because of missing/incompatible definitions), and IO is defined to > >> >>> match the behavior of the host, not target, platform (in the cross > >> >>> compiling case). The only interaction between the two phases is that > >> >>> quoted syntax is resolved against the the run-time phase's definitions > >> >>> (just like today). > >> >>> > >> >>> Some of you may find this a shoddy substitute for defining a subset of > >> >>> Haskell which behaves identically on all platforms, and optionally > >> >>> constraining TH to it. But the big feature that my proposal offers and > >> >>> that one doesn't is to be able to independently specify compile-time > >> >>> dependencies for the host-oriented TH---this is analogous to the > >> >>> newish `Setup.hs` dependencies. That in turns leads to what I think is > >> >>> the "killer app" for Host-Oriented TH: exposing the various > >> >>> prepossessors we use (alex, happy, hsc2hs, even CPP) into libraries, > >> >>> and side-stepping any need for "executable dependencies" in Cabal. > >> >>> Note also that at least hsc2hs additionally requires host-IO---there > >> >>> may not even exist a C compiler on the target platform at all. > >> >>> > >> >>> Finally, forgive me if this has been brought up before. I've been > >> >>> thinking about this a while, and did a final pass over the GHC wiki to > >> >>> make sure it wasn't already proposed, but I could have missed > >> >>> something (this is also my first post to the list). > >> >>> > >> >>> John > >> >>> > >> >>> [1]: https://github.com/ghcjs/ghcjs/blob/master/lib/ghcjs-prim/GHCJS/Prim/Internal/Build.hs > >> >> _______________________________________________ > >> >> ghc-devs mailing list > >> >> ghc-devs at haskell.org > >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From moritz at lichtzwerge.de Thu Jan 21 06:55:36 2016 From: moritz at lichtzwerge.de (Moritz Angermann) Date: Thu, 21 Jan 2016 14:55:36 +0800 Subject: Host-Oriented Template Haskell In-Reply-To: <1453357380-sup-6390@sabre> References: <87si1t2pts.fsf@gnu.org> <1453245573-sup-5512@sabre> <1453350334-sup-7919@sabre> <1453357380-sup-6390@sabre> Message-ID: Colour me an interested party! For iOS one currently builds two different ghc compiler. One for the simulator (i386) and one for the actual device (arm). My initial work on bringing ghcjs?s TH support, (which basically ships the TH out to a process on the target to compile and brings back the compiled TH into the cross compiler) to ghc, was based on the idea of having a TH handler plugin, which would handle the TH parts, and could then be adapted for different TH situations. This of course could only work if the plugin was compiled with the same version of ghc, that the cross compiler was. I wonder if the multi-target pipeline might be simpler to achieve with the llvm backend. If someone is taking a shot at this, I?d like to help! Cheers, Moritz > On Jan 21, 2016, at 2:44 PM, Edward Z. Yang wrote: > > Yes, in principle, a compiler that supports cross-compiling to many > targets without needing to be configured (at build time) which > target it should support is ideal. Unfortunately, currently GHC > relies on autoconf to determine all of the necessary parameters > for a cross-compile. I am not sure how feasible it would be to > allow these parameters to be configured at runtime: it might be > easy, it might be hard! (And of course you have to arrange > to have cross-compiled all the boot libraries too...) > > In any case, I think that a GHC that permits changing cross-compilation > targets at runtime is a fine goal, and if it is supported, then we > would only have to make adjustments to GHC internally to distinguish > between the interfaces/objects for various targets (including itself.) > > Edward > > Excerpts from Ericson, John's message of 2016-01-20 21:23:28 -0800: >> Oops, Sent just to Edward by mistake. >> >> ---- >> >> That all sounds good to me---I think what I was thinking all along in >> fact, unless I am still missing some nuance :). >> >> My idea of using a multi-target compiler was to avoid needing stage0 >> to be the same version as stage1 (or adding a new stage, stage1 as in >> your alternative). The cross compiler is multi-target so it doesn't >> need to link another compiler to load plugins / run "host-oriented >> Template Haskell". I mentioned the usecase of trying to build a stage2 >> which needs plugins / Host-Oriented Template Haskell, but it could >> well apply to building anything else with the need for those to things >> (and not normal TH, which cannot be built with a cross compiler) >> >> In diagrams, rather than: >> >>> stage0 (version foo, platform-x -> platform-x) >>> ==> stage1 (version foo, platform-x -> platform-y) >>> ==> some program (with plugins, with host-oriented TH, without normal TH) >> >> or >> >>> stage0 (version bar, platform-x -> platform-x) >>> ==> stage1 (version foo, platform-x -> platform-x) -> >>> ==> stage2 (version foo, platform-x -> platform-y) -> >>> ==> some program (with plugins, with host-oriented TH, without normal TH) >> >> do just >> >>> stage0 (version bar, platform-x -> platform-x) >>> ==> stage1 (version foo, platform-x -> {platform-x, platform-y}) >>> ==> some program (with plugins, with host-oriented TH, without normal TH) >> >> Now it may be that building such a multi-target compiler today is just >> as arduous as making sure one has a native compiler of the same >> version before building the cross compiler, so my idea is of no >> practical value. But if so, I hope in the long term that could be >> fixed. >> >> John >> >> On Wed, Jan 20, 2016 at 8:37 PM, Edward Z. Yang wrote: >>> Hello John, >>> >>> Almost! >>> >>> As you point out, if you just want a cross-compiler, you don't >>> need to build stage2. The real problem is that we want stage0 >>> to be *the same version* as stage1, so that stage0 has the correct >>> API in order to load stage0 libraries which are going to be used >>> for TH, plugins, etc. (Alternately, build a non-cross-compiler >>> stage1, and then a cross-compiler stage2--NOT a cross compiled >>> stage 2.) >>> >>> Edward >>> >>> Excerpts from Ericson, John's message of 2016-01-19 16:13:24 -0800: >>>> From #11378: >>>> >>>>> Can we actually link against the old version of ghc? Yes we can! All we need is >>>>> (1) for it to have been built with a different IPID, and >>>>> (2) to use module renaming to rename the relevant modules to a different >>>>> module name, so that we can import them without a conflict. >>>> >>>> >>>> If I understand this, you are saying stage1 links stage0 (the normal, >>>> non-cross-compiler used to build stage1), to build stage2? I agree >>>> that should work, but if stage1 is multi-target isn't that level of >>>> complexity not even needed? I'm not too familiar with GHC or its build >>>> system, but a multi-target compiler that doesn't support normal TH >>>> doesn't seem that hard to build in principle. >>>> >>>> John >>>> >>>> On Tue, Jan 19, 2016 at 3:59 PM, Ericson, John wrote: >>>>> Ah thanks for the link. Template Haskell with only {-# TH-ONLY #-} >>>>> imports is precisely equivalent to what I propose. I find a clean >>>>> separation with that and normal TH useful, however, precisely so the >>>>> stage2 compiler's source can include such a thing. >>>>> >>>>> On Tue, Jan 19, 2016 at 3:20 PM, Edward Z. Yang wrote: >>>>>> Hello John >>>>>> >>>>>> You may find this implementation ticket of interest: >>>>>> https://ghc.haskell.org/trac/ghc/ticket/11378 >>>>>> >>>>>> Edward >>>>>> >>>>>> Excerpts from Ericson, John's message of 2016-01-19 15:15:15 -0800: >>>>>>> Cross-posting this as was suggested on the Haskell-Cafe list. While I >>>>>>> envision this as normal feature that anyone can use, in practice its >>>>>>> biggest consumers would be GHC devs. >>>>>>> >>>>>>> John >>>>>>> >>>>>>> ---------- Forwarded message ---------- >>>>>>> From: Ericson, John >>>>>>> Date: Tue, Jan 19, 2016 at 1:17 PM >>>>>>> Subject: Host-Oriented Template Haskell >>>>>>> To: Haskell-Cafe >>>>>>> >>>>>>> >>>>>>> As is well known, TH and cross-compiling do not get along. There are >>>>>>> various proposals on how to make this interaction less annoying, and I >>>>>>> am not against them. But as I see it, the problem is largely inherent >>>>>>> to the design of TH itself: since values can (usually) be lifted from >>>>>>> compile-time to run-time, and normal definitions from upstream modules >>>>>>> to downstream modules' TH, TH and normal code must "live in the same >>>>>>> world". >>>>>>> >>>>>>> Now this restriction in turn bequeaths TH with much expressive power, >>>>>>> and I wouldn't advocate getting rid of it. But many tasks do not need >>>>>>> it, and in some cases, say in bootstrapping compilers[1] themselves, >>>>>>> it is impossible to use TH because of it, even were all the current >>>>>>> proposals implemented. >>>>>>> >>>>>>> For these reason, I propose a new TH variant which has much harsher >>>>>>> phase separation. Normal definitions from upstream modules can not be >>>>>>> used, lifting values is either not permitted or is allowed to fail >>>>>>> (because of missing/incompatible definitions), and IO is defined to >>>>>>> match the behavior of the host, not target, platform (in the cross >>>>>>> compiling case). The only interaction between the two phases is that >>>>>>> quoted syntax is resolved against the the run-time phase's definitions >>>>>>> (just like today). >>>>>>> >>>>>>> Some of you may find this a shoddy substitute for defining a subset of >>>>>>> Haskell which behaves identically on all platforms, and optionally >>>>>>> constraining TH to it. But the big feature that my proposal offers and >>>>>>> that one doesn't is to be able to independently specify compile-time >>>>>>> dependencies for the host-oriented TH---this is analogous to the >>>>>>> newish `Setup.hs` dependencies. That in turns leads to what I think is >>>>>>> the "killer app" for Host-Oriented TH: exposing the various >>>>>>> prepossessors we use (alex, happy, hsc2hs, even CPP) into libraries, >>>>>>> and side-stepping any need for "executable dependencies" in Cabal. >>>>>>> Note also that at least hsc2hs additionally requires host-IO---there >>>>>>> may not even exist a C compiler on the target platform at all. >>>>>>> >>>>>>> Finally, forgive me if this has been brought up before. I've been >>>>>>> thinking about this a while, and did a final pass over the GHC wiki to >>>>>>> make sure it wasn't already proposed, but I could have missed >>>>>>> something (this is also my first post to the list). >>>>>>> >>>>>>> John >>>>>>> >>>>>>> [1]: https://github.com/ghcjs/ghcjs/blob/master/lib/ghcjs-prim/GHCJS/Prim/Internal/Build.hs >>>>>> _______________________________________________ >>>>>> 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 ????????????????? Moritz Angermann +49 170 54 33 0 74 moritz at lichtzwerge.de lichtzwerge GmbH Raiffeisenstr. 8 93185 Michelsneukirchen Amtsgericht Regensburg HRB 14723 Gesch?ftsf?hrung: Moritz Angermann, Ralf Sangl USt-Id: DE291948767 Diese E-Mail enth?lt vertrauliche und/oder rechtlich gesch?tzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrt?mlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. From ezyang at mit.edu Thu Jan 21 07:20:45 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Wed, 20 Jan 2016 23:20:45 -0800 Subject: Host-Oriented Template Haskell In-Reply-To: References: <87si1t2pts.fsf@gnu.org> <1453245573-sup-5512@sabre> <1453350334-sup-7919@sabre> <1453357380-sup-6390@sabre> Message-ID: <1453360828-sup-6927@sabre> I've filed a Trac ticket for this: https://ghc.haskell.org/trac/ghc/ticket/11470#ticket Edward Excerpts from Moritz Angermann's message of 2016-01-20 22:55:36 -0800: > Colour me an interested party! For iOS one currently builds two > different ghc compiler. One for the simulator (i386) and one for the > actual device (arm). My initial work on bringing ghcjs?s TH support, > (which basically ships the TH out to a process on the target to compile > and brings back the compiled TH into the cross compiler) to ghc, was > based on the idea of having a TH handler plugin, which would handle the > TH parts, and could then be adapted for different TH situations. This > of course could only work if the plugin was compiled with the same version > of ghc, that the cross compiler was. > > I wonder if the multi-target pipeline might be simpler to achieve with > the llvm backend. > > If someone is taking a shot at this, I?d like to help! > > Cheers, > Moritz > > > On Jan 21, 2016, at 2:44 PM, Edward Z. Yang wrote: > > > > Yes, in principle, a compiler that supports cross-compiling to many > > targets without needing to be configured (at build time) which > > target it should support is ideal. Unfortunately, currently GHC > > relies on autoconf to determine all of the necessary parameters > > for a cross-compile. I am not sure how feasible it would be to > > allow these parameters to be configured at runtime: it might be > > easy, it might be hard! (And of course you have to arrange > > to have cross-compiled all the boot libraries too...) > > > > In any case, I think that a GHC that permits changing cross-compilation > > targets at runtime is a fine goal, and if it is supported, then we > > would only have to make adjustments to GHC internally to distinguish > > between the interfaces/objects for various targets (including itself.) > > > > Edward > > > > Excerpts from Ericson, John's message of 2016-01-20 21:23:28 -0800: > >> Oops, Sent just to Edward by mistake. > >> > >> ---- > >> > >> That all sounds good to me---I think what I was thinking all along in > >> fact, unless I am still missing some nuance :). > >> > >> My idea of using a multi-target compiler was to avoid needing stage0 > >> to be the same version as stage1 (or adding a new stage, stage1 as in > >> your alternative). The cross compiler is multi-target so it doesn't > >> need to link another compiler to load plugins / run "host-oriented > >> Template Haskell". I mentioned the usecase of trying to build a stage2 > >> which needs plugins / Host-Oriented Template Haskell, but it could > >> well apply to building anything else with the need for those to things > >> (and not normal TH, which cannot be built with a cross compiler) > >> > >> In diagrams, rather than: > >> > >>> stage0 (version foo, platform-x -> platform-x) > >>> ==> stage1 (version foo, platform-x -> platform-y) > >>> ==> some program (with plugins, with host-oriented TH, without normal TH) > >> > >> or > >> > >>> stage0 (version bar, platform-x -> platform-x) > >>> ==> stage1 (version foo, platform-x -> platform-x) -> > >>> ==> stage2 (version foo, platform-x -> platform-y) -> > >>> ==> some program (with plugins, with host-oriented TH, without normal TH) > >> > >> do just > >> > >>> stage0 (version bar, platform-x -> platform-x) > >>> ==> stage1 (version foo, platform-x -> {platform-x, platform-y}) > >>> ==> some program (with plugins, with host-oriented TH, without normal TH) > >> > >> Now it may be that building such a multi-target compiler today is just > >> as arduous as making sure one has a native compiler of the same > >> version before building the cross compiler, so my idea is of no > >> practical value. But if so, I hope in the long term that could be > >> fixed. > >> > >> John > >> > >> On Wed, Jan 20, 2016 at 8:37 PM, Edward Z. Yang wrote: > >>> Hello John, > >>> > >>> Almost! > >>> > >>> As you point out, if you just want a cross-compiler, you don't > >>> need to build stage2. The real problem is that we want stage0 > >>> to be *the same version* as stage1, so that stage0 has the correct > >>> API in order to load stage0 libraries which are going to be used > >>> for TH, plugins, etc. (Alternately, build a non-cross-compiler > >>> stage1, and then a cross-compiler stage2--NOT a cross compiled > >>> stage 2.) > >>> > >>> Edward > >>> > >>> Excerpts from Ericson, John's message of 2016-01-19 16:13:24 -0800: > >>>> From #11378: > >>>> > >>>>> Can we actually link against the old version of ghc? Yes we can! All we need is > >>>>> (1) for it to have been built with a different IPID, and > >>>>> (2) to use module renaming to rename the relevant modules to a different > >>>>> module name, so that we can import them without a conflict. > >>>> > >>>> > >>>> If I understand this, you are saying stage1 links stage0 (the normal, > >>>> non-cross-compiler used to build stage1), to build stage2? I agree > >>>> that should work, but if stage1 is multi-target isn't that level of > >>>> complexity not even needed? I'm not too familiar with GHC or its build > >>>> system, but a multi-target compiler that doesn't support normal TH > >>>> doesn't seem that hard to build in principle. > >>>> > >>>> John > >>>> > >>>> On Tue, Jan 19, 2016 at 3:59 PM, Ericson, John wrote: > >>>>> Ah thanks for the link. Template Haskell with only {-# TH-ONLY #-} > >>>>> imports is precisely equivalent to what I propose. I find a clean > >>>>> separation with that and normal TH useful, however, precisely so the > >>>>> stage2 compiler's source can include such a thing. > >>>>> > >>>>> On Tue, Jan 19, 2016 at 3:20 PM, Edward Z. Yang wrote: > >>>>>> Hello John > >>>>>> > >>>>>> You may find this implementation ticket of interest: > >>>>>> https://ghc.haskell.org/trac/ghc/ticket/11378 > >>>>>> > >>>>>> Edward > >>>>>> > >>>>>> Excerpts from Ericson, John's message of 2016-01-19 15:15:15 -0800: > >>>>>>> Cross-posting this as was suggested on the Haskell-Cafe list. While I > >>>>>>> envision this as normal feature that anyone can use, in practice its > >>>>>>> biggest consumers would be GHC devs. > >>>>>>> > >>>>>>> John > >>>>>>> > >>>>>>> ---------- Forwarded message ---------- > >>>>>>> From: Ericson, John > >>>>>>> Date: Tue, Jan 19, 2016 at 1:17 PM > >>>>>>> Subject: Host-Oriented Template Haskell > >>>>>>> To: Haskell-Cafe > >>>>>>> > >>>>>>> > >>>>>>> As is well known, TH and cross-compiling do not get along. There are > >>>>>>> various proposals on how to make this interaction less annoying, and I > >>>>>>> am not against them. But as I see it, the problem is largely inherent > >>>>>>> to the design of TH itself: since values can (usually) be lifted from > >>>>>>> compile-time to run-time, and normal definitions from upstream modules > >>>>>>> to downstream modules' TH, TH and normal code must "live in the same > >>>>>>> world". > >>>>>>> > >>>>>>> Now this restriction in turn bequeaths TH with much expressive power, > >>>>>>> and I wouldn't advocate getting rid of it. But many tasks do not need > >>>>>>> it, and in some cases, say in bootstrapping compilers[1] themselves, > >>>>>>> it is impossible to use TH because of it, even were all the current > >>>>>>> proposals implemented. > >>>>>>> > >>>>>>> For these reason, I propose a new TH variant which has much harsher > >>>>>>> phase separation. Normal definitions from upstream modules can not be > >>>>>>> used, lifting values is either not permitted or is allowed to fail > >>>>>>> (because of missing/incompatible definitions), and IO is defined to > >>>>>>> match the behavior of the host, not target, platform (in the cross > >>>>>>> compiling case). The only interaction between the two phases is that > >>>>>>> quoted syntax is resolved against the the run-time phase's definitions > >>>>>>> (just like today). > >>>>>>> > >>>>>>> Some of you may find this a shoddy substitute for defining a subset of > >>>>>>> Haskell which behaves identically on all platforms, and optionally > >>>>>>> constraining TH to it. But the big feature that my proposal offers and > >>>>>>> that one doesn't is to be able to independently specify compile-time > >>>>>>> dependencies for the host-oriented TH---this is analogous to the > >>>>>>> newish `Setup.hs` dependencies. That in turns leads to what I think is > >>>>>>> the "killer app" for Host-Oriented TH: exposing the various > >>>>>>> prepossessors we use (alex, happy, hsc2hs, even CPP) into libraries, > >>>>>>> and side-stepping any need for "executable dependencies" in Cabal. > >>>>>>> Note also that at least hsc2hs additionally requires host-IO---there > >>>>>>> may not even exist a C compiler on the target platform at all. > >>>>>>> > >>>>>>> Finally, forgive me if this has been brought up before. I've been > >>>>>>> thinking about this a while, and did a final pass over the GHC wiki to > >>>>>>> make sure it wasn't already proposed, but I could have missed > >>>>>>> something (this is also my first post to the list). > >>>>>>> > >>>>>>> John > >>>>>>> > >>>>>>> [1]: https://github.com/ghcjs/ghcjs/blob/master/lib/ghcjs-prim/GHCJS/Prim/Internal/Build.hs > >>>>>> _______________________________________________ > >>>>>> 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 > > ????????????????? > Moritz Angermann > +49 170 54 33 0 74 > moritz at lichtzwerge.de > > lichtzwerge GmbH > Raiffeisenstr. 8 > 93185 Michelsneukirchen > > Amtsgericht Regensburg HRB 14723 > Gesch?ftsf?hrung: Moritz Angermann, Ralf Sangl > USt-Id: DE291948767 > > Diese E-Mail enth?lt vertrauliche und/oder rechtlich gesch?tzte > Informationen. Wenn Sie nicht der richtige Adressat sind oder diese > E-Mail irrt?mlich erhalten haben, informieren Sie bitte sofort den > Absender und vernichten Sie diese Mail. > Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail > ist nicht gestattet. > This e-mail may contain confidential and/or privileged information. > If you are not the intended recipient (or have received this e-mail in > error) please notify the sender immediately and destroy this e-mail. > Any unauthorized copying, disclosure or distribution of the material in > this e-mail is strictly forbidden. From mail at joachim-breitner.de Thu Jan 21 09:19:11 2016 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 21 Jan 2016 10:19:11 +0100 Subject: CallStack naming In-Reply-To: <1453310647.1815559.497698170.68A46486@webmail.messagingengine.com> References: <96F502AD-4AC6-40FA-BD9C-C9C063C2DDE0@cis.upenn.edu> <659dc968669143e0972602a72fb7753e@DB4PR30MB030.064d.mgd.msft.net> <1453305947.1797061.497600914.32732A90@webmail.messagingengine.com> <13f3ddc1d01a4f46ac15a051cc8ff049@DB4PR30MB030.064d.mgd.msft.net> <1453310647.1815559.497698170.68A46486@webmail.messagingengine.com> Message-ID: <1453367951.23159.6.camel@joachim-breitner.de> Hi, Am Mittwoch, den 20.01.2016, 09:24 -0800 schrieb Eric Seidel: > The problem is that I don't know how to implement > `withFrozenCallStack` > (included in the wiki) as a Haskell function if CallStacks aren't > implicit parameters under-the-hood. breaking it further down, the problem is not with `withFrozenCallStack` per se, but rather with any code that wants to set the current callstack, e.g. anything of the current form ? let ?callStack = ... ? in .. How would that look with a magic nullary constraint "AppendsCallStack"? It?d probably need a built-in function setCallStack :: CallStack -> (AppendsCallStack => a) -> a with which we can likely implement `withFrozenCallStack` again: withFrozenCallStack :: AppendsCallStack => (AppendsCallStack => a) -> a withFrozenCallStack do_this = ? -- we pop the stack before freezing it to remove ? -- withFrozenCallStack's call-site ? let callStack = freezeCallStack (popCallStack callStack) ? in setCallStack callStack do_this It might need a second call to popCallStack depending on the precise semantics of `callStack :: AppendsCallStack => CallStack` (i.e. whether that does pop one entry off itself). Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From ben at smart-cactus.org Thu Jan 21 11:01:05 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Thu, 21 Jan 2016 12:01:05 +0100 Subject: Improving trac notifications In-Reply-To: References: <87twn297mm.fsf@smart-cactus.org> <874meq8s53.fsf@smart-cactus.org> Message-ID: <87y4bjfb7y.fsf@smart-cactus.org> Matthew Pickering writes: > Herbert now seems to have applied the patch. Hopefully this will improve > the email situation for everyone. > Thanks Herbert and Matt! Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From simonpj at microsoft.com Thu Jan 21 12:07:48 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 21 Jan 2016 12:07:48 +0000 Subject: CallStack naming In-Reply-To: <1453367951.23159.6.camel@joachim-breitner.de> References: <96F502AD-4AC6-40FA-BD9C-C9C063C2DDE0@cis.upenn.edu> <659dc968669143e0972602a72fb7753e@DB4PR30MB030.064d.mgd.msft.net> <1453305947.1797061.497600914.32732A90@webmail.messagingengine.com> <13f3ddc1d01a4f46ac15a051cc8ff049@DB4PR30MB030.064d.mgd.msft.net> <1453310647.1815559.497698170.68A46486@webmail.messagingengine.com> <1453367951.23159.6.camel@joachim-breitner.de> Message-ID: | It?d probably need a built-in function | | setCallStack :: CallStack -> (AppendsCallStack => a) -> a Correct. This is easy to write in Core but not in Haskell. We also need something similar for Typeable, when we get a type-indexed version of TypeRep withTypeable :: TypeRep a -> (Typeable a => r) => r Additionally, for ICallStack (bikeshed: I don?t like "AppendsCallStack") we would need to ensure that the new local instance over-rode all others, like for implicit parameters; see Note [Shadowing of Implicit Parameters] in TcInteract. This part isn't necessary for Typeable because all witnesses are the same. Bother. Well, in the short term, let's * implement it with the constraint synonym * bikeshed about names * write down the user-visible API, ensuring that it makes no mention of implicit parameters (provide setCallStack) Then we can implement the API differently later if we so desire. The main disadvantage is that the abstraction is leaky. We can't *prevent* users from seeing and using the implicit parameter. Does that sound like a plan. Might you do it Eric? The urgency is just to get 8.0 out with an API that we like Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | Joachim Breitner | Sent: 21 January 2016 09:19 | To: ghc-devs at haskell.org | Subject: Re: CallStack naming | | Hi, | | Am Mittwoch, den 20.01.2016, 09:24 -0800 schrieb Eric Seidel: | > The problem is that I don't know how to implement | > `withFrozenCallStack` (included in the wiki) as a Haskell function | if | > CallStacks aren't implicit parameters under-the-hood. | | breaking it further down, the problem is not with | `withFrozenCallStack` per se, but rather with any code that wants to | set the current callstack, e.g. anything of the current form | | ? let ?callStack = ... | ? in .. | | How would that look with a magic nullary constraint | "AppendsCallStack"? | It?d probably need a built-in function | | setCallStack :: CallStack -> (AppendsCallStack => a) -> a | | with which we can likely implement `withFrozenCallStack` again: | | withFrozenCallStack :: AppendsCallStack => (AppendsCallStack => a) -> | a withFrozenCallStack do_this = | ? -- we pop the stack before freezing it to remove | ? -- withFrozenCallStack's call-site | ? let callStack = freezeCallStack (popCallStack callStack) | ? in setCallStack callStack do_this | | It might need a second call to popCallStack depending on the precise | semantics of `callStack :: AppendsCallStack => CallStack` (i.e. | whether that does pop one entry off itself). | | Greetings, | Joachim | | | -- | Joachim ?nomeata? Breitner | mail at joachim-breitner.de ? | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.jo | achim- | breitner.de%2f&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cdece5 | 7f942bc42b0dd2308d32243eff4%7c72f988bf86f141af91ab2d7cd011db47%7c1&sda | ta=67ZZO9n8VFDeRV7DCzaI46uxdf%2bPMC4Plx5XY8tMcUc%3d | Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F | Debian Developer: nomeata at debian.org From asr at eafit.edu.co Thu Jan 21 12:36:12 2016 From: asr at eafit.edu.co (=?UTF-8?B?QW5kcsOpcyBTaWNhcmQtUmFtw61yZXo=?=) Date: Thu, 21 Jan 2016 07:36:12 -0500 Subject: GHC 8.0.1 RC 1 and the -fwarn-monomorphism-restriction option Message-ID: Dear all, On 13 January 2016 at 10:43, Ben Gamari wrote: > The GHC Team is very pleased to announce the first release candidate of > the Glasgow Haskell Compiler 8.0.1 release. For compiling Agda we use the -fwarn-monomorphism-restriction option. Using GHC 7.6.3, 7.8.4 and 7.10.3 we don't get any warning, but using GHC 8.0.1 RC 1 this option generates warnings in 103 files. Could someone give me some information about this new behaviour? Best, -- Andr?s From austin at well-typed.com Thu Jan 21 13:07:43 2016 From: austin at well-typed.com (Austin Seipp) Date: Thu, 21 Jan 2016 07:07:43 -0600 Subject: Phabricator upgrade - CI will be down for a short time Message-ID: Hi *, TL;DR Phabricator will go down for about 5 minutes later today, but the CI will be off for a while longer. I wanted to alert everyone: I'll be upgrading Phabricator shortly this morning, after doing a bunch of testing to make sure our upgrade will go smoothly. Luckily, it will go quite smoothly. The upgrade on the database backup I performed went without a hitch, and everything still seems to work quite well. You shouldn't really notice a huge difference in day-to-day usage... However, it will require redoing some pieces of the CI system, so when I do the upgrade, _Harbormaster won't work for a short time_. That means your patches won't get built - do not be alarmed by this. I tested this before, but we'll have to do some other changes to make it happen 'for real' this time (including some CDN fiddling). Ben also recently rewrote the terrible build script I originally wrote, so I'd like to deploy it instead if possible. Thomas has also rightfully prodded me about some of the current CI complaints, so hopefully these can be sorted out too. This upgrade has been long in the tooth, but luckily you shouldn't notice much beyond a minor hitch here, and CI being gone for a little while. Hopefully it should be done by the end of the day. In the mean time, I'll give Ben access to the newer (20 core) buildbot, so he'll be able to validate your changes quite quickly for integration. I'll reply to this email with updates. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From simonpj at microsoft.com Thu Jan 21 13:26:55 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 21 Jan 2016 13:26:55 +0000 Subject: GHC 8.0.1 RC 1 and the -fwarn-monomorphism-restriction option In-Reply-To: References: Message-ID: <3a374fbaf65d4e1680c9d3be45154021@DB4PR30MB030.064d.mgd.msft.net> No, if that answers your question, good. Ben: is this change in the release notes? Simon | -----Original Message----- | From: andres.sicard.ramirez at gmail.com | [mailto:andres.sicard.ramirez at gmail.com] On Behalf Of Andr?s Sicard- | Ram?rez | Sent: 21 January 2016 13:25 | To: Simon Peyton Jones | Cc: Thomas Miedema | Subject: Re: GHC 8.0.1 RC 1 and the -fwarn-monomorphism-restriction | option | | On 21 January 2016 at 08:11, Simon Peyton Jones | wrote: | > Can you give a small concrete test case, showing the different | behaviour? | | I received this answer from Thomas Miedema: | | Thomas Miedema wrote: | > Reinstate monomorphism-restriction warnings | > | > This patch is driven by Trac #10935, and reinstates the | > -fwarn-monomorphism-restriction warning. It was first lost in | 2010: | > d2ce0f52d "Super-monster patch implementing the new typechecker | -- at | > last" | > | > I think the existing documentation is accurate; it is not even | > turned on by -Wall. | > | > I added one test. | | It was exactly what I was looking for. Do you still need a concrete | test case? | | -- | Andr?s From ben at smart-cactus.org Thu Jan 21 13:34:28 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Thu, 21 Jan 2016 14:34:28 +0100 Subject: GHC 8.0.1 RC 1 and the -fwarn-monomorphism-restriction option In-Reply-To: <3a374fbaf65d4e1680c9d3be45154021@DB4PR30MB030.064d.mgd.msft.net> References: <3a374fbaf65d4e1680c9d3be45154021@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <87twm7f44b.fsf@smart-cactus.org> Simon Peyton Jones writes: > No, if that answers your question, good. > > Ben: is this change in the release notes? > Nope, but it will be 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: From ben at smart-cactus.org Thu Jan 21 13:39:21 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Thu, 21 Jan 2016 14:39:21 +0100 Subject: GHC 8.0.1 RC 1 and the -fwarn-monomorphism-restriction option In-Reply-To: <3a374fbaf65d4e1680c9d3be45154021@DB4PR30MB030.064d.mgd.msft.net> References: <3a374fbaf65d4e1680c9d3be45154021@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <87r3hbf3w6.fsf@smart-cactus.org> Simon Peyton Jones writes: > No, if that answers your question, good. > > Ben: is this change in the release notes? > This now probably ought to be -Wmonomorphism-restriction instead of -fwarn-monomorphism-restriction, correct? Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From hvriedel at gmail.com Thu Jan 21 13:56:02 2016 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Thu, 21 Jan 2016 14:56:02 +0100 Subject: CallStack naming In-Reply-To: <96F502AD-4AC6-40FA-BD9C-C9C063C2DDE0@cis.upenn.edu> (Richard Eisenberg's message of "Wed, 20 Jan 2016 00:39:32 -0500") References: <96F502AD-4AC6-40FA-BD9C-C9C063C2DDE0@cis.upenn.edu> Message-ID: <87powvxci5.fsf@gmail.com> On 2016-01-20 at 06:39:32 +0100, Richard Eisenberg wrote: > I'm sure there's an easy answer to this, but I'm wondering: why is the > CallStack feature implemented with implicit parameters instead of just > a magical constraint? Whenever I use this feature, I don't want to > have to enable -XImplicitParams and then make sure I get the name > right. What would be wrong with, e.g., > >> undefined :: AppendsCallStack => a > > Seems simpler. Is it problems with a nullary class? Btw, would that, as a side-effect, make the currently shown type-signature in GHCi a bit nicer than the current ,---- | GHCi, version 8.1.20160117: http://www.haskell.org/ghc/ :? for help | Loaded GHCi configuration from /home/hvr/.ghci | | ?:1> :info error | error :: forall (v :: GHC.Types.Levity) (a :: TYPE v). ?callStack::GHC.Stack.Types.CallStack => [Char] -> a -- Defined in ?GHC.Err? | | ?:2> :info undefined | undefined :: forall (v :: GHC.Types.Levity) (a :: TYPE v). ?callStack::GHC.Stack.Types.CallStack => a -- Defined in ?GHC.Err? `---- ...? From jan.stolarek at p.lodz.pl Thu Jan 21 14:50:49 2016 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Thu, 21 Jan 2016 15:50:49 +0100 Subject: Special treatment of family and role in the parser In-Reply-To: <56A09792.30805@gmail.com> References: <201601201942.18508.jan.stolarek@p.lodz.pl> <56A007B5.6000305@gmail.com> <56A09792.30805@gmail.com> Message-ID: <201601211550.49875.jan.stolarek@p.lodz.pl> I'll take a look at the parser, see if we can do better. > I also suggest that keywords introduced by GHC extensions should be lexed as keywords regardless > of whether extension is enabled or not: this way users won't get spurious errors if they > suddenly enable extension and it turns out that some of their identifiers have become keywords. I would be cautious here. Patch I am working on right now will use "kind" as a reserved identifier. It will only be allowed after `data` keyword. Making it a reserved word everywhere would be a major issue as many people doing type-level programming have variables named "kind". You ar right that problem would be much smaller if the keyword was "datakind" but somehow I am reluctant to seeing things like "datakindmember", "typeinstance", etc. What others think about this proposal? Janek --- Politechnika ??dzka Lodz University of Technology Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system. From alan.zimm at gmail.com Thu Jan 21 14:58:12 2016 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Thu, 21 Jan 2016 16:58:12 +0200 Subject: Special treatment of family and role in the parser In-Reply-To: <201601211550.49875.jan.stolarek@p.lodz.pl> References: <201601201942.18508.jan.stolarek@p.lodz.pl> <56A007B5.6000305@gmail.com> <56A09792.30805@gmail.com> <201601211550.49875.jan.stolarek@p.lodz.pl> Message-ID: At the risk of stating the obvious, have you looked at https://github.com/ghc/ghc/blob/master/compiler/parser/Parser.y#L2993? Alan On 21 Jan 2016 4:50 PM, "Jan Stolarek" wrote: > I'll take a look at the parser, see if we can do better. > > > I also suggest that keywords introduced by GHC extensions should be > lexed as keywords regardless > > of whether extension is enabled or not: this way users won't get > spurious errors if they > > suddenly enable extension and it turns out that some of their > identifiers have become keywords. > I would be cautious here. Patch I am working on right now will use "kind" > as a reserved > identifier. It will only be allowed after `data` keyword. Making it a > reserved word everywhere > would be a major issue as many people doing type-level programming have > variables named "kind". > You ar right that problem would be much smaller if the keyword was > "datakind" but somehow I am > reluctant to seeing things like "datakindmember", "typeinstance", etc. > What others think about > this proposal? > > Janek > > --- > Politechnika ??dzka > Lodz University of Technology > > Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. > Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez > pomy?k? > prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. > > This email contains information intended solely for the use of the > individual to whom it is addressed. > If you are not the intended recipient or if you have received this message > in error, > please notify the sender and delete it from your system. > _______________________________________________ > 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: From jan.stolarek at p.lodz.pl Thu Jan 21 15:02:00 2016 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Thu, 21 Jan 2016 16:02:00 +0100 Subject: Special treatment of family and role in the parser In-Reply-To: References: <201601201942.18508.jan.stolarek@p.lodz.pl> <201601211550.49875.jan.stolarek@p.lodz.pl> Message-ID: <201601211602.00891.jan.stolarek@p.lodz.pl> Yes, I have seen the note, but thank you nevertheless :-) Janek Dnia czwartek, 21 stycznia 2016, Alan & Kim Zimmerman napisa?: > At the risk of stating the obvious, have you looked at > https://github.com/ghc/ghc/blob/master/compiler/parser/Parser.y#L2993? > > Alan > > On 21 Jan 2016 4:50 PM, "Jan Stolarek" wrote: > > I'll take a look at the parser, see if we can do better. > > > > > I also suggest that keywords introduced by GHC extensions should be > > > > lexed as keywords regardless > > > > > of whether extension is enabled or not: this way users won't get > > > > spurious errors if they > > > > > suddenly enable extension and it turns out that some of their > > > > identifiers have become keywords. > > I would be cautious here. Patch I am working on right now will use "kind" > > as a reserved > > identifier. It will only be allowed after `data` keyword. Making it a > > reserved word everywhere > > would be a major issue as many people doing type-level programming have > > variables named "kind". > > You ar right that problem would be much smaller if the keyword was > > "datakind" but somehow I am > > reluctant to seeing things like "datakindmember", "typeinstance", etc. > > What others think about > > this proposal? > > > > Janek > > > > --- > > Politechnika ??dzka > > Lodz University of Technology > > > > Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. > > Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez > > pomy?k? > > prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. > > > > This email contains information intended solely for the use of the > > individual to whom it is addressed. > > If you are not the intended recipient or if you have received this > > message in error, > > please notify the sender and delete it from your system. > > _______________________________________________ > > 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 eir at cis.upenn.edu Thu Jan 21 15:12:30 2016 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Thu, 21 Jan 2016 10:12:30 -0500 Subject: Special treatment of family and role in the parser In-Reply-To: <201601211550.49875.jan.stolarek@p.lodz.pl> References: <201601201942.18508.jan.stolarek@p.lodz.pl> <56A007B5.6000305@gmail.com> <56A09792.30805@gmail.com> <201601211550.49875.jan.stolarek@p.lodz.pl> Message-ID: My opinion is that if we can avoid stealing syntax, we should. I am indeed concerned about complicating the parser overmuch... but I don't think that parser code complexity should, by itself, drive the language design. Richard On Jan 21, 2016, at 9:50 AM, Jan Stolarek wrote: > I'll take a look at the parser, see if we can do better. > >> I also suggest that keywords introduced by GHC extensions should be lexed as keywords regardless >> of whether extension is enabled or not: this way users won't get spurious errors if they >> suddenly enable extension and it turns out that some of their identifiers have become keywords. > I would be cautious here. Patch I am working on right now will use "kind" as a reserved > identifier. It will only be allowed after `data` keyword. Making it a reserved word everywhere > would be a major issue as many people doing type-level programming have variables named "kind". > You ar right that problem would be much smaller if the keyword was "datakind" but somehow I am > reluctant to seeing things like "datakindmember", "typeinstance", etc. What others think about > this proposal? > > Janek > > --- > Politechnika ??dzka > Lodz University of Technology > > Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. > Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k? > prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. > > This email contains information intended solely for the use of the individual to whom it is addressed. > If you are not the intended recipient or if you have received this message in error, > please notify the sender and delete it from your system. From austin at well-typed.com Thu Jan 21 16:12:04 2016 From: austin at well-typed.com (Austin Seipp) Date: Thu, 21 Jan 2016 10:12:04 -0600 Subject: Phabricator upgrade - CI will be down for a short time In-Reply-To: References: Message-ID: Hello *, The server will be going down in just a moment for the upgrade. I turned off jobs earlier this morning so the build queue is now empty. Hold tight. On Thu, Jan 21, 2016 at 7:07 AM, Austin Seipp wrote: > Hi *, > > TL;DR Phabricator will go down for about 5 minutes later today, but > the CI will be off for a while longer. > > I wanted to alert everyone: I'll be upgrading Phabricator shortly this > morning, after doing a bunch of testing to make sure our upgrade will > go smoothly. > > Luckily, it will go quite smoothly. The upgrade on the database backup > I performed went without a hitch, and everything still seems to work > quite well. You shouldn't really notice a huge difference in > day-to-day usage... > > However, it will require redoing some pieces of the CI system, so when > I do the upgrade, _Harbormaster won't work for a short time_. That > means your patches won't get built - do not be alarmed by this. > > I tested this before, but we'll have to do some other changes to make > it happen 'for real' this time (including some CDN fiddling). Ben also > recently rewrote the terrible build script I originally wrote, so I'd > like to deploy it instead if possible. Thomas has also rightfully > prodded me about some of the current CI complaints, so hopefully these > can be sorted out too. > > This upgrade has been long in the tooth, but luckily you shouldn't > notice much beyond a minor hitch here, and CI being gone for a little > while. Hopefully it should be done by the end of the day. > > In the mean time, I'll give Ben access to the newer (20 core) > buildbot, so he'll be able to validate your changes quite quickly for > integration. > > I'll reply to this email with updates. > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From eric at seidel.io Thu Jan 21 16:14:43 2016 From: eric at seidel.io (Eric Seidel) Date: Thu, 21 Jan 2016 08:14:43 -0800 Subject: CallStack naming In-Reply-To: References: <96F502AD-4AC6-40FA-BD9C-C9C063C2DDE0@cis.upenn.edu> <659dc968669143e0972602a72fb7753e@DB4PR30MB030.064d.mgd.msft.net> <1453305947.1797061.497600914.32732A90@webmail.messagingengine.com> <13f3ddc1d01a4f46ac15a051cc8ff049@DB4PR30MB030.064d.mgd.msft.net> <1453310647.1815559.497698170.68A46486@webmail.messagingengine.com> <1453367951.23159.6.camel@joachim-breitner.de> Message-ID: <1453392883.2128646.498701002.6ACCB74F@webmail.messagingengine.com> On Thu, Jan 21, 2016, at 04:07, Simon Peyton Jones wrote: > Well, in the short term, let's > * bikeshed about names Ok, I don't like ICallStack :) It sounds like a C# interface, which, while technically sort of accurate, is very misleading since users will never write an instance. I'd prefer something a bit more descriptive, like - WithCallStack - HasCallStack - GetsCallStack (in no particular order) > * write down the user-visible API, ensuring that it makes > no mention of implicit parameters (provide setCallStack) > > Then we can implement the API differently later if we so desire. In that case we'll probably want to move the CallStack section of the user guide elsewhere, right now it's a subsection of ImplicitParams. > The main disadvantage is that the abstraction is leaky. We can't > *prevent* users from seeing and using the implicit parameter. True, so perhaps a single mention of the implicit parameter, explaining that it's not part of the API and that using it is *explicitly unsupported*, i.e. we may change the implementation later. > Does that sound like a plan. Might you do it Eric? The urgency is just > to get 8.0 out with an API that we like Sure, I'll try to have a patch out later today. From austin at well-typed.com Thu Jan 21 16:21:24 2016 From: austin at well-typed.com (Austin Seipp) Date: Thu, 21 Jan 2016 10:21:24 -0600 Subject: Phabricator upgrade - CI will be down for a short time In-Reply-To: References: Message-ID: The upgrade is complete. I'll keep everyone updated on the pending Harbormaster situation. On Thu, Jan 21, 2016 at 10:12 AM, Austin Seipp wrote: > Hello *, > > The server will be going down in just a moment for the upgrade. I > turned off jobs earlier this morning so the build queue is now empty. > Hold tight. > > On Thu, Jan 21, 2016 at 7:07 AM, Austin Seipp wrote: >> Hi *, >> >> TL;DR Phabricator will go down for about 5 minutes later today, but >> the CI will be off for a while longer. >> >> I wanted to alert everyone: I'll be upgrading Phabricator shortly this >> morning, after doing a bunch of testing to make sure our upgrade will >> go smoothly. >> >> Luckily, it will go quite smoothly. The upgrade on the database backup >> I performed went without a hitch, and everything still seems to work >> quite well. You shouldn't really notice a huge difference in >> day-to-day usage... >> >> However, it will require redoing some pieces of the CI system, so when >> I do the upgrade, _Harbormaster won't work for a short time_. That >> means your patches won't get built - do not be alarmed by this. >> >> I tested this before, but we'll have to do some other changes to make >> it happen 'for real' this time (including some CDN fiddling). Ben also >> recently rewrote the terrible build script I originally wrote, so I'd >> like to deploy it instead if possible. Thomas has also rightfully >> prodded me about some of the current CI complaints, so hopefully these >> can be sorted out too. >> >> This upgrade has been long in the tooth, but luckily you shouldn't >> notice much beyond a minor hitch here, and CI being gone for a little >> while. Hopefully it should be done by the end of the day. >> >> In the mean time, I'll give Ben access to the newer (20 core) >> buildbot, so he'll be able to validate your changes quite quickly for >> integration. >> >> I'll reply to this email with updates. >> >> -- >> Regards, >> >> Austin Seipp, Haskell Consultant >> Well-Typed LLP, http://www.well-typed.com/ > > > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From austin at well-typed.com Thu Jan 21 16:23:00 2016 From: austin at well-typed.com (Austin Seipp) Date: Thu, 21 Jan 2016 10:23:00 -0600 Subject: Phabricator upgrade - CI will be down for a short time In-Reply-To: References: Message-ID: By the way, this might be a good time to upgrade your Arcanist as well: $ arc upgrade You can then do: $ arc version Which should give you output something like this: $ arc version arcanist b87138356a9c71ad5e08eaa05399d0233529bc71 (15 Jan 2016) libphutil c3fd3a8bb2c319982279ead972354c8bf760145c (14 Jan 2016) On Thu, Jan 21, 2016 at 10:21 AM, Austin Seipp wrote: > The upgrade is complete. I'll keep everyone updated on the pending > Harbormaster situation. > > On Thu, Jan 21, 2016 at 10:12 AM, Austin Seipp wrote: >> Hello *, >> >> The server will be going down in just a moment for the upgrade. I >> turned off jobs earlier this morning so the build queue is now empty. >> Hold tight. >> >> On Thu, Jan 21, 2016 at 7:07 AM, Austin Seipp wrote: >>> Hi *, >>> >>> TL;DR Phabricator will go down for about 5 minutes later today, but >>> the CI will be off for a while longer. >>> >>> I wanted to alert everyone: I'll be upgrading Phabricator shortly this >>> morning, after doing a bunch of testing to make sure our upgrade will >>> go smoothly. >>> >>> Luckily, it will go quite smoothly. The upgrade on the database backup >>> I performed went without a hitch, and everything still seems to work >>> quite well. You shouldn't really notice a huge difference in >>> day-to-day usage... >>> >>> However, it will require redoing some pieces of the CI system, so when >>> I do the upgrade, _Harbormaster won't work for a short time_. That >>> means your patches won't get built - do not be alarmed by this. >>> >>> I tested this before, but we'll have to do some other changes to make >>> it happen 'for real' this time (including some CDN fiddling). Ben also >>> recently rewrote the terrible build script I originally wrote, so I'd >>> like to deploy it instead if possible. Thomas has also rightfully >>> prodded me about some of the current CI complaints, so hopefully these >>> can be sorted out too. >>> >>> This upgrade has been long in the tooth, but luckily you shouldn't >>> notice much beyond a minor hitch here, and CI being gone for a little >>> while. Hopefully it should be done by the end of the day. >>> >>> In the mean time, I'll give Ben access to the newer (20 core) >>> buildbot, so he'll be able to validate your changes quite quickly for >>> integration. >>> >>> I'll reply to this email with updates. >>> >>> -- >>> Regards, >>> >>> Austin Seipp, Haskell Consultant >>> Well-Typed LLP, http://www.well-typed.com/ >> >> >> >> -- >> Regards, >> >> Austin Seipp, Haskell Consultant >> Well-Typed LLP, http://www.well-typed.com/ > > > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From simonpj at microsoft.com Thu Jan 21 16:44:34 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 21 Jan 2016 16:44:34 +0000 Subject: CallStack naming In-Reply-To: <1453392883.2128646.498701002.6ACCB74F@webmail.messagingengine.com> References: <96F502AD-4AC6-40FA-BD9C-C9C063C2DDE0@cis.upenn.edu> <659dc968669143e0972602a72fb7753e@DB4PR30MB030.064d.mgd.msft.net> <1453305947.1797061.497600914.32732A90@webmail.messagingengine.com> <13f3ddc1d01a4f46ac15a051cc8ff049@DB4PR30MB030.064d.mgd.msft.net> <1453310647.1815559.497698170.68A46486@webmail.messagingengine.com> <1453367951.23159.6.camel@joachim-breitner.de> <1453392883.2128646.498701002.6ACCB74F@webmail.messagingengine.com> Message-ID: <4e65052c4ef640f8b627b881fdcd2886@DB4PR30MB030.064d.mgd.msft.net> | In that case we'll probably want to move the CallStack section of the | user guide elsewhere, right now it's a subsection of ImplicitParams. Yes! | True, so perhaps a single mention of the implicit parameter, | explaining that it's not part of the API and that using it is | *explicitly unsupported*, i.e. we may change the implementation later. Yes! | - WithCallStack | - HasCallStack | - GetsCallStack I vote for HasCallStack. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Eric | Seidel | Sent: 21 January 2016 16:15 | To: ghc-devs at haskell.org | Subject: Re: CallStack naming | | On Thu, Jan 21, 2016, at 04:07, Simon Peyton Jones wrote: | > Well, in the short term, let's | > * bikeshed about names | | Ok, I don't like ICallStack :) It sounds like a C# interface, which, | while technically sort of accurate, is very misleading since users | will never write an instance. I'd prefer something a bit more | descriptive, like | | - WithCallStack | - HasCallStack | - GetsCallStack | | (in no particular order) | | > * write down the user-visible API, ensuring that it makes | > no mention of implicit parameters (provide setCallStack) | > | > Then we can implement the API differently later if we so desire. | | In that case we'll probably want to move the CallStack section of the | user guide elsewhere, right now it's a subsection of ImplicitParams. | | > The main disadvantage is that the abstraction is leaky. We can't | > *prevent* users from seeing and using the implicit parameter. | | True, so perhaps a single mention of the implicit parameter, | explaining that it's not part of the API and that using it is | *explicitly unsupported*, i.e. we may change the implementation later. | | > Does that sound like a plan. Might you do it Eric? The urgency is | > just to get 8.0 out with an API that we like | | Sure, I'll try to have a patch out later today. | _______________________________________________ | 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%7c520a5cb5bf08467 | e9bd908d3227dfb21%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Bv%2fkj | FszUZpmWXmU0AcnrumJU9XfUU5v%2fdMCKUP4dGY%3d From ben at well-typed.com Fri Jan 22 13:05:43 2016 From: ben at well-typed.com (Ben Gamari) Date: Fri, 22 Jan 2016 14:05:43 +0100 Subject: vectorisation code? In-Reply-To: References: <0CC751A6-A9A9-47AA-961E-A997F39844A2@cis.upenn.edu> <618BE556AADD624C9C918AA5D5911BEF562AAB21@DB3PRD3001MB020.064d.mgd.msft.net> <201501200937.25031.jan.stolarek@p.lodz.pl> <8761c1ltym.fsf@gmail.com> <618BE556AADD624C9C918AA5D5911BEF562AE247@DB3PRD3001MB020.064d.mgd.msft.net> <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> Message-ID: <87io2lg3x4.fsf@smart-cactus.org> Manuel M T Chakravarty writes: > The way I see it, the main cost of keeping DPH around is to handle > breakages such as that with vector. I can?t promise to address those > in a timely manner, which is why I agreed to disable/remove DPH. > > However, as Geoff stepped forward, this issue is solved. As for the > overhead in compile time etc, I don?t think, it is that much of a > deal. During development, most compiles runs are incremental anyway. > Judging by the VCS history it seems that nothing happened in response to this thread. Geoff, do you see yourself having time to pick this up in the near future? If not, perhaps we should pick up this matter again and seriously consider parking this code in a branch until someone is able to pick it up 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: From mainland at apeiron.net Fri Jan 22 14:17:03 2016 From: mainland at apeiron.net (Geoffrey Mainland) Date: Fri, 22 Jan 2016 09:17:03 -0500 Subject: vectorisation code? In-Reply-To: <87io2lg3x4.fsf@smart-cactus.org> References: <0CC751A6-A9A9-47AA-961E-A997F39844A2@cis.upenn.edu> <618BE556AADD624C9C918AA5D5911BEF562AAB21@DB3PRD3001MB020.064d.mgd.msft.net> <201501200937.25031.jan.stolarek@p.lodz.pl> <8761c1ltym.fsf@gmail.com> <618BE556AADD624C9C918AA5D5911BEF562AE247@DB3PRD3001MB020.064d.mgd.msft.net> <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> <87io2lg3x4.fsf@smart-cactus.org> Message-ID: <56A239DF.4070006@apeiron.net> On 1/22/16 8:05 AM, Ben Gamari wrote: > Manuel M T Chakravarty writes: > >> The way I see it, the main cost of keeping DPH around is to handle >> breakages such as that with vector. I can?t promise to address those >> in a timely manner, which is why I agreed to disable/remove DPH. >> >> However, as Geoff stepped forward, this issue is solved. As for the >> overhead in compile time etc, I don?t think, it is that much of a >> deal. During development, most compiles runs are incremental anyway. >> > Judging by the VCS history it seems that nothing happened in response to > this thread. Geoff, do you see yourself having time to pick this up in > the near future? > > If not, perhaps we should pick up this matter again and seriously > consider parking this code in a branch until someone is able to pick it > up again. > > Cheers, > > - Ben Yes, I am willing to do the work to get DPH back into the build in the near future. However, that only makes sense if we are willing to build DPH regularly. Also, I can't be solely responsible for all breakage resulting from DPH; DPH has regularly exposed bugs in the past, which is one reason to get it back into the regular build, but I can't promise to fix all problems that might be exposed by DPH in the future :) If I put a patch on Phab that updates DPH, are we willing to make DPH part of the regular validation script again? Cheers, Geoff From thomasmiedema at gmail.com Fri Jan 22 14:23:56 2016 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Fri, 22 Jan 2016 15:23:56 +0100 Subject: vectorisation code? In-Reply-To: <56A239DF.4070006@apeiron.net> References: <0CC751A6-A9A9-47AA-961E-A997F39844A2@cis.upenn.edu> <618BE556AADD624C9C918AA5D5911BEF562AAB21@DB3PRD3001MB020.064d.mgd.msft.net> <201501200937.25031.jan.stolarek@p.lodz.pl> <8761c1ltym.fsf@gmail.com> <618BE556AADD624C9C918AA5D5911BEF562AE247@DB3PRD3001MB020.064d.mgd.msft.net> <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> <87io2lg3x4.fsf@smart-cactus.org> <56A239DF.4070006@apeiron.net> Message-ID: We could make all of hackage be part of the ghc build, and it would turn up bugs. But we don't do that either. Why is dph special? On Fri, Jan 22, 2016 at 3:17 PM, Geoffrey Mainland wrote: > On 1/22/16 8:05 AM, Ben Gamari wrote: > > Manuel M T Chakravarty writes: > >> The way I > see it, the main cost of keeping DPH around is to handle > >> breakages such as that with vector. I can?t promise to address those > >> in a timely manner, which is why I agreed to disable/remove DPH. >> > >> However, as Geoff stepped forward, this issue is solved. As for the > >> overhead in compile time etc, I don?t think, it is that much of a >> > deal. During development, most compiles runs are incremental anyway. >> > > Judging by the VCS history it seems that nothing happened in response > to > this thread. Geoff, do you see yourself having time to pick this up > in > the near future? > > If not, perhaps we should pick up this matter > again and seriously > consider parking this code in a branch until > someone is able to pick it > up again. > > Cheers, > > - Ben > > Yes, I am willing to do the work to get DPH back into the build in the > near future. However, that only makes sense if we are willing to build > DPH regularly. Also, I can't be solely responsible for all breakage > resulting from DPH; DPH has regularly exposed bugs in the past, which is > one reason to get it back into the regular build, but I can't promise to > fix all problems that might be exposed by DPH in the future :) > > If I put a patch on Phab that updates DPH, are we willing to make DPH > part of the regular validation script again? > > Cheers, > Geoff > > _______________________________________________ > 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: From andrey.mokhov at newcastle.ac.uk Fri Jan 22 14:27:24 2016 From: andrey.mokhov at newcastle.ac.uk (Andrey Mokhov) Date: Fri, 22 Jan 2016 14:27:24 +0000 Subject: [ANNOUNCE] Shaking up GHC Message-ID: Dear GHC developers, I am happy to announce that the Shaking up GHC project has finally reached the first milestone. The goal of the project is to design a new GHC build system based on Shake that will eventually replace the current make-based one. See the project page for more details: https://github.com/snowleopard/shaking-up-ghc. There is still a long way until we can match the capabilities of the current build system. At the moment we only build vanilla way. Validation, documentation, build flavours and cross-compilation are not yet implemented. Known limitations are listed here: https://github.com/snowleopard/shaking-up-ghc#current-limitations. The purpose of this announcement is to attract alpha testers and collect early feedback across multiple platforms and build configurations. We already have several success reports on Linux, OS X, Solaris and Windows. However, things will inevitably break and we hope to catch and fix as many of these cases as possible with your help. The instructions on how to try the new build system can be found here: https://github.com/snowleopard/shaking-up-ghc#your-first-build. We plan to be ready to become a part of the GHC tree around 1 March 2016, and catch up with the make build system around 1 June 2016. The dates are tentative and depend on how much time it takes us to resolve the remaining issues: https://github.com/snowleopard/shaking-up-ghc/milestones. I would like thank everyone who contributed to this project so far: Simon Peyton Jones, Neil Mitchell and Simon Marlow came up with the idea and guided me throughout the project; Moritz Angermann, Ben Gamari, Karel Gardas, David Luposchainsky, and Neil Mitchell contributed to the codebase. Thank you all! Kind regards, Andrey From mainland at apeiron.net Fri Jan 22 14:57:59 2016 From: mainland at apeiron.net (Geoffrey Mainland) Date: Fri, 22 Jan 2016 06:57:59 -0800 Subject: vectorisation code? In-Reply-To: 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> <87io2lg3x4.fsf@smart-cactus.org> <56A239DF.4070006@apeiron.net> Message-ID: <20160122145759.GA7974@apeiron.net> On Fri, Jan 22, 2016 at 03:23:56PM +0100, Thomas Miedema wrote: > On Fri, Jan 22, 2016 at 3:17 PM, Geoffrey Mainland wrote: >> On 1/22/16 8:05 AM, Ben Gamari wrote: >>> Manuel M T Chakravarty writes: >>>> The way I see it, the main cost of keeping DPH around is to handle >>>> breakages such as that with vector. I can't promise to address those >>>> in a timely manner, which is why I agreed to disable/remove DPH. >>>> However, as Geoff stepped forward, this issue is solved. As for the >>>> overhead in compile time etc, I don't think, it is that much of a >>>> deal. During development, most compiles runs are incremental anyway. >>> >>> Judging by the VCS history it seems that nothing happened in response to >>> this thread. Geoff, do you see yourself having time to pick this up in >>> the near future? If not, perhaps we should pick up this matter again and seriously >>> consider parking this code in a branch until someone is able to pick it >>> up again. >>> Cheers, >>> - Ben >> >> Yes, I am willing to do the work to get DPH back into the build in the >> near future. However, that only makes sense if we are willing to build >> DPH regularly. Also, I can't be solely responsible for all breakage >> resulting from DPH; DPH has regularly exposed bugs in the past, which is >> one reason to get it back into the regular build, but I can't promise to >> fix all problems that might be exposed by DPH in the future :) >> >> If I put a patch on Phab that updates DPH, are we willing to make DPH >> part of the regular validation script again? >> >> Cheers, >> Geoff > > We could make all of hackage be part of the ghc build, and it would turn > up bugs. But we don't do that either. Why is dph special? Manuel and Simon can say more, but DPH has in the past been very good at exposing, for example, regressions in the inliner. It exercises GHC in a way that few other packages do. DPH is intimately tied to GHC, so it's not something that can be maintained separately as a package. If we aren't willing to make DPH part of the regular build, then it will just bitrot again quickly, and there's little point in doing the work to get it running again. I'm of the opinion that DPH still has value and that it would be a shame to lose it forever, which is effectively what will happen if we relegate the vectorizer to a branch. I am willing to get DPH working again, but only if there is general agreement that DPH is worth having---and that we are willing to once again make it part of the regular build. Geoff From ben at smart-cactus.org Fri Jan 22 15:12:39 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Fri, 22 Jan 2016 16:12:39 +0100 Subject: vectorisation code? In-Reply-To: <54C11F26.9080201@apeiron.net> References: <0CC751A6-A9A9-47AA-961E-A997F39844A2@cis.upenn.edu> <618BE556AADD624C9C918AA5D5911BEF562AAB21@DB3PRD3001MB020.064d.mgd.msft.net> <201501200937.25031.jan.stolarek@p.lodz.pl> <8761c1ltym.fsf@gmail.com> <618BE556AADD624C9C918AA5D5911BEF562AE247@DB3PRD3001MB020.064d.mgd.msft.net> <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> Message-ID: <87bn8dfy1k.fsf@smart-cactus.org> Geoffrey Mainland writes: > That's part of "minimal maintenance mode." Yes, keeping DPH will impose > some burden. I am not pretending that keeping DPH imposes no cost, but > instead asking what cost we are willing to pay to keep DPH > working---maybe the answer is "none." > I would imagine that cost is greater than "none". Unfortunately, it is is very difficult to judge as it depends upon something none of us can know: what the future holds in store for DPH. Naturally, this is subject to the whims of funding and students' interests, but it would be good to know where the DPH project currently stands and what future plans for it, if any, exist. Is there potential for someone to come along in, say, the next three years, pick up the existing implementation, and begin turning it into something that might become useful to a larger audience? I stress the phrase "existing implementation" since we need to weigh the fact that, as has been mentioned in past discussions [1], the current implementation embodies some design decisions which will likely need to be changed, perhaps requiring a rewrite. If a rewrite is very likely it becomes harder for us to ask developers to invest the effort to keep this code building. I also stress the phrase "begin turning", acknowledging that this is a research project, that students and funding come and go, and the problem that the project attacks is a challenging one. I appreciate the fact that DPH may serve as a good smoke-test for GHC and it would be a shame to see this work rot into oblivion; as a Haskell user I am intrigued by the potential held by DPH. Nevertheless, it would be nice to have an estimate of the probability that the effort we put in maintaining DPH might some day be rewarded. Cheers, - Ben [1] http://thread.gmane.org/gmane.comp.lang.haskell.ghc.devel/5645/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From ben at smart-cactus.org Fri Jan 22 15:23:27 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Fri, 22 Jan 2016 16:23:27 +0100 Subject: [ANNOUNCE] Shaking up GHC In-Reply-To: References: Message-ID: <878u3hfxjk.fsf@smart-cactus.org> Andrey Mokhov writes: > Dear GHC developers, > > I am happy to announce that the Shaking up GHC project has finally > reached the first milestone. The goal of the project is to design a > new GHC build system based on Shake that will eventually replace the > current make-based one. See the project page for more details: > https://github.com/snowleopard/shaking-up-ghc. > Congratulations, Andrey! I'm looking forward to seeing how this project progresses. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From simonpj at microsoft.com Fri Jan 22 16:13:15 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 22 Jan 2016 16:13:15 +0000 Subject: vectorisation code? In-Reply-To: <20160122145759.GA7974@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> <87io2lg3x4.fsf@smart-cactus.org> <56A239DF.4070006@apeiron.net> <20160122145759.GA7974@apeiron.net> Message-ID: <3541c1a536d24f5794e432150833b428@DB4PR30MB030.064d.mgd.msft.net> Making it part of *every* validate is a big ask because it takes so long to build. But we already have "sh validate --slow", which runs a lot more tests than --fast. So maybe it could be part of --slow? And I do think that we should have a nightly build (although perhaps not the continuous-integration build-every-commit stuff) that runs the full testsuite. I don't think that happens right now. But it should. That might resolve the "painful to add DPH to validate" problem. Simon | -----Original Message----- | From: Geoffrey Mainland [mailto:mainland at apeiron.net] | Sent: 22 January 2016 14:58 | To: Thomas Miedema | Cc: Ben Gamari ; Manuel M T Chakravarty | ; Simon Peyton Jones ; | ghc-devs at haskell.org | Subject: Re: vectorisation code? | | On Fri, Jan 22, 2016 at 03:23:56PM +0100, Thomas Miedema wrote: | > On Fri, Jan 22, 2016 at 3:17 PM, Geoffrey Mainland | wrote: | >> On 1/22/16 8:05 AM, Ben Gamari wrote: | >>> Manuel M T Chakravarty writes: | >>>> The way I see it, the main cost of keeping DPH around is to | handle | >>>> breakages such as that with vector. I can't promise to address | >>>> those in a timely manner, which is why I agreed to disable/remove | DPH. | >>>> However, as Geoff stepped forward, this issue is solved. As for | the | >>>> overhead in compile time etc, I don't think, it is that much of a | >>>> deal. During development, most compiles runs are incremental | anyway. | >>> | >>> Judging by the VCS history it seems that nothing happened in | >>> response to this thread. Geoff, do you see yourself having time to | >>> pick this up in the near future? If not, perhaps we should pick up | >>> this matter again and seriously consider parking this code in a | >>> branch until someone is able to pick it up again. | >>> Cheers, | >>> - Ben | >> | >> Yes, I am willing to do the work to get DPH back into the build in | >> the near future. However, that only makes sense if we are willing | to | >> build DPH regularly. Also, I can't be solely responsible for all | >> breakage resulting from DPH; DPH has regularly exposed bugs in the | >> past, which is one reason to get it back into the regular build, | but | >> I can't promise to fix all problems that might be exposed by DPH in | >> the future :) | >> | >> If I put a patch on Phab that updates DPH, are we willing to make | DPH | >> part of the regular validation script again? | >> | >> Cheers, | >> Geoff | > | > We could make all of hackage be part of the ghc build, and it would | > turn up bugs. But we don't do that either. Why is dph special? | | Manuel and Simon can say more, but DPH has in the past been very good | at exposing, for example, regressions in the inliner. It exercises GHC | in a way that few other packages do. | | DPH is intimately tied to GHC, so it's not something that can be | maintained separately as a package. If we aren't willing to make DPH | part of the regular build, then it will just bitrot again quickly, and | there's little point in doing the work to get it running again. | | I'm of the opinion that DPH still has value and that it would be a | shame to lose it forever, which is effectively what will happen if we | relegate the vectorizer to a branch. I am willing to get DPH working | again, but only if there is general agreement that DPH is worth | having---and that we are willing to once again make it part of the | regular build. | | Geoff From mainland at apeiron.net Fri Jan 22 16:23:18 2016 From: mainland at apeiron.net (Geoffrey Mainland) Date: Fri, 22 Jan 2016 11:23:18 -0500 Subject: vectorisation code? In-Reply-To: <3541c1a536d24f5794e432150833b428@DB4PR30MB030.064d.mgd.msft.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> <87io2lg3x4.fsf@smart-cactus.org> <56A239DF.4070006@apeiron.net> <20160122145759.GA7974@apeiron.net> <3541c1a536d24f5794e432150833b428@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <56A25776.20403@apeiron.net> I didn't mean to suggest that DPH should be part of every build, just that it should be part of *some* regular build. If we're willing to do that, then I'm certainly willing to get DPH back up and running. Geoff On 01/22/2016 11:13 AM, Simon Peyton Jones wrote: > Making it part of *every* validate is a big ask because it takes so long to build. > > But we already have "sh validate --slow", which runs a lot more tests than --fast. So maybe it could be part of --slow? > > And I do think that we should have a nightly build (although perhaps not the continuous-integration build-every-commit stuff) that runs the full testsuite. I don't think that happens right now. But it should. > > That might resolve the "painful to add DPH to validate" problem. > > Simon > > | -----Original Message----- > | From: Geoffrey Mainland [mailto:mainland at apeiron.net] > | Sent: 22 January 2016 14:58 > | To: Thomas Miedema > | Cc: Ben Gamari ; Manuel M T Chakravarty > | ; Simon Peyton Jones ; > | ghc-devs at haskell.org > | Subject: Re: vectorisation code? > | > | On Fri, Jan 22, 2016 at 03:23:56PM +0100, Thomas Miedema wrote: > | > On Fri, Jan 22, 2016 at 3:17 PM, Geoffrey Mainland > | wrote: > | >> On 1/22/16 8:05 AM, Ben Gamari wrote: > | >>> Manuel M T Chakravarty writes: > | >>>> The way I see it, the main cost of keeping DPH around is to > | handle > | >>>> breakages such as that with vector. I can't promise to address > | >>>> those in a timely manner, which is why I agreed to disable/remove > | DPH. > | >>>> However, as Geoff stepped forward, this issue is solved. As for > | the > | >>>> overhead in compile time etc, I don't think, it is that much of a > | >>>> deal. During development, most compiles runs are incremental > | anyway. > | >>> > | >>> Judging by the VCS history it seems that nothing happened in > | >>> response to this thread. Geoff, do you see yourself having time to > | >>> pick this up in the near future? If not, perhaps we should pick up > | >>> this matter again and seriously consider parking this code in a > | >>> branch until someone is able to pick it up again. > | >>> Cheers, > | >>> - Ben > | >> > | >> Yes, I am willing to do the work to get DPH back into the build in > | >> the near future. However, that only makes sense if we are willing > | to > | >> build DPH regularly. Also, I can't be solely responsible for all > | >> breakage resulting from DPH; DPH has regularly exposed bugs in the > | >> past, which is one reason to get it back into the regular build, > | but > | >> I can't promise to fix all problems that might be exposed by DPH in > | >> the future :) > | >> > | >> If I put a patch on Phab that updates DPH, are we willing to make > | DPH > | >> part of the regular validation script again? > | >> > | >> Cheers, > | >> Geoff > | > > | > We could make all of hackage be part of the ghc build, and it would > | > turn up bugs. But we don't do that either. Why is dph special? > | > | Manuel and Simon can say more, but DPH has in the past been very good > | at exposing, for example, regressions in the inliner. It exercises GHC > | in a way that few other packages do. > | > | DPH is intimately tied to GHC, so it's not something that can be > | maintained separately as a package. If we aren't willing to make DPH > | part of the regular build, then it will just bitrot again quickly, and > | there's little point in doing the work to get it running again. > | > | I'm of the opinion that DPH still has value and that it would be a > | shame to lose it forever, which is effectively what will happen if we > | relegate the vectorizer to a branch. I am willing to get DPH working > | again, but only if there is general agreement that DPH is worth > | having---and that we are willing to once again make it part of the > | regular build. > | > | Geoff > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From hvriedel at gmail.com Fri Jan 22 16:36:18 2016 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Fri, 22 Jan 2016 17:36:18 +0100 Subject: vectorisation code? In-Reply-To: <56A25776.20403@apeiron.net> (Geoffrey Mainland's message of "Fri, 22 Jan 2016 11:23:18 -0500") 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> <87io2lg3x4.fsf@smart-cactus.org> <56A239DF.4070006@apeiron.net> <20160122145759.GA7974@apeiron.net> <3541c1a536d24f5794e432150833b428@DB4PR30MB030.064d.mgd.msft.net> <56A25776.20403@apeiron.net> Message-ID: <87wpr1k1vh.fsf@gmail.com> On 2016-01-22 at 17:23:18 +0100, Geoffrey Mainland wrote: > I didn't mean to suggest that DPH should be part of every build, just > that it should be part of *some* regular build. > > If we're willing to do that, then I'm certainly willing to get DPH > back up and running. What's the situation with the `vector`/`primitive` packages if DPH is to be resuscitated? Does the official `vector` package need to be made DPH-aware? From mainland at apeiron.net Fri Jan 22 16:39:25 2016 From: mainland at apeiron.net (Geoffrey Mainland) Date: Fri, 22 Jan 2016 11:39:25 -0500 Subject: vectorisation code? In-Reply-To: <87wpr1k1vh.fsf@gmail.com> 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> <87io2lg3x4.fsf@smart-cactus.org> <56A239DF.4070006@apeiron.net> <20160122145759.GA7974@apeiron.net> <3541c1a536d24f5794e432150833b428@DB4PR30MB030.064d.mgd.msft.net> <56A25776.20403@apeiron.net> <87wpr1k1vh.fsf@gmail.com> Message-ID: <56A25B3D.1050809@apeiron.net> On 1/22/16 11:36 AM, Herbert Valerio Riedel wrote: > On 2016-01-22 at 17:23:18 +0100, Geoffrey Mainland wrote: >> I didn't mean to suggest that DPH should be part of every build, just >> that it should be part of *some* regular build. >> >> If we're willing to do that, then I'm certainly willing to get DPH >> back up and running. > What's the situation with the `vector`/`primitive` packages if DPH is to > be resuscitated? Does the official `vector` package need to be made > DPH-aware? > The vector and primitive packages will not need to be changed in any significant way, and perhaps not at all. It's possible we might need a few patches to vector to, e.g., expose a data constructor somewhere, so I can't promise that we will need zero changes. Geoff From dluposchainsky at googlemail.com Fri Jan 22 19:10:41 2016 From: dluposchainsky at googlemail.com (David Luposchainsky) Date: Fri, 22 Jan 2016 20:10:41 +0100 Subject: [ANNOUNCE] Shaking up GHC In-Reply-To: References: Message-ID: <56A27EB1.1080701@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Great work Andrey! I'm actually (pleasantly) surprised this is becoming part of the GHC tree so soon . Are there any plans as to how to include it in the GHC tree? Does it ship with all the libraries required to build the build system, will we have a mini-build system to bootstrap it? If I recall correctly, we rely on Cabal sandboxes on Linux/OSX and global Cabal library installations on Windows in order to run it. Greetings, David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJWon6xAAoJELrQsaT5WQUs/WUIAL8K6+pQh/hWqJCIDb1SG6+r 2wGkAd9CpihFX10farMUo4irakiRkwqQdw2r82LAHluaXIqiM8cr6k2kKJh/hOEl 2ct475akN3p7KlNlV4b74xSXPK6WmU0gabR7lkQm1FGQQbB1Gl9ztKpaL+x4vygj ZbQS76h6K+xMy+oLBXgC2bHALYb4fK/1u9JDuAFuJeGqhwy6xcdgr0QOMLY8x3P0 JGeiKT0nsJ8359nj28/BPPJz3yjNdHqcMU3F8lCY96N+r8K+gwo8VTLhji/3MIMT 7amh2D8bpfbK7Ckv9B5tD4OsYVRDgy9iRF54sSu1Qce1YhsPFnRoD4b2teV3UHs= =zLQ3 -----END PGP SIGNATURE----- From asr at eafit.edu.co Sat Jan 23 03:24:59 2016 From: asr at eafit.edu.co (=?UTF-8?B?QW5kcsOpcyBTaWNhcmQtUmFtw61yZXo=?=) Date: Fri, 22 Jan 2016 22:24:59 -0500 Subject: Options -Wmissed-specialisations, -Wall-missed-specialisations and -Werror Message-ID: Dear all, In GHC 8 RC 1, the `-Wmissed-specialisations` and `-Wall-missed-specialisations` options generate a warning instead of an error when using `-Werror`. Is it the expected behaviour? Best, -- Andr?s From john_ericson at brown.edu Sat Jan 23 06:40:47 2016 From: john_ericson at brown.edu (Ericson, John) Date: Fri, 22 Jan 2016 22:40:47 -0800 Subject: Host-Oriented Template Haskell In-Reply-To: <1453360828-sup-6927@sabre> References: <87si1t2pts.fsf@gnu.org> <1453245573-sup-5512@sabre> <1453350334-sup-7919@sabre> <1453357380-sup-6390@sabre> <1453360828-sup-6927@sabre> Message-ID: Thanks for filing the issue Edward! Moritz I hope you are right. I suspect most of the autoconf stuff relating to this exists because GCC and binutils are single-target by default, whereas LLVM is (always?) multi-target. Even the other targets may also benefit if LLD can be used instead of binutils--LLD was WIP last I checked, but I assume like the rest of LLVM it plans to be multi-target. Insofar as configuration and the build system might be the biggest headache in bringing this about, I hope the shaking-up-ghc work will be very useful. John On Wed, Jan 20, 2016 at 11:20 PM, Edward Z. Yang wrote: > I've filed a Trac ticket for this: https://ghc.haskell.org/trac/ghc/ticket/11470#ticket > > Edward > > Excerpts from Moritz Angermann's message of 2016-01-20 22:55:36 -0800: >> Colour me an interested party! For iOS one currently builds two >> different ghc compiler. One for the simulator (i386) and one for the >> actual device (arm). My initial work on bringing ghcjs?s TH support, >> (which basically ships the TH out to a process on the target to compile >> and brings back the compiled TH into the cross compiler) to ghc, was >> based on the idea of having a TH handler plugin, which would handle the >> TH parts, and could then be adapted for different TH situations. This >> of course could only work if the plugin was compiled with the same version >> of ghc, that the cross compiler was. >> >> I wonder if the multi-target pipeline might be simpler to achieve with >> the llvm backend. >> >> If someone is taking a shot at this, I?d like to help! >> >> Cheers, >> Moritz >> >> > On Jan 21, 2016, at 2:44 PM, Edward Z. Yang wrote: >> > >> > Yes, in principle, a compiler that supports cross-compiling to many >> > targets without needing to be configured (at build time) which >> > target it should support is ideal. Unfortunately, currently GHC >> > relies on autoconf to determine all of the necessary parameters >> > for a cross-compile. I am not sure how feasible it would be to >> > allow these parameters to be configured at runtime: it might be >> > easy, it might be hard! (And of course you have to arrange >> > to have cross-compiled all the boot libraries too...) >> > >> > In any case, I think that a GHC that permits changing cross-compilation >> > targets at runtime is a fine goal, and if it is supported, then we >> > would only have to make adjustments to GHC internally to distinguish >> > between the interfaces/objects for various targets (including itself.) >> > >> > Edward >> > >> > Excerpts from Ericson, John's message of 2016-01-20 21:23:28 -0800: >> >> Oops, Sent just to Edward by mistake. >> >> >> >> ---- >> >> >> >> That all sounds good to me---I think what I was thinking all along in >> >> fact, unless I am still missing some nuance :). >> >> >> >> My idea of using a multi-target compiler was to avoid needing stage0 >> >> to be the same version as stage1 (or adding a new stage, stage1 as in >> >> your alternative). The cross compiler is multi-target so it doesn't >> >> need to link another compiler to load plugins / run "host-oriented >> >> Template Haskell". I mentioned the usecase of trying to build a stage2 >> >> which needs plugins / Host-Oriented Template Haskell, but it could >> >> well apply to building anything else with the need for those to things >> >> (and not normal TH, which cannot be built with a cross compiler) >> >> >> >> In diagrams, rather than: >> >> >> >>> stage0 (version foo, platform-x -> platform-x) >> >>> ==> stage1 (version foo, platform-x -> platform-y) >> >>> ==> some program (with plugins, with host-oriented TH, without normal TH) >> >> >> >> or >> >> >> >>> stage0 (version bar, platform-x -> platform-x) >> >>> ==> stage1 (version foo, platform-x -> platform-x) -> >> >>> ==> stage2 (version foo, platform-x -> platform-y) -> >> >>> ==> some program (with plugins, with host-oriented TH, without normal TH) >> >> >> >> do just >> >> >> >>> stage0 (version bar, platform-x -> platform-x) >> >>> ==> stage1 (version foo, platform-x -> {platform-x, platform-y}) >> >>> ==> some program (with plugins, with host-oriented TH, without normal TH) >> >> >> >> Now it may be that building such a multi-target compiler today is just >> >> as arduous as making sure one has a native compiler of the same >> >> version before building the cross compiler, so my idea is of no >> >> practical value. But if so, I hope in the long term that could be >> >> fixed. >> >> >> >> John >> >> >> >> On Wed, Jan 20, 2016 at 8:37 PM, Edward Z. Yang wrote: >> >>> Hello John, >> >>> >> >>> Almost! >> >>> >> >>> As you point out, if you just want a cross-compiler, you don't >> >>> need to build stage2. The real problem is that we want stage0 >> >>> to be *the same version* as stage1, so that stage0 has the correct >> >>> API in order to load stage0 libraries which are going to be used >> >>> for TH, plugins, etc. (Alternately, build a non-cross-compiler >> >>> stage1, and then a cross-compiler stage2--NOT a cross compiled >> >>> stage 2.) >> >>> >> >>> Edward >> >>> >> >>> Excerpts from Ericson, John's message of 2016-01-19 16:13:24 -0800: >> >>>> From #11378: >> >>>> >> >>>>> Can we actually link against the old version of ghc? Yes we can! All we need is >> >>>>> (1) for it to have been built with a different IPID, and >> >>>>> (2) to use module renaming to rename the relevant modules to a different >> >>>>> module name, so that we can import them without a conflict. >> >>>> >> >>>> >> >>>> If I understand this, you are saying stage1 links stage0 (the normal, >> >>>> non-cross-compiler used to build stage1), to build stage2? I agree >> >>>> that should work, but if stage1 is multi-target isn't that level of >> >>>> complexity not even needed? I'm not too familiar with GHC or its build >> >>>> system, but a multi-target compiler that doesn't support normal TH >> >>>> doesn't seem that hard to build in principle. >> >>>> >> >>>> John >> >>>> >> >>>> On Tue, Jan 19, 2016 at 3:59 PM, Ericson, John wrote: >> >>>>> Ah thanks for the link. Template Haskell with only {-# TH-ONLY #-} >> >>>>> imports is precisely equivalent to what I propose. I find a clean >> >>>>> separation with that and normal TH useful, however, precisely so the >> >>>>> stage2 compiler's source can include such a thing. >> >>>>> >> >>>>> On Tue, Jan 19, 2016 at 3:20 PM, Edward Z. Yang wrote: >> >>>>>> Hello John >> >>>>>> >> >>>>>> You may find this implementation ticket of interest: >> >>>>>> https://ghc.haskell.org/trac/ghc/ticket/11378 >> >>>>>> >> >>>>>> Edward >> >>>>>> >> >>>>>> Excerpts from Ericson, John's message of 2016-01-19 15:15:15 -0800: >> >>>>>>> Cross-posting this as was suggested on the Haskell-Cafe list. While I >> >>>>>>> envision this as normal feature that anyone can use, in practice its >> >>>>>>> biggest consumers would be GHC devs. >> >>>>>>> >> >>>>>>> John >> >>>>>>> >> >>>>>>> ---------- Forwarded message ---------- >> >>>>>>> From: Ericson, John >> >>>>>>> Date: Tue, Jan 19, 2016 at 1:17 PM >> >>>>>>> Subject: Host-Oriented Template Haskell >> >>>>>>> To: Haskell-Cafe >> >>>>>>> >> >>>>>>> >> >>>>>>> As is well known, TH and cross-compiling do not get along. There are >> >>>>>>> various proposals on how to make this interaction less annoying, and I >> >>>>>>> am not against them. But as I see it, the problem is largely inherent >> >>>>>>> to the design of TH itself: since values can (usually) be lifted from >> >>>>>>> compile-time to run-time, and normal definitions from upstream modules >> >>>>>>> to downstream modules' TH, TH and normal code must "live in the same >> >>>>>>> world". >> >>>>>>> >> >>>>>>> Now this restriction in turn bequeaths TH with much expressive power, >> >>>>>>> and I wouldn't advocate getting rid of it. But many tasks do not need >> >>>>>>> it, and in some cases, say in bootstrapping compilers[1] themselves, >> >>>>>>> it is impossible to use TH because of it, even were all the current >> >>>>>>> proposals implemented. >> >>>>>>> >> >>>>>>> For these reason, I propose a new TH variant which has much harsher >> >>>>>>> phase separation. Normal definitions from upstream modules can not be >> >>>>>>> used, lifting values is either not permitted or is allowed to fail >> >>>>>>> (because of missing/incompatible definitions), and IO is defined to >> >>>>>>> match the behavior of the host, not target, platform (in the cross >> >>>>>>> compiling case). The only interaction between the two phases is that >> >>>>>>> quoted syntax is resolved against the the run-time phase's definitions >> >>>>>>> (just like today). >> >>>>>>> >> >>>>>>> Some of you may find this a shoddy substitute for defining a subset of >> >>>>>>> Haskell which behaves identically on all platforms, and optionally >> >>>>>>> constraining TH to it. But the big feature that my proposal offers and >> >>>>>>> that one doesn't is to be able to independently specify compile-time >> >>>>>>> dependencies for the host-oriented TH---this is analogous to the >> >>>>>>> newish `Setup.hs` dependencies. That in turns leads to what I think is >> >>>>>>> the "killer app" for Host-Oriented TH: exposing the various >> >>>>>>> prepossessors we use (alex, happy, hsc2hs, even CPP) into libraries, >> >>>>>>> and side-stepping any need for "executable dependencies" in Cabal. >> >>>>>>> Note also that at least hsc2hs additionally requires host-IO---there >> >>>>>>> may not even exist a C compiler on the target platform at all. >> >>>>>>> >> >>>>>>> Finally, forgive me if this has been brought up before. I've been >> >>>>>>> thinking about this a while, and did a final pass over the GHC wiki to >> >>>>>>> make sure it wasn't already proposed, but I could have missed >> >>>>>>> something (this is also my first post to the list). >> >>>>>>> >> >>>>>>> John >> >>>>>>> >> >>>>>>> [1]: https://github.com/ghcjs/ghcjs/blob/master/lib/ghcjs-prim/GHCJS/Prim/Internal/Build.hs >> >>>>>> _______________________________________________ >> >>>>>> 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 >> >> ????????????????? >> Moritz Angermann >> +49 170 54 33 0 74 >> moritz at lichtzwerge.de >> >> lichtzwerge GmbH >> Raiffeisenstr. 8 >> 93185 Michelsneukirchen >> >> Amtsgericht Regensburg HRB 14723 >> Gesch?ftsf?hrung: Moritz Angermann, Ralf Sangl >> USt-Id: DE291948767 >> >> Diese E-Mail enth?lt vertrauliche und/oder rechtlich gesch?tzte >> Informationen. Wenn Sie nicht der richtige Adressat sind oder diese >> E-Mail irrt?mlich erhalten haben, informieren Sie bitte sofort den >> Absender und vernichten Sie diese Mail. >> Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail >> ist nicht gestattet. >> This e-mail may contain confidential and/or privileged information. >> If you are not the intended recipient (or have received this e-mail in >> error) please notify the sender immediately and destroy this e-mail. >> Any unauthorized copying, disclosure or distribution of the material in >> this e-mail is strictly forbidden. From ben at well-typed.com Sat Jan 23 11:51:04 2016 From: ben at well-typed.com (Ben Gamari) Date: Sat, 23 Jan 2016 12:51:04 +0100 Subject: Options -Wmissed-specialisations, -Wall-missed-specialisations and -Werror In-Reply-To: References: Message-ID: <874me4fr9z.fsf@smart-cactus.org> Andr?s Sicard-Ram?rez writes: > Dear all, > > In GHC 8 RC 1, the `-Wmissed-specialisations` and > `-Wall-missed-specialisations` options generate a warning instead of > an error when using `-Werror`. Is it the expected behaviour? > I would say this can be considered correct. This warning is really intended to let the user know that a specialization hasn't occurred; fixing this may require changes in code which they have little control over (e.g. adding an inline pragma to an upstream library). Regardless, this behavior probably ought to be a bit better documented. I've opened D1829 fixing this. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From andrey.mokhov at newcastle.ac.uk Sat Jan 23 13:05:56 2016 From: andrey.mokhov at newcastle.ac.uk (Andrey Mokhov) Date: Sat, 23 Jan 2016 13:05:56 +0000 Subject: [ANNOUNCE] Shaking up GHC Message-ID: Thanks David! > Are there any plans as to how to include it in the GHC tree? Does it > ship with all the libraries required to build the build system, will we > have a mini-build system to bootstrap it? If I recall correctly, we rely > on Cabal sandboxes on Linux/OSX and global Cabal library > installations on Windows in order to run it. The simplest way is to add the 'shake-build' folder to the GHC tree and ask first adopters of the new build system to globally install the dependencies (ansi-terminal, mtl, shake, QuickCheck). Then 'build.sh' and 'build.bat' scripts should work. I am open to suggestions on how to make this more convenient and robust. I've never used anything more advanced than a global cabal installation, so I'd appreciate input from more experienced users. Could you create a ticket on github suggesting possible approaches? I'm afraid our discussion may get lost in ghc-devs mailing list. Many thanks! Andrey > From: David Luposchainsky > To: ghc-devs at haskell.org > Subject: Re: [ANNOUNCE] Shaking up GHC > Message-ID: <56A27EB1.1080701 at gmail.com> > Content-Type: text/plain; charset=windows-1252 > > Great work Andrey! > > I'm actually (pleasantly) surprised this is becoming part of the GHC > tree so soon > . > > Are there any plans as to how to include it in the GHC tree? Does it > ship with > all the libraries required to build the build system, will we have a > mini-build > system to bootstrap it? If I recall correctly, we rely on Cabal > sandboxes on > Linux/OSX and global Cabal library installations on Windows in order to > run it. > > Greetings, > David -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.colpitts at gmail.com Sat Jan 23 13:35:42 2016 From: george.colpitts at gmail.com (George Colpitts) Date: Sat, 23 Jan 2016 09:35:42 -0400 Subject: [ANNOUNCE] Shaking up GHC In-Reply-To: References: Message-ID: with ghc 8.0.0.20160111, cabal install shake fails with [43 of 47] Compiling Development.Shake.Args ( src/Development/Shake/Args.hs, dist/build/Development/Shake/Args.o ) src/Development/Shake/Args.hs:1:1: error: solveWanteds: too many iterations (limit = 4) Unsolved: WC {wc_simple = [D] _ :: Eq a (CDictCan) [D] _ :: Ord a (CDictCan) [D] _ :: Read a (CDictCan) [D] _ :: Show a (CDictCan) [W] hole{a4gTO} :: a ~ a (CNonCanonical) [D] _ :: Eq a (CDictCan)} New superclasses found Set limit with -fconstraint-solver-iterations=n; n=0 for no limit Is this a known problem? Thanks On Sat, Jan 23, 2016 at 9:05 AM, Andrey Mokhov < andrey.mokhov at newcastle.ac.uk> wrote: > Thanks David! > > > > > Are there any plans as to how to include it in the GHC tree? Does it > > > ship with all the libraries required to build the build system, will we > > > have a mini-build system to bootstrap it? If I recall correctly, we rely > > > on Cabal sandboxes on Linux/OSX and global Cabal library > > > installations on Windows in order to run it. > > > > The simplest way is to add the 'shake-build' folder to the GHC tree and > > ask first adopters of the new build system to globally install the > > dependencies (ansi-terminal, mtl, shake, QuickCheck). Then 'build.sh' > > and 'build.bat' scripts should work. > > > > I am open to suggestions on how to make this more convenient and > > robust. I've never used anything more advanced than a global cabal > > installation, so I'd appreciate input from more experienced users. > > > > Could you create a ticket on github suggesting possible approaches? > > I'm afraid our discussion may get lost in ghc-devs mailing list. > > > > Many thanks! > > Andrey > > > > > From: David Luposchainsky > > > To: ghc-devs at haskell.org > > > Subject: Re: [ANNOUNCE] Shaking up GHC > > > Message-ID: <56A27EB1.1080701 at gmail.com> > > > Content-Type: text/plain; charset=windows-1252 > > > > > > Great work Andrey! > > > > > > I'm actually (pleasantly) surprised this is becoming part of the GHC > > > tree so soon > > > . > > > > > > Are there any plans as to how to include it in the GHC tree? Does it > > > ship with > > > all the libraries required to build the build system, will we have a > > > mini-build > > > system to bootstrap it? If I recall correctly, we rely on Cabal > > > sandboxes on > > > Linux/OSX and global Cabal library installations on Windows in order to > > > run it. > > > > > > Greetings, > > > David > > _______________________________________________ > 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: From andrey.mokhov at newcastle.ac.uk Sat Jan 23 14:11:07 2016 From: andrey.mokhov at newcastle.ac.uk (Andrey Mokhov) Date: Sat, 23 Jan 2016 14:11:07 +0000 Subject: [ANNOUNCE] Shaking up GHC In-Reply-To: References: Message-ID: Hi George, I think you are hitting this bug: https://ghc.haskell.org/trac/ghc/ticket/11379. Note, you don't have to use GHC HEAD as a bootstrapping compiler. I'm bootstrapping with GHC 7.10.1, for example. Cheers, Andrey From: George Colpitts [mailto:george.colpitts at gmail.com] Sent: 23 January 2016 13:36 To: Andrey Mokhov Cc: dluposchainsky at googlemail.com; GHC developers Subject: Re: [ANNOUNCE] Shaking up GHC with ghc 8.0.0.20160111, cabal install shake fails with [43 of 47] Compiling Development.Shake.Args ( src/Development/Shake/Args.hs, dist/build/Development/Shake/Args.o ) src/Development/Shake/Args.hs:1:1: error: solveWanteds: too many iterations (limit = 4) Unsolved: WC {wc_simple = [D] _ :: Eq a (CDictCan) [D] _ :: Ord a (CDictCan) [D] _ :: Read a (CDictCan) [D] _ :: Show a (CDictCan) [W] hole{a4gTO} :: a ~ a (CNonCanonical) [D] _ :: Eq a (CDictCan)} New superclasses found Set limit with -fconstraint-solver-iterations=n; n=0 for no limit Is this a known problem? Thanks On Sat, Jan 23, 2016 at 9:05 AM, Andrey Mokhov > wrote: Thanks David! > Are there any plans as to how to include it in the GHC tree? Does it > ship with all the libraries required to build the build system, will we > have a mini-build system to bootstrap it? If I recall correctly, we rely > on Cabal sandboxes on Linux/OSX and global Cabal library > installations on Windows in order to run it. The simplest way is to add the 'shake-build' folder to the GHC tree and ask first adopters of the new build system to globally install the dependencies (ansi-terminal, mtl, shake, QuickCheck). Then 'build.sh' and 'build.bat' scripts should work. I am open to suggestions on how to make this more convenient and robust. I've never used anything more advanced than a global cabal installation, so I'd appreciate input from more experienced users. Could you create a ticket on github suggesting possible approaches? I'm afraid our discussion may get lost in ghc-devs mailing list. Many thanks! Andrey > From: David Luposchainsky > > To: ghc-devs at haskell.org > Subject: Re: [ANNOUNCE] Shaking up GHC > Message-ID: <56A27EB1.1080701 at gmail.com> > Content-Type: text/plain; charset=windows-1252 > > Great work Andrey! > > I'm actually (pleasantly) surprised this is becoming part of the GHC > tree so soon > . > > Are there any plans as to how to include it in the GHC tree? Does it > ship with > all the libraries required to build the build system, will we have a > mini-build > system to bootstrap it? If I recall correctly, we rely on Cabal > sandboxes on > Linux/OSX and global Cabal library installations on Windows in order to > run it. > > Greetings, > David _______________________________________________ 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: From tuncer.ayaz at gmail.com Sat Jan 23 16:58:12 2016 From: tuncer.ayaz at gmail.com (Tuncer Ayaz) Date: Sat, 23 Jan 2016 17:58:12 +0100 Subject: [ANNOUNCE] Shaking up GHC In-Reply-To: References: Message-ID: On 23 January 2016 at 14:05, Andrey Mokhov wrote: > The simplest way is to add the 'shake-build' folder to the GHC tree > and ask first adopters of the new build system to globally install > the dependencies (ansi-terminal, mtl, shake, QuickCheck). Then > 'build.sh' and 'build.bat' scripts should work. > > I am open to suggestions on how to make this more convenient and > robust. I've never used anything more advanced than a global cabal > installation, so I'd appreciate input from more experienced users. > > Could you create a ticket on github suggesting possible > approaches? I'm afraid our discussion may get lost in ghc-devs > mailing list. My suggestion, and what I'd expect, is to make Shake part of GHC's included lib, just like process or xhtml. Neil said this can be a maintenance burden, and I'm aware of that argument, but the bundled libs ghc depends on are not maintained by ghc devs and merely included as known-to-work versions to go with the ghc release as well. Why do I want this? a1) Want to use Shake? Install GHC via OS pkg mgr or prebuilt binary tarball, and be done. This way, telling potential users migrating from Makefile(s) to Shake is as easy as "Install ghc-8.0". Anyone who needs a different Shake version can, as it's done right now with cabal(-install), install Cabal+cabal-install as a 2nd dependency. So, anybody that that wants to use Shake instead of make, can just install ghc itself. That's a very minimal set of requirements and steps, compared to installing Shake after first getting ghc. a2) Like what Xmonad has done for custom window management, Shake can be that for build scripts that are written in one language, compared to Ninja, where it's meant to be generated from something else. Requiring just ghc and nothing else, is easier to sell, given how easy it has been dependency-wise (breakage, etc.) to install ghc on various Linux or BSD distros I've tried it on. a3) As an extension of (a2), it's preferable to write build scripts in Haskell than Guile Scheme, and anything we can do to make that easier is a good thing. We don't want to move m4+(auto)make+sh to Scheme, where it's arguably easier to publish broken scripts due to the dynamic nature them. Why do I think it's not a big deal to do it this way? b1) Seeing how Shake is needed to build ghc itself, Edward's working on using it in ghc --make, and both cabal and stack devs are looking into reusing Shake, it makes a whole lot of sense to not make it an extra dependency. b2) The way I see it, relying on Alex and Happy is, for instance, different, as those are usable as plain executable without a Haskell library. So, by keeping Shake bundled like xhtml or process, we'd not add external dependencies that need ghc and maybe cabal/stack to be built. b3) Just like everyone is free to use a newer xhtml, regardless of what's bundled with a ghc release, nothing prevents you from installing a newer Shake than what's in the ghc release. Thus, I don't think we'd have to make it ghc-private. From hvriedel at gmail.com Sat Jan 23 17:13:45 2016 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Sat, 23 Jan 2016 18:13:45 +0100 Subject: [ANNOUNCE] Shaking up GHC In-Reply-To: (Andrey Mokhov's message of "Sat, 23 Jan 2016 13:05:56 +0000") References: Message-ID: <87vb6kkyly.fsf@gmail.com> On 2016-01-23 at 14:05:56 +0100, Andrey Mokhov wrote: >> Are there any plans as to how to include it in the GHC tree? Does it >> ship with all the libraries required to build the build system, will we >> have a mini-build system to bootstrap it? If I recall correctly, we rely >> on Cabal sandboxes on Linux/OSX and global Cabal library >> installations on Windows in order to run it. > > The simplest way is to add the 'shake-build' folder to the GHC tree and > ask first adopters of the new build system to globally install the > dependencies (ansi-terminal, mtl, shake, QuickCheck). Then 'build.sh' > and 'build.bat' scripts should work. > > I am open to suggestions on how to make this more convenient and > robust. I've never used anything more advanced than a global cabal > installation, so I'd appreciate input from more experienced users. I think it's already quite convenient. After all, you're expected to have a minimum GHC bootstrapping environment anyway. So having the tools installed (as already do now, e.g. you need alex, happy, and ghc to be able to work on GHC). And the new cabal nix-store feature to show-case as tech-preview together with GHC 8.0 makes this even more robust by avoiding pkg-db breakages due to reinstalls, which would be the main reason not to rely on "global installed dependency". The shake-build.sh script simply needs to invoke `cabal new-build` to generate the ghc shake build-tool executable. From hvriedel at gmail.com Sat Jan 23 17:16:28 2016 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Sat, 23 Jan 2016 18:16:28 +0100 Subject: [ANNOUNCE] Shaking up GHC In-Reply-To: (Tuncer Ayaz's message of "Sat, 23 Jan 2016 17:58:12 +0100") References: Message-ID: <87oacckyhf.fsf@gmail.com> On 2016-01-23 at 17:58:12 +0100, Tuncer Ayaz wrote: [...] > My suggestion, and what I'd expect, is to make Shake part of GHC's > included lib, just like process or xhtml. please don't; the only reason we include process and xhtml because we *have* to. The less we *have* to bundle, the better. From tuncer.ayaz at gmail.com Sat Jan 23 17:21:42 2016 From: tuncer.ayaz at gmail.com (Tuncer Ayaz) Date: Sat, 23 Jan 2016 18:21:42 +0100 Subject: [ANNOUNCE] Shaking up GHC In-Reply-To: <87oacckyhf.fsf@gmail.com> References: <87oacckyhf.fsf@gmail.com> Message-ID: On 23 January 2016 at 18:16, Herbert Valerio Riedel wrote: > On 2016-01-23 at 17:58:12 +0100, Tuncer Ayaz wrote: > > [...] > > > My suggestion, and what I'd expect, is to make Shake part of GHC's > > included lib, just like process or xhtml. > > please don't; the only reason we include process and xhtml because > we *have* to. The less we *have* to bundle, the better. If there's a good way in 8.x (with new Cabal and Shake) to avoid bundling, while using Shake for ghc --make, then I'm all for it. My concern is that it has to be as simple as it's currently to install ghc on a random Linux distro, in order for someone to use a Shakefile. I want more Shakefile users :). From ben at smart-cactus.org Sat Jan 23 18:45:50 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Sat, 23 Jan 2016 19:45:50 +0100 Subject: [ANNOUNCE] Shaking up GHC In-Reply-To: References: <87oacckyhf.fsf@gmail.com> Message-ID: <87twm4dti9.fsf@smart-cactus.org> Tuncer Ayaz writes: > On 23 January 2016 at 18:16, Herbert Valerio Riedel wrote: > >> On 2016-01-23 at 17:58:12 +0100, Tuncer Ayaz wrote: >> >> [...] >> >> > My suggestion, and what I'd expect, is to make Shake part of GHC's >> > included lib, just like process or xhtml. >> >> please don't; the only reason we include process and xhtml because >> we *have* to. The less we *have* to bundle, the better. > > If there's a good way in 8.x (with new Cabal and Shake) to avoid > bundling, while using Shake for ghc --make, then I'm all for it. My > concern is that it has to be as simple as it's currently to install > ghc on a random Linux distro, in order for someone to use a Shakefile. > I want more Shakefile users :). I'm not sure I follow. Edward's --make support is a front-end plugin; as far as I know there has been no discussion of shipping it with GHC-proper. It merely makes use of the new front-end plugin facility. Perhaps I'm misunderstanding something here? Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From karel.gardas at centrum.cz Sat Jan 23 19:09:32 2016 From: karel.gardas at centrum.cz (Karel Gardas) Date: Sat, 23 Jan 2016 20:09:32 +0100 Subject: [ANNOUNCE] Shaking up GHC In-Reply-To: References: <87oacckyhf.fsf@gmail.com> Message-ID: <56A3CFEC.8060903@centrum.cz> On 01/23/16 06:21 PM, Tuncer Ayaz wrote: > If there's a good way in 8.x (with new Cabal and Shake) to avoid > bundling, while using Shake for ghc --make, then I'm all for it. My > concern is that it has to be as simple as it's currently to install > ghc on a random Linux distro, in order for someone to use a Shakefile. Not only random Linux distro please! GHC supports a lot of other nice OSes and it would be a pity if shake-based build does not support them too. Karel From tuncer.ayaz at gmail.com Sat Jan 23 20:01:09 2016 From: tuncer.ayaz at gmail.com (Tuncer Ayaz) Date: Sat, 23 Jan 2016 21:01:09 +0100 Subject: [ANNOUNCE] Shaking up GHC In-Reply-To: <56A3CFEC.8060903@centrum.cz> References: <87oacckyhf.fsf@gmail.com> <56A3CFEC.8060903@centrum.cz> Message-ID: On 23 January 2016 at 20:09, Karel Gardas wrote: > On 01/23/16 06:21 PM, Tuncer Ayaz wrote: > > > > If there's a good way in 8.x (with new Cabal and Shake) to avoid > > bundling, while using Shake for ghc --make, then I'm all for it. > > My concern is that it has to be as simple as it's currently to > > install ghc on a random Linux distro, in order for someone to use > > a Shakefile. > > > Not only random Linux distro please! GHC supports a lot of other > nice OSes and it would be a pity if shake-based build does not > support them too. Where available via pkgng or pkgsrc, it's also a quick install away. I've mentioned Linux+BSD (and left out Illumos), but subsequently forgot to mention BSDs, etc. here. Sorry about that. Better wording: "as simple as 'pkgmgr install ghc'". From tuncer.ayaz at gmail.com Sat Jan 23 20:09:08 2016 From: tuncer.ayaz at gmail.com (Tuncer Ayaz) Date: Sat, 23 Jan 2016 21:09:08 +0100 Subject: [ANNOUNCE] Shaking up GHC In-Reply-To: <87twm4dti9.fsf@smart-cactus.org> References: <87oacckyhf.fsf@gmail.com> <87twm4dti9.fsf@smart-cactus.org> Message-ID: On 23 January 2016 at 19:45, Ben Gamari wrote: > I'm not sure I follow. Edward's --make support is a front-end > plugin; as far as I know there has been no discussion of shipping it > with GHC-proper. It merely makes use of the new front-end plugin > facility. Perhaps I'm misunderstanding something here? You likely aren't, and I'm probably under-informed. Viewing 'ghc --make' as a core feature of ghc-the-executable, I've assumed Shake (the lib) to be a build-time+run-time requirement. From andrey.mokhov at newcastle.ac.uk Sat Jan 23 21:17:46 2016 From: andrey.mokhov at newcastle.ac.uk (Andrey Mokhov) Date: Sat, 23 Jan 2016 21:17:46 +0000 Subject: [ANNOUNCE] Shaking up GHC In-Reply-To: <87vb6kkyly.fsf@gmail.com> References: <87vb6kkyly.fsf@gmail.com> Message-ID: Herbert, > I think it's already quite convenient. After all, you're expected to > have a minimum GHC bootstrapping environment anyway. So having the > tools installed (as already do now, e.g. you need alex, happy, and > ghc to be able to work on GHC). I agree. Roughly, we are talking about going from: cabal install alex happy to: cabal install alex happy ansi-terminal mtl shake QuickCheck This doesn't look too onerous (although one could also consider somehow packaging these dependencies together). And hopefully upcoming cabal features will make this more robust. Tuncer, > My suggestion, and what I'd expect, is to make Shake part of > GHC's included lib, just like process or xhtml. This sounds like a very big decision which is beyond the Shaking up GHC project. (I wouldn't want to shake up GHC too much!) Cheers, Andrey > -----Original Message----- > From: Herbert Valerio Riedel [mailto:hvriedel at gmail.com] > Sent: 23 January 2016 17:14 > To: Andrey Mokhov > Cc: dluposchainsky at googlemail.com; GHC developers > Subject: Re: [ANNOUNCE] Shaking up GHC > > On 2016-01-23 at 14:05:56 +0100, Andrey Mokhov wrote: > >> Are there any plans as to how to include it in the GHC tree? Does it > >> ship with all the libraries required to build the build system, will > we > >> have a mini-build system to bootstrap it? If I recall correctly, we > rely > >> on Cabal sandboxes on Linux/OSX and global Cabal library > >> installations on Windows in order to run it. > > > > The simplest way is to add the 'shake-build' folder to the GHC tree > and > > ask first adopters of the new build system to globally install the > > dependencies (ansi-terminal, mtl, shake, QuickCheck). Then 'build.sh' > > and 'build.bat' scripts should work. > > > > I am open to suggestions on how to make this more convenient and > > robust. I've never used anything more advanced than a global cabal > > installation, so I'd appreciate input from more experienced users. > > I think it's already quite convenient. After all, you're expected to > have a minimum GHC bootstrapping environment anyway. So having the > tools > installed (as already do now, e.g. you need alex, happy, and ghc to be > able to work on GHC). > > And the new cabal nix-store feature to show-case as tech-preview > together with GHC 8.0 makes this even more robust by avoiding pkg-db > breakages due to reinstalls, which would be the main reason not to > rely on "global installed dependency". > > The shake-build.sh script simply needs to invoke `cabal new-build` to > generate the ghc shake build-tool executable. From ben at smart-cactus.org Sat Jan 23 21:22:06 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Sat, 23 Jan 2016 22:22:06 +0100 Subject: [ANNOUNCE] Shaking up GHC In-Reply-To: References: <87vb6kkyly.fsf@gmail.com> Message-ID: <87r3h8dm9t.fsf@smart-cactus.org> Andrey Mokhov writes: > Herbert, > >> I think it's already quite convenient. After all, you're expected to >> have a minimum GHC bootstrapping environment anyway. So having the >> tools installed (as already do now, e.g. you need alex, happy, and >> ghc to be able to work on GHC). > > I agree. Roughly, we are talking about going from: > > cabal install alex happy > > to: > > cabal install alex happy ansi-terminal mtl shake QuickCheck > Wouldn't git clone git://github.com/snowleopard/shaking-up-ghc shake-build cabal install shake-build/ be sufficient? Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From kili at outback.escape.de Sat Jan 23 21:25:31 2016 From: kili at outback.escape.de (Matthias Kilian) Date: Sat, 23 Jan 2016 22:25:31 +0100 Subject: [ANNOUNCE] Shaking up GHC In-Reply-To: <56A3CFEC.8060903@centrum.cz> References: <87oacckyhf.fsf@gmail.com> <56A3CFEC.8060903@centrum.cz> Message-ID: <20160123212531.GB7035@nutty.outback.escape.de> Hi, On Sat, Jan 23, 2016 at 08:09:32PM +0100, Karel Gardas wrote: > On 01/23/16 06:21 PM, Tuncer Ayaz wrote: > >If there's a good way in 8.x (with new Cabal and Shake) to avoid > >bundling, while using Shake for ghc --make, then I'm all for it. My > >concern is that it has to be as simple as it's currently to install > >ghc on a random Linux distro, in order for someone to use a Shakefile. > > Not only random Linux distro please! GHC supports a lot of other nice OSes > and it would be a pity if shake-based build does not support them too. Thanks, Karel, for pointing that out ;-) First, I don't know Shake, and I didn't follow this thread too closely, but let me describe the way packages for OpenBSD are built and used (as I'm the guy who tries to keep ghc and some tools implemented in Haskell running on that system). This may help understanding the requirements at least OpenBSD (but probably other disstributions) have. - Users install packages (like ghc, darcs, xmonad or the haskell-platform, which is a meta-package) with OpenBSDs pkg_add(1). Those packages are fetched from official OpenBSD mirrors. In porticular, users are *not* expected to build anything themselves (but of course they may if they want). - Oficcial binary packages are built for releases and regularly for OpenBSD-current ('HEAD') on dedicated build machines run by OpenBSD people. - Package builds start *from scratch* with only the OpenBSD base system installed, and whenever the build of one package depends on another package, the latter has to be built from scratch first. - Those builds are done from upstream source distributions (like ghc-7.10.3b-src.tar.bz2); preexisting binaries from external sources are frowned upon. - It is, however, acceptable, that a port maintainer supplies additional distfiles containing precompiled stuff. For example, for ghc, i provide trimmed down binary builds of ghc for boostrapping. Here's a proble, because people have to trust me that i'm not creating a bootstraper doing evil things. So, in short, the requirements for a system like OpenBSD supporting ghc as a binary package are self-contained ghc source distrivutions (with all files needed to build it from source) and a way to create a ghc bindist that can be used for building ghc from its source distribution. Ciao, Kili From andrey.mokhov at newcastle.ac.uk Sat Jan 23 21:40:56 2016 From: andrey.mokhov at newcastle.ac.uk (Andrey Mokhov) Date: Sat, 23 Jan 2016 21:40:56 +0000 Subject: [ANNOUNCE] Shaking up GHC In-Reply-To: <87r3h8dm9t.fsf@smart-cactus.org> References: <87vb6kkyly.fsf@gmail.com> <87r3h8dm9t.fsf@smart-cactus.org> Message-ID: Ben, > Wouldn't > > git clone git://github.com/snowleopard/shaking-up-ghc shake-build > cabal install shake-build/ > > be sufficient? As I understand, this will not take care of alex and happy? Although if we list them as dependencies in shaking-up-ghc.cabal, that will indeed be sufficient... I think it's a good idea :) Cheers, Andrey > -----Original Message----- > From: Ben Gamari [mailto:ben at smart-cactus.org] > Sent: 23 January 2016 21:22 > To: Andrey Mokhov; Herbert Valerio Riedel; Tuncer Ayaz > Cc: GHC developers > Subject: RE: [ANNOUNCE] Shaking up GHC > > Andrey Mokhov writes: > > > Herbert, > > > >> I think it's already quite convenient. After all, you're expected to > >> have a minimum GHC bootstrapping environment anyway. So having the > >> tools installed (as already do now, e.g. you need alex, happy, and > >> ghc to be able to work on GHC). > > > > I agree. Roughly, we are talking about going from: > > > > cabal install alex happy > > > > to: > > > > cabal install alex happy ansi-terminal mtl shake QuickCheck > > > Wouldn't > > git clone git://github.com/snowleopard/shaking-up-ghc shake-build > cabal install shake-build/ > > be sufficient? > > Cheers, > > - Ben From ezyang at mit.edu Sat Jan 23 21:43:23 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Sat, 23 Jan 2016 13:43:23 -0800 Subject: [ANNOUNCE] Shaking up GHC In-Reply-To: <87twm4dti9.fsf@smart-cactus.org> References: <87oacckyhf.fsf@gmail.com> <87twm4dti9.fsf@smart-cactus.org> Message-ID: <1453585357-sup-8455@sabre> I mean, it would be nice if ghc --make was reimplemented using Shake, but there are a few problems (most notably the use of .shake metadata store) which make it hard to be bug-for-bug compatible with the old make. Edward Excerpts from Ben Gamari's message of 2016-01-23 10:45:50 -0800: > Tuncer Ayaz writes: > > > On 23 January 2016 at 18:16, Herbert Valerio Riedel wrote: > > > >> On 2016-01-23 at 17:58:12 +0100, Tuncer Ayaz wrote: > >> > >> [...] > >> > >> > My suggestion, and what I'd expect, is to make Shake part of GHC's > >> > included lib, just like process or xhtml. > >> > >> please don't; the only reason we include process and xhtml because > >> we *have* to. The less we *have* to bundle, the better. > > > > If there's a good way in 8.x (with new Cabal and Shake) to avoid > > bundling, while using Shake for ghc --make, then I'm all for it. My > > concern is that it has to be as simple as it's currently to install > > ghc on a random Linux distro, in order for someone to use a Shakefile. > > I want more Shakefile users :). > > I'm not sure I follow. Edward's --make support is a front-end plugin; > as far as I know there has been no discussion of shipping it with > GHC-proper. It merely makes use of the new front-end plugin facility. > Perhaps I'm misunderstanding something here? > > Cheers, > > - Ben From george.colpitts at gmail.com Sun Jan 24 16:05:05 2016 From: george.colpitts at gmail.com (George Colpitts) Date: Sun, 24 Jan 2016 12:05:05 -0400 Subject: dynamic linking and GHC 8.0.1 User's Guide Message-ID: I believe that static linking will produce a faster program, at least in some situations. If so it would be good to mention this in section 8.2 of the user's guide, *Faster: producing a program that runs quicker, * I couldn't find documentation for the -dynamic-too option of GHC. If it isn't there it would be good to document. I looked in the index, and sections 6.11.5. *Options affecting code generation, *and 6.11.6. *Options affecting linking.* Is there a pdf version of the GHC 8.0.1 User's Guide? It' much easier to search in the pdf version. 8.0.1 rc1 just has an html version but perhaps there is a pdf version available on the web somewhere. I assume the final version of 8.0.1 will have a pdf version. Thanks George -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Sun Jan 24 21:24:16 2016 From: david.feuer at gmail.com (David Feuer) Date: Sun, 24 Jan 2016 16:24:16 -0500 Subject: Type class for sanity Message-ID: Since type families can be stuck, it's sometimes useful to restrict things to sane types. At present, the most convenient way I can see to do this in general is with Typeable: type family Foo x where Foo 'True = Int class Typeable (Foo x) => Bar x where blah :: proxy x -> Foo x This will prevent anyone from producing the bogus instance instance Bar 'False where blah _ = undefined Unfortunately, the Typeable constraint carries runtime overhead. One possible way around this, I think, is with a class that does just sanity checking and nothing more: class Sane (a :: k) instance Sane Int instance Sane Char instance Sane 'False instance Sane 'True instance Sane '[] instance Sane '(:) instance Sane (->) instance Sane 'Just instance Sane 'Nothing instance (Sane f, Sane x) => Sane (f x) To really do its job properly, Sane would need to have instances for all sane types and no more. An example of an insane instance of Sane would be instance Sane (a :: MyKind) which would include stuck types of kind MyKind. Would it be useful to add such an automatic-only class to GHC? David From omeragacan at gmail.com Mon Jan 25 01:58:02 2016 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Sun, 24 Jan 2016 20:58:02 -0500 Subject: a reliable way of dropping levity args? Message-ID: Hi all, I'm looking for a reliable way of dropping levity args from TyCon applications. When I know that a particular TyCon gets some number of levity args, I can just drop the args manually (for example, I can drop the first half of arguments of a tuple TyCon application) but the code looks fragile (what happens if I use a different TyCon in the future) and confusing to the reader because it looks like this: drop (length args `div` 2) args Ideally it'd look like this: dropWhile isLevityArg args Now, there's a function called isLevityTy, but I don't understand what it's supposed to do. This doesn't do anyting to 'Boxed and 'Unboxed arguments: dropWhile (isLevityArg . idType) args Any ideas on this? Thanks.. From david.feuer at gmail.com Mon Jan 25 06:23:13 2016 From: david.feuer at gmail.com (David Feuer) Date: Mon, 25 Jan 2016 01:23:13 -0500 Subject: Type class for sanity In-Reply-To: References: Message-ID: See https://typesandkinds.wordpress.com/2015/09/09/what-are-type-families/ for some discussion. A type family application is stuck if it can't reduce further and has not reached a proper type. Given the aforementioned type family Foo, the application Foo 'False is stuck. It's a type of kind *, and it's uninhabited (but not as nicely uninhabited as Void--it offers no ex falso). This actually turns out to be useful for some things. GHC offers type family Any :: k where {} which is, at least, 1. A safe intermediate target for unsafeCoerce 2. An utterly unsatisfiable constraint (see the definition of Bottom in the GitHub master of the reflection package) But sometimes you want to know something's *not* a stuck type family. See the issue I filed earlier today at https://github.com/kwf/ComonadSheet/issues/6 for an example--the code tries to make a certain instance impossible to produce, but the possibility of stuckness defeats it as its currently written. On Jan 25, 2016 1:01 AM, "Jeffrey Brown" wrote: > "Stuck type" is proving difficult to Google. Do you recommend any > references? > > On Sun, Jan 24, 2016 at 1:24 PM, David Feuer > wrote: > >> Since type families can be stuck, it's sometimes useful to restrict >> things to sane types. At present, the most convenient way I can see to >> do this in general is with Typeable: >> >> type family Foo x where >> Foo 'True = Int >> >> class Typeable (Foo x) => Bar x where >> blah :: proxy x -> Foo x >> >> This will prevent anyone from producing the bogus instance >> >> instance Bar 'False where >> blah _ = undefined >> >> Unfortunately, the Typeable constraint carries runtime overhead. One >> possible way around this, I think, is with a class that does just >> sanity checking and nothing more: >> >> class Sane (a :: k) >> instance Sane Int >> instance Sane Char >> instance Sane 'False >> instance Sane 'True >> instance Sane '[] >> instance Sane '(:) >> instance Sane (->) >> instance Sane 'Just >> instance Sane 'Nothing >> instance (Sane f, Sane x) => Sane (f x) >> >> To really do its job properly, Sane would need to have instances for >> all sane types and no more. An example of an insane instance of Sane >> would be >> >> instance Sane (a :: MyKind) >> >> which would include stuck types of kind MyKind. >> >> Would it be useful to add such an automatic-only class to GHC? >> >> David >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > > > > -- > Jeffrey Benjamin Brown > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Jan 25 12:13:59 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 25 Jan 2016 12:13:59 +0000 Subject: [ANNOUNCE] Shaking up GHC In-Reply-To: References: Message-ID: <9c0cbf832813492aae0828fdf172f02c@DB4PR30MB030.064d.mgd.msft.net> Very good. As I understand it, it can work side-by-side with the existing build system, correct? That means we don't need to make an either/or choice, which is very helpful. Every day I do sh validate --fast --no-clean How can I do that using Shake to build? Maybe sh validate --shake --fast --no-clean or something? Just modifying the validate script to make it convenient to use shake for the build part would be great. You say: The make-based build system uses mk/build.mk to specify user build settings. We use src/Settings/User.hs for the same purpose. Feel free to experiment following the Haddock comments. But User.hs is a source file, which we shouldn't normally modify lest we accidentally commit it. Could we have a non-source file to modify (rather like build.mk being based on build.mk.sample) Simon | -----Original Message----- | From: Andrey Mokhov [mailto:andrey.mokhov at newcastle.ac.uk] | Sent: 22 January 2016 14:27 | To: ghc-devs at haskell.org | Cc: Simon Peyton Jones ; Neil Mitchell | ; Simon Marlow | Subject: [ANNOUNCE] Shaking up GHC | | Dear GHC developers, | | I am happy to announce that the Shaking up GHC project has finally | reached the first milestone. The goal of the project is to design a | new GHC build system based on Shake that will eventually replace the | current make-based one. See the project page for more details: | https://github.com/snowleopard/shaking-up-ghc. | | There is still a long way until we can match the capabilities of the | current build system. At the moment we only build vanilla way. | Validation, documentation, build flavours and cross-compilation are | not yet implemented. Known limitations are listed here: | https://github.com/snowleopard/shaking-up-ghc#current-limitations. | | The purpose of this announcement is to attract alpha testers and | collect early feedback across multiple platforms and build | configurations. We already have several success reports on Linux, OS | X, Solaris and Windows. However, things will inevitably break and we | hope to catch and fix as many of these cases as possible with your | help. The instructions on how to try the new build system can be found | here: https://github.com/snowleopard/shaking-up-ghc#your-first-build. | | We plan to be ready to become a part of the GHC tree around 1 March | 2016, and catch up with the make build system around 1 June 2016. The | dates are tentative and depend on how much time it takes us to resolve | the remaining issues: https://github.com/snowleopard/shaking-up- | ghc/milestones. | | I would like thank everyone who contributed to this project so far: | Simon Peyton Jones, Neil Mitchell and Simon Marlow came up with the | idea and guided me throughout the project; Moritz Angermann, Ben | Gamari, Karel Gardas, David Luposchainsky, and Neil Mitchell | contributed to the codebase. Thank you all! | | Kind regards, | Andrey From eir at cis.upenn.edu Mon Jan 25 12:30:12 2016 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 25 Jan 2016 07:30:12 -0500 Subject: a reliable way of dropping levity args? In-Reply-To: References: Message-ID: As discussed on IRC, your approach below looks right to me: dropWhile (isLevityTy . idType) args. But you then said this wasn't working for you. What does (map idType args) say? Richard On Jan 24, 2016, at 8:58 PM, ?mer Sinan A?acan wrote: > Hi all, > > I'm looking for a reliable way of dropping levity args from TyCon applications. > When I know that a particular TyCon gets some number of levity args, I can just > drop the args manually (for example, I can drop the first half of arguments of > a tuple TyCon application) but the code looks fragile (what happens if I use a > different TyCon in the future) and confusing to the reader because it looks > like this: > > drop (length args `div` 2) args > > Ideally it'd look like this: > > dropWhile isLevityArg args > > Now, there's a function called isLevityTy, but I don't understand what it's > supposed to do. This doesn't do anyting to 'Boxed and 'Unboxed arguments: > > dropWhile (isLevityArg . idType) args > > Any ideas on this? > > Thanks.. From eir at cis.upenn.edu Mon Jan 25 12:34:18 2016 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 25 Jan 2016 07:34:18 -0500 Subject: Type class for sanity In-Reply-To: References: Message-ID: <18F29A7D-2691-47CE-AC2B-12BEC943A4CD@cis.upenn.edu> +1 This would be very easy to implement, too. But I suggest a different name. Ground? Terminating? NormalForm? Irreducible? ValueType? I don't love any of these, but I love Sane less. On Jan 24, 2016, at 4:24 PM, David Feuer wrote: > Since type families can be stuck, it's sometimes useful to restrict > things to sane types. At present, the most convenient way I can see to > do this in general is with Typeable: > > type family Foo x where > Foo 'True = Int > > class Typeable (Foo x) => Bar x where > blah :: proxy x -> Foo x > > This will prevent anyone from producing the bogus instance > > instance Bar 'False where > blah _ = undefined > > Unfortunately, the Typeable constraint carries runtime overhead. One > possible way around this, I think, is with a class that does just > sanity checking and nothing more: > > class Sane (a :: k) > instance Sane Int > instance Sane Char > instance Sane 'False > instance Sane 'True > instance Sane '[] > instance Sane '(:) > instance Sane (->) > instance Sane 'Just > instance Sane 'Nothing > instance (Sane f, Sane x) => Sane (f x) > > To really do its job properly, Sane would need to have instances for > all sane types and no more. An example of an insane instance of Sane > would be > > instance Sane (a :: MyKind) > > which would include stuck types of kind MyKind. > > Would it be useful to add such an automatic-only class to GHC? > > David > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From david.feuer at gmail.com Mon Jan 25 13:44:19 2016 From: david.feuer at gmail.com (David Feuer) Date: Mon, 25 Jan 2016 08:44:19 -0500 Subject: Type class for sanity In-Reply-To: <18F29A7D-2691-47CE-AC2B-12BEC943A4CD@cis.upenn.edu> References: <18F29A7D-2691-47CE-AC2B-12BEC943A4CD@cis.upenn.edu> Message-ID: I don't care about the name at all. Unstuck? Would we want to distinguish between whnf (e.g., Proxy Any) and nf, or is only nf sufficiently useful? On Jan 25, 2016 7:34 AM, "Richard Eisenberg" wrote: > +1 > > This would be very easy to implement, too. > > But I suggest a different name. Ground? Terminating? NormalForm? > Irreducible? ValueType? I don't love any of these, but I love Sane less. > > On Jan 24, 2016, at 4:24 PM, David Feuer wrote: > > > Since type families can be stuck, it's sometimes useful to restrict > > things to sane types. At present, the most convenient way I can see to > > do this in general is with Typeable: > > > > type family Foo x where > > Foo 'True = Int > > > > class Typeable (Foo x) => Bar x where > > blah :: proxy x -> Foo x > > > > This will prevent anyone from producing the bogus instance > > > > instance Bar 'False where > > blah _ = undefined > > > > Unfortunately, the Typeable constraint carries runtime overhead. One > > possible way around this, I think, is with a class that does just > > sanity checking and nothing more: > > > > class Sane (a :: k) > > instance Sane Int > > instance Sane Char > > instance Sane 'False > > instance Sane 'True > > instance Sane '[] > > instance Sane '(:) > > instance Sane (->) > > instance Sane 'Just > > instance Sane 'Nothing > > instance (Sane f, Sane x) => Sane (f x) > > > > To really do its job properly, Sane would need to have instances for > > all sane types and no more. An example of an insane instance of Sane > > would be > > > > instance Sane (a :: MyKind) > > > > which would include stuck types of kind MyKind. > > > > Would it be useful to add such an automatic-only class to GHC? > > > > David > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Mon Jan 25 14:00:30 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 25 Jan 2016 15:00:30 +0100 Subject: [ANNOUNCE] Shaking up GHC In-Reply-To: <9c0cbf832813492aae0828fdf172f02c@DB4PR30MB030.064d.mgd.msft.net> References: <9c0cbf832813492aae0828fdf172f02c@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <87k2mxep35.fsf@smart-cactus.org> Simon Peyton Jones writes: > Very good. > > As I understand it, it can work side-by-side with the existing build > system, correct? That means we don't need to make an either/or choice, > which is very helpful. > > Every day I do sh validate --fast --no-clean How can I do that using > Shake to build? Maybe sh validate --shake --fast --no-clean or > something? Just modifying the validate script to make it convenient > to use shake for the build part would be great. > > You say: The make-based build system uses mk/build.mk to specify user > build settings. We use src/Settings/User.hs for the same purpose. Feel > free to experiment following the Haddock comments. > > But User.hs is a source file, which we shouldn't normally modify lest > we accidentally commit it. Could we have a non-source file to modify > (rather like build.mk being based on build.mk.sample) > One way around this would be to add User.hs to .gitignore. That way git will ignore changes to this files when you `git commit -a`. You can still, however, commit changes to it if you ask git explicitly. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From eir at cis.upenn.edu Mon Jan 25 14:05:58 2016 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 25 Jan 2016 09:05:58 -0500 Subject: Type class for sanity In-Reply-To: References: <18F29A7D-2691-47CE-AC2B-12BEC943A4CD@cis.upenn.edu> Message-ID: <460529F3-2626-4505-B326-C6C6D929C357@cis.upenn.edu> Might be nice to have whnf too, while we're at it. Perhaps whnf is enough for someone and going all the way to nf would be less efficient / impossible. Richard On Jan 25, 2016, at 8:44 AM, David Feuer wrote: > I don't care about the name at all. Unstuck? Would we want to distinguish between whnf (e.g., Proxy Any) and nf, or is only nf sufficiently useful? > > On Jan 25, 2016 7:34 AM, "Richard Eisenberg" wrote: > +1 > > This would be very easy to implement, too. > > But I suggest a different name. Ground? Terminating? NormalForm? Irreducible? ValueType? I don't love any of these, but I love Sane less. > > On Jan 24, 2016, at 4:24 PM, David Feuer wrote: > > > Since type families can be stuck, it's sometimes useful to restrict > > things to sane types. At present, the most convenient way I can see to > > do this in general is with Typeable: > > > > type family Foo x where > > Foo 'True = Int > > > > class Typeable (Foo x) => Bar x where > > blah :: proxy x -> Foo x > > > > This will prevent anyone from producing the bogus instance > > > > instance Bar 'False where > > blah _ = undefined > > > > Unfortunately, the Typeable constraint carries runtime overhead. One > > possible way around this, I think, is with a class that does just > > sanity checking and nothing more: > > > > class Sane (a :: k) > > instance Sane Int > > instance Sane Char > > instance Sane 'False > > instance Sane 'True > > instance Sane '[] > > instance Sane '(:) > > instance Sane (->) > > instance Sane 'Just > > instance Sane 'Nothing > > instance (Sane f, Sane x) => Sane (f x) > > > > To really do its job properly, Sane would need to have instances for > > all sane types and no more. An example of an insane instance of Sane > > would be > > > > instance Sane (a :: MyKind) > > > > which would include stuck types of kind MyKind. > > > > Would it be useful to add such an automatic-only class to GHC? > > > > David > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Jan 25 14:21:09 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 25 Jan 2016 14:21:09 +0000 Subject: Type class for sanity In-Reply-To: <460529F3-2626-4505-B326-C6C6D929C357@cis.upenn.edu> References: <18F29A7D-2691-47CE-AC2B-12BEC943A4CD@cis.upenn.edu> <460529F3-2626-4505-B326-C6C6D929C357@cis.upenn.edu> Message-ID: <54f04e1ba120419789a3a40337df782c@AM3PR30MB019.064d.mgd.msft.net> I?m a bit dubious about whether it?s worth the effort of making this an extension that requires GHC support. Does the gain justify the (maybe-small but eternal) pain Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Richard Eisenberg Sent: 25 January 2016 14:06 To: David Feuer Cc: Haskell Libraries ; ghc-devs Subject: Re: Type class for sanity Might be nice to have whnf too, while we're at it. Perhaps whnf is enough for someone and going all the way to nf would be less efficient / impossible. Richard On Jan 25, 2016, at 8:44 AM, David Feuer > wrote: I don't care about the name at all. Unstuck? Would we want to distinguish between whnf (e.g., Proxy Any) and nf, or is only nf sufficiently useful? On Jan 25, 2016 7:34 AM, "Richard Eisenberg" > wrote: +1 This would be very easy to implement, too. But I suggest a different name. Ground? Terminating? NormalForm? Irreducible? ValueType? I don't love any of these, but I love Sane less. On Jan 24, 2016, at 4:24 PM, David Feuer > wrote: > Since type families can be stuck, it's sometimes useful to restrict > things to sane types. At present, the most convenient way I can see to > do this in general is with Typeable: > > type family Foo x where > Foo 'True = Int > > class Typeable (Foo x) => Bar x where > blah :: proxy x -> Foo x > > This will prevent anyone from producing the bogus instance > > instance Bar 'False where > blah _ = undefined > > Unfortunately, the Typeable constraint carries runtime overhead. One > possible way around this, I think, is with a class that does just > sanity checking and nothing more: > > class Sane (a :: k) > instance Sane Int > instance Sane Char > instance Sane 'False > instance Sane 'True > instance Sane '[] > instance Sane '(:) > instance Sane (->) > instance Sane 'Just > instance Sane 'Nothing > instance (Sane f, Sane x) => Sane (f x) > > To really do its job properly, Sane would need to have instances for > all sane types and no more. An example of an insane instance of Sane > would be > > instance Sane (a :: MyKind) > > which would include stuck types of kind MyKind. > > Would it be useful to add such an automatic-only class to GHC? > > David > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Mon Jan 25 14:26:09 2016 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 25 Jan 2016 09:26:09 -0500 Subject: Type class for sanity In-Reply-To: <54f04e1ba120419789a3a40337df782c@AM3PR30MB019.064d.mgd.msft.net> References: <18F29A7D-2691-47CE-AC2B-12BEC943A4CD@cis.upenn.edu> <460529F3-2626-4505-B326-C6C6D929C357@cis.upenn.edu> <54f04e1ba120419789a3a40337df782c@AM3PR30MB019.064d.mgd.msft.net> Message-ID: <6E311A34-DB3C-4459-B779-DF670EC2FDD0@cis.upenn.edu> Yes, if we can arrange that Ground a implies that Equals a [a] reduces to False, with type family Equals a b where Equals a a = True Equals a b = False But getting that to work is admittedly a feature beyond what's proposed. On Jan 25, 2016, at 9:21 AM, Simon Peyton Jones wrote: > I?m a bit dubious about whether it?s worth the effort of making this an extension that requires GHC support. Does the gain justify the (maybe-small but eternal) pain > > Simon > > From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Richard Eisenberg > Sent: 25 January 2016 14:06 > To: David Feuer > Cc: Haskell Libraries ; ghc-devs > Subject: Re: Type class for sanity > > Might be nice to have whnf too, while we're at it. Perhaps whnf is enough for someone and going all the way to nf would be less efficient / impossible. > > Richard > > On Jan 25, 2016, at 8:44 AM, David Feuer wrote: > > > I don't care about the name at all. Unstuck? Would we want to distinguish between whnf (e.g., Proxy Any) and nf, or is only nf sufficiently useful? > > On Jan 25, 2016 7:34 AM, "Richard Eisenberg" wrote: > +1 > > This would be very easy to implement, too. > > But I suggest a different name. Ground? Terminating? NormalForm? Irreducible? ValueType? I don't love any of these, but I love Sane less. > > On Jan 24, 2016, at 4:24 PM, David Feuer wrote: > > > Since type families can be stuck, it's sometimes useful to restrict > > things to sane types. At present, the most convenient way I can see to > > do this in general is with Typeable: > > > > type family Foo x where > > Foo 'True = Int > > > > class Typeable (Foo x) => Bar x where > > blah :: proxy x -> Foo x > > > > This will prevent anyone from producing the bogus instance > > > > instance Bar 'False where > > blah _ = undefined > > > > Unfortunately, the Typeable constraint carries runtime overhead. One > > possible way around this, I think, is with a class that does just > > sanity checking and nothing more: > > > > class Sane (a :: k) > > instance Sane Int > > instance Sane Char > > instance Sane 'False > > instance Sane 'True > > instance Sane '[] > > instance Sane '(:) > > instance Sane (->) > > instance Sane 'Just > > instance Sane 'Nothing > > instance (Sane f, Sane x) => Sane (f x) > > > > To really do its job properly, Sane would need to have instances for > > all sane types and no more. An example of an insane instance of Sane > > would be > > > > instance Sane (a :: MyKind) > > > > which would include stuck types of kind MyKind. > > > > Would it be useful to add such an automatic-only class to GHC? > > > > David > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Mon Jan 25 14:39:18 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 25 Jan 2016 15:39:18 +0100 Subject: vectorisation code? In-Reply-To: <3541c1a536d24f5794e432150833b428@DB4PR30MB030.064d.mgd.msft.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> <87io2lg3x4.fsf@smart-cactus.org> <56A239DF.4070006@apeiron.net> <20160122145759.GA7974@apeiron.net> <3541c1a536d24f5794e432150833b428@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <87h9i1enah.fsf@smart-cactus.org> Simon Peyton Jones writes: > Making it part of *every* validate is a big ask because it takes so > long to build. > > But we already have "sh validate --slow", which runs a lot more tests > than --fast. So maybe it could be part of --slow? > > And I do think that we should have a nightly build (although perhaps > not the continuous-integration build-every-commit stuff) that runs the > full testsuite. I don't think that happens right now. But it should. > Indeed that sounds reasonable. I have a cronjob which performs a nightly build and testsuite run anyways. As a start I can make these logs publicly available and ensure that I get notified when the build breaks. In the longer term I hope we can get some integration with Phabricator, although if I'm not mistaken this isn't yet possible. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From ben at well-typed.com Mon Jan 25 15:14:15 2016 From: ben at well-typed.com (Ben Gamari) Date: Mon, 25 Jan 2016 16:14:15 +0100 Subject: dynamic linking and GHC 8.0.1 User's Guide In-Reply-To: References: Message-ID: <87egd5elo8.fsf@smart-cactus.org> George Colpitts writes: > I believe that static linking will produce a faster program, at least in > some situations. If so it would be good to mention this in section 8.2 of > the user's guide, *Faster: producing a program that runs quicker, * > > I couldn't find documentation for the -dynamic-too option of GHC. If it > isn't there it would be good to document. I looked in the index, and > sections 6.11.5. *Options affecting code generation, *and 6.11.6. *Options > affecting linking.* > Oh dear, indeed this flag appears to be entirely undocumented. I've opened #11488 to ensure we don't lose from of this. > Is there a pdf version of the GHC 8.0.1 User's Guide? It' much easier to > search in the pdf version. 8.0.1 rc1 just has an html version but perhaps > there is a pdf version available on the web somewhere. I assume the final > version of 8.0.1 will have a pdf version. > I'll need to look at the documentation situation. While things largely "just work" on our Linux platforms, LaTeX is quite a pain on OS X and Windows. This makes producing the PDF user guide quite tricky. When I built rc1 I spent a quite bit of time trying to work out some mysterious font issues on OS X but in the end ran out of time and had to drop it. One option (although unsavory) would be to simply plop the PDF from the Linux build into the OS X and Windows tarballs. I would really prefer to avoid this, however, as this presents yet another barrier to a completely automated build, which is my eventual goal. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From ben at well-typed.com Mon Jan 25 15:15:05 2016 From: ben at well-typed.com (Ben Gamari) Date: Mon, 25 Jan 2016 16:15:05 +0100 Subject: dynamic linking and GHC 8.0.1 User's Guide In-Reply-To: References: Message-ID: <87d1spelmu.fsf@smart-cactus.org> George Colpitts writes: > I believe that static linking will produce a faster program, at least in > some situations. If so it would be good to mention this in section 8.2 of > the user's guide, *Faster: producing a program that runs quicker, * > Indeed it would be a good idea to mention this. Would you like to write up a 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: From david.feuer at gmail.com Mon Jan 25 17:35:13 2016 From: david.feuer at gmail.com (David Feuer) Date: Mon, 25 Jan 2016 12:35:13 -0500 Subject: Type class for sanity In-Reply-To: References: <18F29A7D-2691-47CE-AC2B-12BEC943A4CD@cis.upenn.edu> Message-ID: You're correct. Please forget that name. On Jan 25, 2016 12:33 PM, "wren romano" wrote: > On Mon, Jan 25, 2016 at 7:34 AM, Richard Eisenberg > wrote: > > But I suggest a different name. Ground? Terminating? NormalForm? > Irreducible? ValueType? I don't love any of these, but I love Sane less. > > I'm also strongly opposed to using "sane". That name is ableist and > quite offputting to many Haskellers I know (myself included). To say > nothing of the fact that the name doesn't provide any useful > understanding of what precisely it's supposed to be categorizing. > > -- > Live well, > ~wren > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrey.mokhov at newcastle.ac.uk Mon Jan 25 19:32:32 2016 From: andrey.mokhov at newcastle.ac.uk (Andrey Mokhov) Date: Mon, 25 Jan 2016 19:32:32 +0000 Subject: [ANNOUNCE] Shaking up GHC In-Reply-To: <9c0cbf832813492aae0828fdf172f02c@DB4PR30MB030.064d.mgd.msft.net> References: <9c0cbf832813492aae0828fdf172f02c@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Simon, > As I understand it, it can work side-by-side with the existing build > system, correct? That means we don't need to make an either/or > choice, which is very helpful. That's correct. Note though that the two build systems put (some) build results in the same directories, e.g. inplace/bin/ghc-stage1, so there is some interaction between them. In future it would be possible to decouple them completely (if need be). > How can I do that using Shake to build? Maybe > sh validate --shake --fast --no-clean > or something? Just modifying the validate script to make it > convenient to use shake for the build part would be great. This may be possible precisely because binaries are where validate expects them to be. I tried to pull this off, but unsuccessfully so far (validate starts rebuilding everything from scratch with make). I think the reason is that we changed some naming conventions for directories (using stageN instead of dist, dist-boot, dist-install), so validate can't find some utils. I'll let you know if I find a workaround. Otherwise we'll just have to wait for the proper implementation of the "test" target in the new build system. Maybe it's not too difficult to implement. Ben, > > But User.hs is a source file, which we shouldn't normally modify lest > > we accidentally commit it. Could we have a non-source file to modify > > (rather like build.mk being based on build.mk.sample) > > > One way around this would be to add User.hs to .gitignore. That way git > will ignore changes to this files when you `git commit -a`. You can still, > however, commit changes to it if you ask git explicitly. Yes, I was thinking about the same idea. Cheers, Andrey -----Original Message----- From: Simon Peyton Jones [mailto:simonpj at microsoft.com] Sent: 25 January 2016 12:14 To: Andrey Mokhov ; ghc-devs at haskell.org Cc: Neil Mitchell ; Simon Marlow Subject: RE: [ANNOUNCE] Shaking up GHC Very good. As I understand it, it can work side-by-side with the existing build system, correct? That means we don't need to make an either/or choice, which is very helpful. Every day I do sh validate --fast --no-clean How can I do that using Shake to build? Maybe sh validate --shake --fast --no-clean or something? Just modifying the validate script to make it convenient to use shake for the build part would be great. You say: The make-based build system uses mk/build.mk to specify user build settings. We use src/Settings/User.hs for the same purpose. Feel free to experiment following the Haddock comments. But User.hs is a source file, which we shouldn't normally modify lest we accidentally commit it. Could we have a non-source file to modify (rather like build.mk being based on build.mk.sample) Simon | -----Original Message----- | From: Andrey Mokhov [mailto:andrey.mokhov at newcastle.ac.uk] | Sent: 22 January 2016 14:27 | To: ghc-devs at haskell.org | Cc: Simon Peyton Jones ; Neil Mitchell | ; Simon Marlow | Subject: [ANNOUNCE] Shaking up GHC | | Dear GHC developers, | | I am happy to announce that the Shaking up GHC project has finally | reached the first milestone. The goal of the project is to design a | new GHC build system based on Shake that will eventually replace the | current make-based one. See the project page for more details: | https://github.com/snowleopard/shaking-up-ghc. | | There is still a long way until we can match the capabilities of the | current build system. At the moment we only build vanilla way. | Validation, documentation, build flavours and cross-compilation are | not yet implemented. Known limitations are listed here: | https://github.com/snowleopard/shaking-up-ghc#current-limitations. | | The purpose of this announcement is to attract alpha testers and | collect early feedback across multiple platforms and build | configurations. We already have several success reports on Linux, OS | X, Solaris and Windows. However, things will inevitably break and we | hope to catch and fix as many of these cases as possible with your | help. The instructions on how to try the new build system can be found | here: https://github.com/snowleopard/shaking-up-ghc#your-first-build. | | We plan to be ready to become a part of the GHC tree around 1 March | 2016, and catch up with the make build system around 1 June 2016. The | dates are tentative and depend on how much time it takes us to resolve | the remaining issues: https://github.com/snowleopard/shaking-up- | ghc/milestones. | | I would like thank everyone who contributed to this project so far: | Simon Peyton Jones, Neil Mitchell and Simon Marlow came up with the | idea and guided me throughout the project; Moritz Angermann, Ben | Gamari, Karel Gardas, David Luposchainsky, and Neil Mitchell | contributed to the codebase. Thank you all! | | Kind regards, | Andrey From simonpj at microsoft.com Tue Jan 26 08:54:40 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 26 Jan 2016 08:54:40 +0000 Subject: [ANNOUNCE] Shaking up GHC In-Reply-To: References: <9c0cbf832813492aae0828fdf172f02c@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <778fc21afb044e9fb8224d9e55a0b25f@DB4PR30MB030.064d.mgd.msft.net> | That's correct. Note though that the two build systems put (some) | build results in the same directories, e.g. inplace/bin/ghc-stage1, so | there is some interaction between them. In future it would be possible | to decouple them completely (if need be). Documenting this side-by-side possibility on the home page would be very helpful to up-take. | > How can I do that using Shake to build? Maybe | > sh validate --shake --fast --no-clean | > or something? Just modifying the validate script to make it | >convenient to use shake for the build part would be great. | | This may be possible precisely because binaries are where validate | expects them to be. I tried to pull this off, but unsuccessfully so | far (validate starts rebuilding everything from scratch with make). I | think the reason is that we changed some naming conventions for | directories (using stageN instead of dist, dist-boot, dist-install), | so validate can't find some utils. I'll let you know if I find a | workaround. Why not just make the 'validate' script invoke the shake build system (instead of 'make') when you say 'sh validate --shake'? That would be simple, wouldn't it? So shake builds GHC, and then 'validate' invokes 'make test' (or whatever) to run the testsuite. Little things like this would significantly increase uptake I think! Simon | | Ben, | | > > But User.hs is a source file, which we shouldn't normally modify | > > lest we accidentally commit it. Could we have a non-source file to | > > modify (rather like | > > | https://na01.safelinks.protection.outlook.com/?url=build.mk&data=01% | > > | 7c01%7csimonpj%40064d.mgd.microsoft.com%7c7f0edcff3c78490bd0e808d325 | > > | be4774%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=8L%2b7QWlhbAwUnY | > > fAfCEwTXTC2PUMd17m1ceCcD2TE%2fU%3d being based on build.mk.sample) | > > | > One way around this would be to add User.hs to .gitignore. That way | > git will ignore changes to this files when you `git commit -a`. You | > can still, however, commit changes to it if you ask git explicitly. | | Yes, I was thinking about the same idea. | | Cheers, | Andrey | | -----Original Message----- | From: Simon Peyton Jones [mailto:simonpj at microsoft.com] | Sent: 25 January 2016 12:14 | To: Andrey Mokhov ; ghc- | devs at haskell.org | Cc: Neil Mitchell ; Simon Marlow | | Subject: RE: [ANNOUNCE] Shaking up GHC | | Very good. | | As I understand it, it can work side-by-side with the existing build | system, correct? That means we don't need to make an either/or | choice, which is very helpful. | | Every day I do | sh validate --fast --no-clean | How can I do that using Shake to build? Maybe | sh validate --shake --fast --no-clean | or something? Just modifying the validate script to make it | convenient to use shake for the build part would be great. | | You say: The make-based build system uses mk/build.mk to specify user | build settings. We use src/Settings/User.hs for the same purpose. Feel | free to experiment following the Haddock comments. | | But User.hs is a source file, which we shouldn't normally modify lest | we accidentally commit it. Could we have a non-source file to modify | (rather like | https://na01.safelinks.protection.outlook.com/?url=build.mk&data=01%7c | 01%7csimonpj%40064d.mgd.microsoft.com%7c7f0edcff3c78490bd0e808d325be47 | 74%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=8L%2b7QWlhbAwUnYfAfCEw | TXTC2PUMd17m1ceCcD2TE%2fU%3d being based on build.mk.sample) | | Simon | | | -----Original Message----- | | From: Andrey Mokhov [mailto:andrey.mokhov at newcastle.ac.uk] | | Sent: 22 January 2016 14:27 | | To: ghc-devs at haskell.org | | Cc: Simon Peyton Jones ; Neil Mitchell | | ; Simon Marlow | | Subject: [ANNOUNCE] Shaking up GHC | | | | Dear GHC developers, | | | | I am happy to announce that the Shaking up GHC project has finally | | reached the first milestone. The goal of the project is to design a | | new GHC build system based on Shake that will eventually replace the | | current make-based one. See the project page for more details: | | https://github.com/snowleopard/shaking-up-ghc. | | | | There is still a long way until we can match the capabilities of | the | | current build system. At the moment we only build vanilla way. | | Validation, documentation, build flavours and cross-compilation are | | not yet implemented. Known limitations are listed here: | | https://github.com/snowleopard/shaking-up-ghc#current-limitations. | | | | The purpose of this announcement is to attract alpha testers and | | collect early feedback across multiple platforms and build | | configurations. We already have several success reports on Linux, OS | | X, Solaris and Windows. However, things will inevitably break and we | | hope to catch and fix as many of these cases as possible with your | | help. The instructions on how to try the new build system can be | found | | here: https://github.com/snowleopard/shaking-up-ghc#your-first- | build. | | | | We plan to be ready to become a part of the GHC tree around 1 March | | 2016, and catch up with the make build system around 1 June 2016. | The | | dates are tentative and depend on how much time it takes us to | resolve | | the remaining issues: https://github.com/snowleopard/shaking-up- | | ghc/milestones. | | | | I would like thank everyone who contributed to this project so far: | | Simon Peyton Jones, Neil Mitchell and Simon Marlow came up with the | | idea and guided me throughout the project; Moritz Angermann, Ben | | Gamari, Karel Gardas, David Luposchainsky, and Neil Mitchell | | contributed to the codebase. Thank you all! | | | | Kind regards, | | Andrey From marlowsd at gmail.com Tue Jan 26 10:33:45 2016 From: marlowsd at gmail.com (Simon Marlow) Date: Tue, 26 Jan 2016 10:33:45 +0000 Subject: [ANNOUNCE] Shaking up GHC In-Reply-To: References: <87vb6kkyly.fsf@gmail.com> Message-ID: On 23 January 2016 at 21:17, Andrey Mokhov wrote: > Herbert, > > > I think it's already quite convenient. After all, you're expected to > > have a minimum GHC bootstrapping environment anyway. So having the > > tools installed (as already do now, e.g. you need alex, happy, and > > ghc to be able to work on GHC). > > I agree. Roughly, we are talking about going from: > > cabal install alex happy > > to: > > cabal install alex happy ansi-terminal mtl shake QuickCheck > It likely won't be that simple due to versioning issues. It's entirely possible that GHC will work only with certain versions of some of these libraries (and not necessarily the latest ones), so the build may fail at certain times and under certain conditions for some users. The configure script will already have to check for compatible versions, like it does for alex/happy. That's the reason we bundle things, it reduces the possibility for failure. It's a complicated tradeoff, but if the GHC build system became tightly coupled to Shake in the way that it is with Cabal, then bundling would probably be the right thing to do. Cheers, Simon > This doesn't look too onerous (although one could also consider > somehow packaging these dependencies together). And hopefully > upcoming cabal features will make this more robust. > > Tuncer, > > > My suggestion, and what I'd expect, is to make Shake part of > > GHC's included lib, just like process or xhtml. > > This sounds like a very big decision which is beyond the Shaking > up GHC project. (I wouldn't want to shake up GHC too much!) > > Cheers, > Andrey > > > -----Original Message----- > > From: Herbert Valerio Riedel [mailto:hvriedel at gmail.com] > > Sent: 23 January 2016 17:14 > > To: Andrey Mokhov > > Cc: dluposchainsky at googlemail.com; GHC developers > > Subject: Re: [ANNOUNCE] Shaking up GHC > > > > On 2016-01-23 at 14:05:56 +0100, Andrey Mokhov wrote: > > >> Are there any plans as to how to include it in the GHC tree? Does it > > >> ship with all the libraries required to build the build system, will > > we > > >> have a mini-build system to bootstrap it? If I recall correctly, we > > rely > > >> on Cabal sandboxes on Linux/OSX and global Cabal library > > >> installations on Windows in order to run it. > > > > > > The simplest way is to add the 'shake-build' folder to the GHC tree > > and > > > ask first adopters of the new build system to globally install the > > > dependencies (ansi-terminal, mtl, shake, QuickCheck). Then 'build.sh' > > > and 'build.bat' scripts should work. > > > > > > I am open to suggestions on how to make this more convenient and > > > robust. I've never used anything more advanced than a global cabal > > > installation, so I'd appreciate input from more experienced users. > > > > I think it's already quite convenient. After all, you're expected to > > have a minimum GHC bootstrapping environment anyway. So having the > > tools > > installed (as already do now, e.g. you need alex, happy, and ghc to be > > able to work on GHC). > > > > And the new cabal nix-store feature to show-case as tech-preview > > together with GHC 8.0 makes this even more robust by avoiding pkg-db > > breakages due to reinstalls, which would be the main reason not to > > rely on "global installed dependency". > > > > The shake-build.sh script simply needs to invoke `cabal new-build` to > > generate the ghc shake build-tool executable. > _______________________________________________ > 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: From simonpj at microsoft.com Tue Jan 26 10:55:08 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 26 Jan 2016 10:55:08 +0000 Subject: Substitutions Message-ID: <6f775f0124cc489f8ea14554173f4677@DB4PR30MB030.064d.mgd.msft.net> Bartosz How are you getting on with tidying up substitutions. I?ve done a bit in that direction myself: commit 1c6d70c2121fd1126fcc2458bdbcc856e19598c2 Author: Simon Peyton Jones > Date: Tue Jan 26 09:37:06 2016 +0000 Kill off zipTopTCvSubst in favour of zipOpenTCvSubst But there is more to do. In particular, I note that substTys is not checked ? but neither is it called substTysUnchecked. It should be! That will show up a bunch more cases, I think. Another particular thing, arising from my patch, is that we can now do some renaming ? zipOpenTCvSubst -> zipTvSubst (It only deals with tyvars) ? zipOpenTCvSubstCoVars -> zipCvSubst (it only deals with covars) ? zipOpenTCvSubstBinders -> zipTyBinderSubst (it only deals with TyBinders, not covars) I guess you?ll want to do similar things for the ?mk? variants. Anyway: good for you! Let me know if you need help. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From niteria at gmail.com Tue Jan 26 11:14:40 2016 From: niteria at gmail.com (Bartosz Nitka) Date: Tue, 26 Jan 2016 11:14:40 +0000 Subject: Substitutions In-Reply-To: <6f775f0124cc489f8ea14554173f4677@DB4PR30MB030.064d.mgd.msft.net> References: <6f775f0124cc489f8ea14554173f4677@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Hello Simon, I was about to send an improved version of D1801, I will do that once I rebase past your patch (there's a small overlap with what I've done). D1820 is ready for review. I have a patch coming for piResultTys [1] where the FVs of ty are not in the in_scope set. I've also looked at a similar problem in lint_app [2], but the fix I have is a bit awkward, so I will probably need some input from you. Both of them are blocking #11360 and I want to get it unblocked as soon as possible to continue determinism work. I'm aware of substTys being currently unchecked, I didn't want to introduce substTysUnchecked just yet, as there already are more than 30 occurrences of substTyUnchecked. But maybe I should push uncheckedness as far up as possible, do you think it's worth to do it now? Do you want me to do the renaming? Cheers, Bartosz [1] https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/types/Type.hs;016a0bd1ba129134dfa612db0d96e01644fa7b9f$803-804 [2] https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/coreSyn/CoreLint.hs;016a0bd1ba129134dfa612db0d96e01644fa7b9f$1134 2016-01-26 10:55 GMT+00:00 Simon Peyton Jones : > Bartosz > > How are you getting on with tidying up substitutions. > > I?ve done a bit in that direction myself: > > commit 1c6d70c2121fd1126fcc2458bdbcc856e19598c2 > > Author: Simon Peyton Jones > > Date: Tue Jan 26 09:37:06 2016 +0000 > > > > Kill off zipTopTCvSubst in favour of zipOpenTCvSubst > > But there is more to do. > > In particular, I note that * substTys is not checked* ? but neither is it > called substTysUnchecked. It should be! That will show up a bunch more > cases, I think. > > Another particular thing, arising from my patch, is that *we can now do > some renaming* > > ? zipOpenTCvSubst -> zipTvSubst (It only deals with tyvars) > > ? zipOpenTCvSubstCoVars -> zipCvSubst (it only deals with > covars) > > ? zipOpenTCvSubstBinders -> zipTyBinderSubst (it only deals > with TyBinders, not covars) > > I guess you?ll want to do similar things for the ?mk? variants. > > Anyway: good for you! Let me know if you need help. > > Simon > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Jan 26 11:58:51 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 26 Jan 2016 11:58:51 +0000 Subject: Substitutions In-Reply-To: References: <6f775f0124cc489f8ea14554173f4677@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <07d75bb24bfd47868df135cfe00f4c0d@DB4PR30MB030.064d.mgd.msft.net> I'm aware of substTys being currently unchecked, I didn't want to introduce substTysUnchecked just yet, as there already are more than 30 occurrences of substTyUnchecked. But maybe I should push uncheckedness as far up as possible, do you think it's worth to do it now? Well, it?s just as much a source of potential bugs as substTy. So yes, I?d make all the calls to substTysUnchecked, and then work through getting rid of them. Many of them will be simple. Do you want me to do the renaming? yes please Pls yell specifically when you need help; don?t rely on me seeing Phab patches S From: Bartosz Nitka [mailto:niteria at gmail.com] Sent: 26 January 2016 11:15 To: Simon Peyton Jones Cc: ghc-devs at haskell.org Subject: Re: Substitutions Hello Simon, I was about to send an improved version of D1801, I will do that once I rebase past your patch (there's a small overlap with what I've done). D1820 is ready for review. I have a patch coming for piResultTys [1] where the FVs of ty are not in the in_scope set. I've also looked at a similar problem in lint_app [2], but the fix I have is a bit awkward, so I will probably need some input from you. Both of them are blocking #11360 and I want to get it unblocked as soon as possible to continue determinism work. I'm aware of substTys being currently unchecked, I didn't want to introduce substTysUnchecked just yet, as there already are more than 30 occurrences of substTyUnchecked. But maybe I should push uncheckedness as far up as possible, do you think it's worth to do it now? Do you want me to do the renaming? Cheers, Bartosz [1] https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/types/Type.hs;016a0bd1ba129134dfa612db0d96e01644fa7b9f$803-804 [2] https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/coreSyn/CoreLint.hs;016a0bd1ba129134dfa612db0d96e01644fa7b9f$1134 2016-01-26 10:55 GMT+00:00 Simon Peyton Jones >: Bartosz How are you getting on with tidying up substitutions. I?ve done a bit in that direction myself: commit 1c6d70c2121fd1126fcc2458bdbcc856e19598c2 Author: Simon Peyton Jones > Date: Tue Jan 26 09:37:06 2016 +0000 Kill off zipTopTCvSubst in favour of zipOpenTCvSubst But there is more to do. In particular, I note that substTys is not checked ? but neither is it called substTysUnchecked. It should be! That will show up a bunch more cases, I think. Another particular thing, arising from my patch, is that we can now do some renaming ? zipOpenTCvSubst -> zipTvSubst (It only deals with tyvars) ? zipOpenTCvSubstCoVars -> zipCvSubst (it only deals with covars) ? zipOpenTCvSubstBinders -> zipTyBinderSubst (it only deals with TyBinders, not covars) I guess you?ll want to do similar things for the ?mk? variants. Anyway: good for you! Let me know if you need help. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Jan 26 15:34:57 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 26 Jan 2016 15:34:57 +0000 Subject: GHC release candidate Message-ID: <718fc1d42461479fb954d89d337dac42@DB4PR30MB030.064d.mgd.msft.net> George, Richard, Geoff We?d like to get a new release candidate for GHC out on Friday 5th Feb. Does that give you enough post-POPL time to get done? ? George: The pattern match performance issues ? Richard: the ReturnTv stuff (branch wip/exp-types) ? Richard: #11471 (levity) ? Richard: documentation for TypeInType ? Geoff: #11487 ? Simon PJ: #11339 Richard, also if you look at https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1 you can see ?highest? priority tickets with you as owner, that are to do with TypeInType and TypeApplications. Thanks Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From mainland at apeiron.net Tue Jan 26 15:43:06 2016 From: mainland at apeiron.net (Geoffrey Mainland) Date: Tue, 26 Jan 2016 10:43:06 -0500 Subject: GHC release candidate In-Reply-To: <718fc1d42461479fb954d89d337dac42@DB4PR30MB030.064d.mgd.msft.net> References: <718fc1d42461479fb954d89d337dac42@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <56A7940A.4040707@apeiron.net> I will try, but that's a bit tight for #11487---less than two weeks from initial report to required fix, and I am teaching 3 courses this term. Given that this bug has been dormant for 3.5 years, one might question why it is suddenly of the "highest" priority :) Cheers, Geoff On 01/26/2016 10:34 AM, Simon Peyton Jones wrote: > > George, Richard, Geoff > > We?d like to get a new release candidate for GHC out on Friday 5^th > Feb. Does that give you enough post-POPL time to get done? > > ? *George*: The pattern match performance issues > > ? *Richard*: the ReturnTv stuff (branch wip/exp-types) > > ? *Richard*: #11471 (levity) > > ? *Richard*: documentation for TypeInType > > ? *Geoff*: #11487 > > ? *Simon PJ*: #11339 > > *Richard*, also if you look at > https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1 you can see > ?highest? priority tickets with you as owner, that are to do with > TypeInType and TypeApplications. > > Thanks > > Simon > From simonpj at microsoft.com Tue Jan 26 16:18:01 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 26 Jan 2016 16:18:01 +0000 Subject: GHC release candidate In-Reply-To: <56A7940A.4040707@apeiron.net> References: <718fc1d42461479fb954d89d337dac42@DB4PR30MB030.064d.mgd.msft.net> <56A7940A.4040707@apeiron.net> Message-ID: | Given that this bug has been dormant for 3.5 years, one might question | why it is suddenly of the "highest" priority :) Only that (a) it's a seg-fault, and (b) it seems easy to fix, and most important (c) you kindly volunteered to produce a patch in a week. If you can't, fair enough, so be it. We can push it out to 8.2. Or maybe someone else (Reid?) might do it. So feel free to un-volunteer! Simon | -----Original Message----- | From: Geoffrey Mainland [mailto:mainland at apeiron.net] | Sent: 26 January 2016 15:43 | To: Simon Peyton Jones ; Skull | ; Richard Eisenberg | Cc: ghc-devs at haskell.org | Subject: Re: GHC release candidate | | I will try, but that's a bit tight for #11487---less than two weeks | from initial report to required fix, and I am teaching 3 courses this | term. | | Given that this bug has been dormant for 3.5 years, one might question | why it is suddenly of the "highest" priority :) | | Cheers, | Geoff | | On 01/26/2016 10:34 AM, Simon Peyton Jones wrote: | > | > George, Richard, Geoff | > | > We?d like to get a new release candidate for GHC out on Friday 5^th | > Feb. Does that give you enough post-POPL time to get done? | > | > ? *George*: The pattern match performance issues | > | > ? *Richard*: the ReturnTv stuff (branch wip/exp-types) | > | > ? *Richard*: #11471 (levity) | > | > ? *Richard*: documentation for TypeInType | > | > ? *Geoff*: #11487 | > | > ? *Simon PJ*: #11339 | > | > *Richard*, also if you look at | > https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1 you can see | > ?highest? priority tickets with you as owner, that are to do with | > TypeInType and TypeApplications. | > | > Thanks | > | > Simon | > From ben at well-typed.com Tue Jan 26 17:00:24 2016 From: ben at well-typed.com (Ben Gamari) Date: Tue, 26 Jan 2016 18:00:24 +0100 Subject: vectorisation code? In-Reply-To: <56A25776.20403@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> <87io2lg3x4.fsf@smart-cactus.org> <56A239DF.4070006@apeiron.net> <20160122145759.GA7974@apeiron.net> <3541c1a536d24f5794e432150833b428@DB4PR30MB030.064d.mgd.msft.net> <56A25776.20403@apeiron.net> Message-ID: <878u3ce0nr.fsf@smart-cactus.org> Geoffrey Mainland writes: > I didn't mean to suggest that DPH should be part of every build, just > that it should be part of *some* regular build. > > If we're willing to do that, then I'm certainly willing to get DPH back > up and running. > 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From mainland at apeiron.net Tue Jan 26 17:06:53 2016 From: mainland at apeiron.net (Geoffrey Mainland) Date: Tue, 26 Jan 2016 12:06:53 -0500 Subject: vectorisation code? In-Reply-To: <878u3ce0nr.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> <87io2lg3x4.fsf@smart-cactus.org> <56A239DF.4070006@apeiron.net> <20160122145759.GA7974@apeiron.net> <3541c1a536d24f5794e432150833b428@DB4PR30MB030.064d.mgd.msft.net> <56A25776.20403@apeiron.net> <878u3ce0nr.fsf@smart-cactus.org> Message-ID: <56A7A7AD.6030105@apeiron.net> On 01/26/2016 12:00 PM, Ben Gamari wrote: > Geoffrey Mainland writes: > >> I didn't mean to suggest that DPH should be part of every build, just >> that it should be part of *some* regular build. >> >> If we're willing to do that, then I'm certainly willing to get DPH back >> up and running. >> > 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. Cheers, Geoff From joehillen at gmail.com Tue Jan 26 17:31:41 2016 From: joehillen at gmail.com (Joe Hillenbrand) Date: Tue, 26 Jan 2016 09:31:41 -0800 Subject: [ANNOUNCE] Shaking up GHC In-Reply-To: References: <87vb6kkyly.fsf@gmail.com> Message-ID: > > cabal install alex happy ansi-terminal mtl shake QuickCheck >> > > It likely won't be that simple due to versioning issues. It's entirely > possible that GHC will work only with certain versions of some of these > libraries (and not necessarily the latest ones), so the build may fail at > certain times and under certain conditions for some users. This is exactly why I added build.stack.sh to shaking-up-ghc, to mitigate these kinds of issues. https://github.com/snowleopard/shaking-up-ghc/blob/master/build.stack.sh Personally, I think the shake build system should default to stack because it is the best way to get consistent builds. On Tue, Jan 26, 2016 at 2:33 AM, Simon Marlow wrote: > > > On 23 January 2016 at 21:17, Andrey Mokhov > wrote: > >> Herbert, >> >> > I think it's already quite convenient. After all, you're expected to >> > have a minimum GHC bootstrapping environment anyway. So having the >> > tools installed (as already do now, e.g. you need alex, happy, and >> > ghc to be able to work on GHC). >> >> I agree. Roughly, we are talking about going from: >> >> cabal install alex happy >> >> to: >> >> cabal install alex happy ansi-terminal mtl shake QuickCheck >> > > It likely won't be that simple due to versioning issues. It's entirely > possible that GHC will work only with certain versions of some of these > libraries (and not necessarily the latest ones), so the build may fail at > certain times and under certain conditions for some users. The configure > script will already have to check for compatible versions, like it does for > alex/happy. That's the reason we bundle things, it reduces the possibility > for failure. > > It's a complicated tradeoff, but if the GHC build system became tightly > coupled to Shake in the way that it is with Cabal, then bundling would > probably be the right thing to do. > > Cheers, > Simon > > >> This doesn't look too onerous (although one could also consider >> somehow packaging these dependencies together). And hopefully >> upcoming cabal features will make this more robust. >> >> Tuncer, >> >> > My suggestion, and what I'd expect, is to make Shake part of >> > GHC's included lib, just like process or xhtml. >> >> This sounds like a very big decision which is beyond the Shaking >> up GHC project. (I wouldn't want to shake up GHC too much!) >> >> Cheers, >> Andrey >> >> > -----Original Message----- >> > From: Herbert Valerio Riedel [mailto:hvriedel at gmail.com] >> > Sent: 23 January 2016 17:14 >> > To: Andrey Mokhov >> > Cc: dluposchainsky at googlemail.com; GHC developers >> > Subject: Re: [ANNOUNCE] Shaking up GHC >> > >> > On 2016-01-23 at 14:05:56 +0100, Andrey Mokhov wrote: >> > >> Are there any plans as to how to include it in the GHC tree? Does it >> > >> ship with all the libraries required to build the build system, will >> > we >> > >> have a mini-build system to bootstrap it? If I recall correctly, we >> > rely >> > >> on Cabal sandboxes on Linux/OSX and global Cabal library >> > >> installations on Windows in order to run it. >> > > >> > > The simplest way is to add the 'shake-build' folder to the GHC tree >> > and >> > > ask first adopters of the new build system to globally install the >> > > dependencies (ansi-terminal, mtl, shake, QuickCheck). Then 'build.sh' >> > > and 'build.bat' scripts should work. >> > > >> > > I am open to suggestions on how to make this more convenient and >> > > robust. I've never used anything more advanced than a global cabal >> > > installation, so I'd appreciate input from more experienced users. >> > >> > I think it's already quite convenient. After all, you're expected to >> > have a minimum GHC bootstrapping environment anyway. So having the >> > tools >> > installed (as already do now, e.g. you need alex, happy, and ghc to be >> > able to work on GHC). >> > >> > And the new cabal nix-store feature to show-case as tech-preview >> > together with GHC 8.0 makes this even more robust by avoiding pkg-db >> > breakages due to reinstalls, which would be the main reason not to >> > rely on "global installed dependency". >> > >> > The shake-build.sh script simply needs to invoke `cabal new-build` to >> > generate the ghc shake build-tool executable. >> _______________________________________________ >> 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: From eir at cis.upenn.edu Wed Jan 27 04:43:58 2016 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Tue, 26 Jan 2016 23:43:58 -0500 Subject: GHC release candidate In-Reply-To: <718fc1d42461479fb954d89d337dac42@DB4PR30MB030.064d.mgd.msft.net> References: <718fc1d42461479fb954d89d337dac42@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <14A623BB-4329-41CB-AB5D-4D16ED75BFE2@cis.upenn.edu> On Jan 26, 2016, at 10:34 AM, Simon Peyton Jones wrote: > ? Richard: the ReturnTv stuff (branch wip/exp-types) > Yes. I just pushed a candidate patch that may well validate. I'll merge tomorrow (Wed) on success. > ? Richard: #11471 (levity) > This should hopefully be much easier than ExpTypes. Next Friday is a reasonable deadline. > ? Richard: documentation for TypeInType > Sure. > ? Geoff: #11487 > > ? Simon PJ: #11339 > > Richard, also if you look at https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1 you can see ?highest? priority tickets with you as owner, that are to do with TypeInType and TypeApplications. > There's a bunch here. Believe me -- I'm working as fast as I can to wrap up these bugs. Unfortunately, our release cycle overlaps with the critical time for the academic job market, so GHC is competing with my need to get a job. If anyone reading this wants to offer me a job, that could indeed have a tangible effect on how quickly I scoop up these bugs! :) Richard > Thanks > > Simon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed Jan 27 09:30:08 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 27 Jan 2016 09:30:08 +0000 Subject: GHC release candidate In-Reply-To: <14A623BB-4329-41CB-AB5D-4D16ED75BFE2@cis.upenn.edu> References: <718fc1d42461479fb954d89d337dac42@DB4PR30MB030.064d.mgd.msft.net> <14A623BB-4329-41CB-AB5D-4D16ED75BFE2@cis.upenn.edu> Message-ID: There's a bunch here. Believe me -- I'm working as fast as I can to wrap up these bugs. Indeed! And believe me, we are grateful, both to you and other huge contributors. GHC is a pretty big enterprise. The intention is not to pile on pressure, but rather to share information. . No one is asking you to turn into superman/superwoman. It?s just that are many people working together, so sharing info about what can and cannot get done by date X is helpful. No more than that! Simon From: Richard Eisenberg [mailto:eir at cis.upenn.edu] Sent: 27 January 2016 04:44 To: Simon Peyton Jones Cc: Skull ; Geoffrey Mainland ; ghc-devs at haskell.org Subject: Re: GHC release candidate On Jan 26, 2016, at 10:34 AM, Simon Peyton Jones > wrote: ? Richard: the ReturnTv stuff (branch wip/exp-types) Yes. I just pushed a candidate patch that may well validate. I'll merge tomorrow (Wed) on success. ? Richard: #11471 (levity) This should hopefully be much easier than ExpTypes. Next Friday is a reasonable deadline. ? Richard: documentation for TypeInType Sure. ? Geoff: #11487 ? Simon PJ: #11339 Richard, also if you look at https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1 you can see ?highest? priority tickets with you as owner, that are to do with TypeInType and TypeApplications. There's a bunch here. Believe me -- I'm working as fast as I can to wrap up these bugs. Unfortunately, our release cycle overlaps with the critical time for the academic job market, so GHC is competing with my need to get a job. If anyone reading this wants to offer me a job, that could indeed have a tangible effect on how quickly I scoop up these bugs! :) Richard Thanks Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Wed Jan 27 11:34:40 2016 From: ben at well-typed.com (Ben Gamari) Date: Wed, 27 Jan 2016 12:34:40 +0100 Subject: GHC 8.0.1 plans Message-ID: <874mdzdzn3.fsf@smart-cactus.org> tl;dr: The march towards 8.0.1 continues. Release candidate 2 will likely be cut late next week. If you have a ticket which you'd like to see addressed but suspect we aren't working on then please say so. Hello again GHC-ers, As you likely know, we are currently in the stabilization period of GHC's 8.0.1 release. Release candidate 1 has been out for nearly two weeks now and issues have been steadily trickling in. The problems we've heard about thusfar have largely fallen into a few broad categories, * OS X linker issues due to botched preparation of the first binary distribution (#11423) * pattern match checker performance. These we largely knew about prior to the release, although it has been surprising to see how easily one can wander into the new checker's performance abyss. (#11374, #11276, #11163, #11302, #11303, #11195) * Regressions due to visible type applications (#11329, #11458) * Issues uncovered by generalizations allowed under TypeInType (#11429, #11334, #11473, #11405, #11407, #11399) * Trouble caused by new warnings (#11370, #11316, #11474) Since the release, there has been significant progress on many of these fronts: * George Karachalias has been hard at work further improving the pattern checker. The result should have far more predictable performance characteristics at less cost in reasoning power. * Simon Peyton Jones has been squashing bugs at a furious rate, including a variety of long-standing issues (#11248, #11330 and many others) * Tamar Christina has added support for remote GHCi on Windows and resolved a long-standing linking issue (#11223, #11100) * A variety of limitations in our implementation of Typeable have been fixed (#11120) although there is still more to be done (#11334). * InjectiveTypeFamilies has been renamed to TypeFamiliesDependencies * Custom type errors are now more robust (#11391) * We now have a more conservative default warning set, as well as better mechanisms for managing warning changes in the future. (#11429, #11370) * A wide variety of miscellaneous bug-fixes have also been merged. Given how much progress has been made, we approaching the point where we can begin planning the next candidate. At this point the plan is to wait until we have landed George's pattern checker rework, as this has been one of the more visible issues in practice. This may be merged as early as the latter half of next week. If this happens then we hope to have the next release candidate out late next week. In the interim we will continue to work on paring down the bug list, focusing on the highest priority tickets listed on the 8.0.1 status page. In particular, those with owners are most likely to be dealt with soon. If you see a ticket which you would like to see addressed in 8.0.1 but is unowned or lower than "highest" priority, please bring this to our attention. Given the large amount of churn still being felt in the `ghc-8.0` branch (with over 150 comments in the two weeks since -rc1) and the size of some of the patches that have yet to land, it's unclear whether two release candidates will be sufficient to ensure the stability of the branch. Consequently, unless -rc2 yields a particularly small number of new tickets it's likely that it will be followed by a third candidate before the release. As always, let us know if you have any questions or concerns about the release process. Thanks to everyone who has contributed to -rc1! Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From ky3 at atamo.com Wed Jan 27 12:51:11 2016 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Wed, 27 Jan 2016 19:51:11 +0700 Subject: GHC 8.0.1 plans In-Reply-To: <874mdzdzn3.fsf@smart-cactus.org> References: <874mdzdzn3.fsf@smart-cactus.org> Message-ID: On Wed, Jan 27, 2016 at 6:34 PM, Ben Gamari wrote: > tl;dr: The march towards 8.0.1 continues. Release candidate 2 will likely > be cut late next week. If you have a ticket which you'd like to > see addressed but suspect we aren't working on then please say so. > Dear Ben, I think this email has a lot of useful info for *users* too, not just ghc devs. Might it not be a good idea to keep glasgow-haskell-users in the loop for future announcements of this sort? -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Wed Jan 27 13:02:05 2016 From: ben at well-typed.com (Ben Gamari) Date: Wed, 27 Jan 2016 14:02:05 +0100 Subject: GHC 8.0.1 plans In-Reply-To: References: <874mdzdzn3.fsf@smart-cactus.org> Message-ID: <87si1jch0y.fsf@smart-cactus.org> Kim-Ee Yeoh writes: > On Wed, Jan 27, 2016 at 6:34 PM, Ben Gamari wrote: > >> tl;dr: The march towards 8.0.1 continues. Release candidate 2 will likely >> be cut late next week. If you have a ticket which you'd like to >> see addressed but suspect we aren't working on then please say so. >> > > Dear Ben, I think this email has a lot of useful info for *users* too, not > just ghc devs. > > Might it not be a good idea to keep glasgow-haskell-users in the loop for > future announcements of this sort? > Indeed, I should have included -users as well. Thanks for the reminder! Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From eric at seidel.io Wed Jan 27 18:16:14 2016 From: eric at seidel.io (Eric Seidel) Date: Wed, 27 Jan 2016 10:16:14 -0800 Subject: CallStack naming In-Reply-To: References: <96F502AD-4AC6-40FA-BD9C-C9C063C2DDE0@cis.upenn.edu> <659dc968669143e0972602a72fb7753e@DB4PR30MB030.064d.mgd.msft.net> <1453305947.1797061.497600914.32732A90@webmail.messagingengine.com> <13f3ddc1d01a4f46ac15a051cc8ff049@DB4PR30MB030.064d.mgd.msft.net> <1453310647.1815559.497698170.68A46486@webmail.messagingengine.com> <1453367951.23159.6.camel@joachim-breitner.de> Message-ID: <1453918574.415584.504305722.15570A0D@webmail.messagingengine.com> On Thu, Jan 21, 2016, at 04:07, Simon Peyton Jones wrote: > | It?d probably need a built-in function > | > | setCallStack :: CallStack -> (AppendsCallStack => a) -> a > > Correct. This is easy to write in Core but not in Haskell. Ugh, I just realized that we can't write setCallStack (with implicit parameters) in Haskell either. Well, we can, but it adds an entry to the stack.. Why? Let's look at the implementation setCallStack :: CallStack -> (HasCallStack => a) -> a setCallStack stk do_this = let ?callStack = stk in do_this Rebinding ?callStack works just fine, but the occurrence of do_this causes GHC to push an entry onto the stack, which is less than ideal. What does this look like in practice? If we evaluate setCallStack foo (error "die") the resulting stack will be error *do_this* foo The rebinding trick works for withFrozenCallStack precisely because we freeze the CallStack, so the push from do_this is ignored. So, long story short, I'm not convinced of the utility of setCallStack. I think perhaps we should not provide it, and just do the rebinding trick inside withFrozenCallStack (which was the only use-case for setCallStack to begin with). From rwbarton at gmail.com Wed Jan 27 19:50:37 2016 From: rwbarton at gmail.com (Reid Barton) Date: Wed, 27 Jan 2016 14:50:37 -0500 Subject: Unexpected lack of change in ghcspeed results Message-ID: Hi Joachim, I was interested to see what effect the recent commit "Restore original alignment for info tables" (0dc7b36c) would have on performance. However, when I look at http://ghcspeed-nomeata.rhcloud.com/changes/?rev=0dc7b36c3c261b3eccf8460581fcd3d71f6e6ff6, I don't see the expected binary size increase (about 1%) that I got in local testing. Instead, the size increase appears to be attached to commit 0d92d9cb6d65fd00f9910c3f6f85bc6c68f5543b. I notice that these two commits, along with three others, were committed at exactly the same time (Wed Jan 27 11:32:15 2016 +0100), presumably in a rebase. Could this be confusing ghcspeed? Regards, Reid Barton -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Wed Jan 27 22:23:25 2016 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 27 Jan 2016 23:23:25 +0100 Subject: Unexpected lack of change in ghcspeed results In-Reply-To: References: Message-ID: <1453933405.1572.95.camel@joachim-breitner.de> Dear Reid, Am Mittwoch, den 27.01.2016, 14:50 -0500 schrieb Reid Barton: > I was interested to see what effect the recent commit "Restore > original alignment for info tables" (0dc7b36c) would have on > performance. However, when I look at http://ghcspeed-nomeata.rhcloud. > com/changes/?rev=0dc7b36c3c261b3eccf8460581fcd3d71f6e6ff6, I don't > see the expected binary size increase (about 1%) that I got in local > testing. Instead, the size increase appears to be attached to commit > 0d92d9cb6d65fd00f9910c3f6f85bc6c68f5543b. > > I notice that these two commits, along with three others, were > committed at exactly the same time (Wed Jan 27 11:32:15 2016 +0100), > presumably in a rebase. Could this be confusing ghcspeed? > heh, I?m surprised: Both that the ghcspeed server still runs, and that people are still using it :-) Indeed, you observe correctly, ghcspeed does not handle git rebases well. That was one of the reasons why I reimplemented the server from scratch. It now runs under perf.haskell.org, and there the expected changes are attributed to the right commit: https://perf.haskell.org/ghc/#revision/0dc7b36c3c261b3eccf8460581fcd3d71f6e6ff6 Is ghcspeed still linked somewhere, or was it an old bookmark from you that led you there? Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From rwbarton at gmail.com Wed Jan 27 22:35:18 2016 From: rwbarton at gmail.com (Reid Barton) Date: Wed, 27 Jan 2016 17:35:18 -0500 Subject: Unexpected lack of change in ghcspeed results In-Reply-To: <1453933405.1572.95.camel@joachim-breitner.de> References: <1453933405.1572.95.camel@joachim-breitner.de> Message-ID: Oh! I guess the name ghcspeed was too memorable... and browser bar autocompletion did the rest. Sorry for the noise! Regards, Reid Barton On Wed, Jan 27, 2016 at 5:23 PM, Joachim Breitner wrote: > Dear Reid, > > Am Mittwoch, den 27.01.2016, 14:50 -0500 schrieb Reid Barton: > > I was interested to see what effect the recent commit "Restore > > original alignment for info tables" (0dc7b36c) would have on > > performance. However, when I look at http://ghcspeed-nomeata.rhcloud. > > com/changes/?rev=0dc7b36c3c261b3eccf8460581fcd3d71f6e6ff6, I don't > > see the expected binary size increase (about 1%) that I got in local > > testing. Instead, the size increase appears to be attached to commit > > 0d92d9cb6d65fd00f9910c3f6f85bc6c68f5543b. > > > > I notice that these two commits, along with three others, were > > committed at exactly the same time (Wed Jan 27 11:32:15 2016 +0100), > > presumably in a rebase. Could this be confusing ghcspeed? > > > > heh, I?m surprised: Both that the ghcspeed server still runs, and that > people are still using it :-) > > Indeed, you observe correctly, ghcspeed does not handle git rebases > well. That was one of the reasons why I reimplemented the server from > scratch. It now runs under perf.haskell.org, and there the expected > changes are attributed to the right commit: > > https://perf.haskell.org/ghc/#revision/0dc7b36c3c261b3eccf8460581fcd3d71f6e6ff6 > > Is ghcspeed still linked somewhere, or was it an old bookmark from you > that led you there? > > Greetings, > Joachim > > -- > Joachim ?nomeata? Breitner > mail at joachim-breitner.de ? http://www.joachim-breitner.de/ > Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F > Debian Developer: nomeata at debian.org > > > _______________________________________________ > 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: From conal at conal.net Thu Jan 28 00:04:36 2016 From: conal at conal.net (Conal Elliott) Date: Wed, 27 Jan 2016 16:04:36 -0800 Subject: More aggressive dictionary removal? Message-ID: I'm looking for pointers on getting GHC to eliminate more overloading & polymorphism. I think this sort of thing mainly happens in the Specialise module. The default GHC flag settings get me a couple levels of monomorphization and dictionary removal, but I want to go further. I've tried -fspecialise-aggressively, but it didn't seem to make a difference, and I haven't found this flag described in the GHC user's guide. Anyone have pointers to more information? Thanks, - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrey.mokhov at newcastle.ac.uk Thu Jan 28 03:02:50 2016 From: andrey.mokhov at newcastle.ac.uk (Andrey Mokhov) Date: Thu, 28 Jan 2016 03:02:50 +0000 Subject: [ANNOUNCE] Shaking up GHC In-Reply-To: <778fc21afb044e9fb8224d9e55a0b25f@DB4PR30MB030.064d.mgd.msft.net> References: <9c0cbf832813492aae0828fdf172f02c@DB4PR30MB030.064d.mgd.msft.net> <778fc21afb044e9fb8224d9e55a0b25f@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Simon, > Documenting this side-by-side possibility on the home page > would be very helpful to up-take. Indeed. I added a note on this at the very top of the README. > Why not just make the 'validate' script invoke the shake build > system (instead of 'make') when you say 'sh validate --shake'? > That would be simple, wouldn't it? So shake builds GHC, and > then 'validate' invokes 'make test' (or whatever) to run the testsuite. Several quick attempts to reuse the validate script have failed, so I decided to start implementing a proper test rule in the new build system. (Note, I still rely on the old Python scripts for testing -- rewriting them seems to be a major undertaking.) The test rule does work for me on Windows, but the functionality is very limited at the moment. You can give it a try by running: shake-build/build.sh test This should run (some) tests. It shouldn't take long to make it more useful. I added a section on testing to the README: https://github.com/snowleopard/shaking-up-ghc#testing. Cheers, Andrey -----Original Message----- From: Simon Peyton Jones [mailto:simonpj at microsoft.com] Sent: 26 January 2016 08:55 To: Andrey Mokhov ; Ben Gamari Cc: ghc-devs at haskell.org Subject: RE: [ANNOUNCE] Shaking up GHC | That's correct. Note though that the two build systems put (some) | build results in the same directories, e.g. inplace/bin/ghc-stage1, so | there is some interaction between them. In future it would be possible | to decouple them completely (if need be). Documenting this side-by-side possibility on the home page would be very helpful to up-take. | > How can I do that using Shake to build? Maybe | > sh validate --shake --fast --no-clean | > or something? Just modifying the validate script to make it | >convenient to use shake for the build part would be great. | | This may be possible precisely because binaries are where validate | expects them to be. I tried to pull this off, but unsuccessfully so | far (validate starts rebuilding everything from scratch with make). I | think the reason is that we changed some naming conventions for | directories (using stageN instead of dist, dist-boot, dist-install), | so validate can't find some utils. I'll let you know if I find a | workaround. Why not just make the 'validate' script invoke the shake build system (instead of 'make') when you say 'sh validate --shake'? That would be simple, wouldn't it? So shake builds GHC, and then 'validate' invokes 'make test' (or whatever) to run the testsuite. Little things like this would significantly increase uptake I think! Simon | | Ben, | | > > But User.hs is a source file, which we shouldn't normally modify | > > lest we accidentally commit it. Could we have a non-source file to | > > modify (rather like > > | https://na01.safelinks.protection.outlook.com/?url=build.mk&data=01% | > > | 7c01%7csimonpj%40064d.mgd.microsoft.com%7c7f0edcff3c78490bd0e808d325 | > > | be4774%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=8L%2b7QWlhbAwUnY | > > fAfCEwTXTC2PUMd17m1ceCcD2TE%2fU%3d being based on | build.mk.sample) > > > One way around this would be to add User.hs | to .gitignore. That way > git will ignore changes to this files when | you `git commit -a`. You > can still, however, commit changes to it | if you ask git explicitly. | | Yes, I was thinking about the same idea. | | Cheers, | Andrey | | -----Original Message----- | From: Simon Peyton Jones [mailto:simonpj at microsoft.com] | Sent: 25 January 2016 12:14 | To: Andrey Mokhov ; ghc- | devs at haskell.org | Cc: Neil Mitchell ; Simon Marlow | | Subject: RE: [ANNOUNCE] Shaking up GHC | | Very good. | | As I understand it, it can work side-by-side with the existing build | system, correct? That means we don't need to make an either/or | choice, which is very helpful. | | Every day I do | sh validate --fast --no-clean | How can I do that using Shake to build? Maybe | sh validate --shake --fast --no-clean or something? Just modifying | the validate script to make it convenient to use shake for the build | part would be great. | | You say: The make-based build system uses mk/build.mk to specify user | build settings. We use src/Settings/User.hs for the same purpose. Feel | free to experiment following the Haddock comments. | | But User.hs is a source file, which we shouldn't normally modify lest | we accidentally commit it. Could we have a non-source file to modify | (rather like | https://na01.safelinks.protection.outlook.com/?url=build.mk&data=01%7c | | 01%7csimonpj%40064d.mgd.microsoft.com%7c7f0edcff3c78490bd0e808d325be47 | | 74%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=8L%2b7QWlhbAwUnYfAfCEw | TXTC2PUMd17m1ceCcD2TE%2fU%3d being based on build.mk.sample) | | Simon | | | -----Original Message----- | | From: Andrey Mokhov [mailto:andrey.mokhov at newcastle.ac.uk] | | Sent: 22 January 2016 14:27 | | To: ghc-devs at haskell.org | | Cc: Simon Peyton Jones ; Neil Mitchell | | ; Simon Marlow | Subject: | [ANNOUNCE] Shaking up GHC | | Dear GHC developers, | | I am | happy to announce that the Shaking up GHC project has finally | | reached the first milestone. The goal of the project is to design a | | new GHC build system based on Shake that will eventually replace the | | current make-based one. See the project page for more details: | | https://github.com/snowleopard/shaking-up-ghc. | | | | There is still a long way until we can match the capabilities of | the | current build system. At the moment we only build vanilla way. | | Validation, documentation, build flavours and cross-compilation | are | not yet implemented. Known limitations are listed here: | | https://github.com/snowleopard/shaking-up-ghc#current-limitations. | | | | The purpose of this announcement is to attract alpha testers and | | collect early feedback across multiple platforms and build | | configurations. We already have several success reports on Linux, OS | | X, Solaris and Windows. However, things will inevitably break and we | | hope to catch and fix as many of these cases as possible with your | | help. The instructions on how to try the new build system can be | found | here: | https://github.com/snowleopard/shaking-up-ghc#your-first- | build. | | | | We plan to be ready to become a part of the GHC tree around 1 | March | 2016, and catch up with the make build system around 1 June 2016. | The | | dates are tentative and depend on how much time it takes us to | resolve | the remaining issues: | https://github.com/snowleopard/shaking-up- | | ghc/milestones. | | | | I would like thank everyone who contributed to this project so far: | | Simon Peyton Jones, Neil Mitchell and Simon Marlow came up with | the | idea and guided me throughout the project; Moritz Angermann, | Ben | Gamari, Karel Gardas, David Luposchainsky, and Neil Mitchell | | contributed to the codebase. Thank you all! | | | | Kind regards, | | Andrey From johan.tibell at gmail.com Thu Jan 28 08:28:05 2016 From: johan.tibell at gmail.com (Johan Tibell) Date: Thu, 28 Jan 2016 09:28:05 +0100 Subject: More aggressive dictionary removal? In-Reply-To: References: Message-ID: The best way I know is to put INLINABLE on all functions with dictionaries that you want removed. That's what we do in e.g. containers. The pragma is perhaps a bit misnamed, as it doesn't only imply that we make the source of the function available for inlining, but also that we specialize the dictionary arguments at every call site, when known. On Thu, Jan 28, 2016 at 1:04 AM, Conal Elliott wrote: > I'm looking for pointers on getting GHC to eliminate more overloading & > polymorphism. I think this sort of thing mainly happens in the Specialise > module. The default GHC flag settings get me a couple levels of > monomorphization and dictionary removal, but I want to go further. I've > tried -fspecialise-aggressively, but it didn't seem to make a difference, > and I haven't found this flag described in the GHC user's guide. Anyone > have pointers to more information? > > Thanks, - Conal > > _______________________________________________ > 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: From simonpj at microsoft.com Thu Jan 28 12:54:41 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 28 Jan 2016 12:54:41 +0000 Subject: More aggressive dictionary removal? In-Reply-To: References: Message-ID: Aggressive inlining is one way, but specialisation ought to get a long way, and makes fewer copies of the specialised code. It?s hard to help without a concrete example Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Conal Elliott Sent: 28 January 2016 00:05 To: ghc-devs at haskell.org Subject: More aggressive dictionary removal? I'm looking for pointers on getting GHC to eliminate more overloading & polymorphism. I think this sort of thing mainly happens in the Specialise module. The default GHC flag settings get me a couple levels of monomorphization and dictionary removal, but I want to go further. I've tried -fspecialise-aggressively, but it didn't seem to make a difference, and I haven't found this flag described in the GHC user's guide. Anyone have pointers to more information? Thanks, - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Thu Jan 28 13:40:22 2016 From: johan.tibell at gmail.com (Johan Tibell) Date: Thu, 28 Jan 2016 14:40:22 +0100 Subject: More aggressive dictionary removal? In-Reply-To: References: Message-ID: I think the difference between the inlinable and specialize pragma is whether the specialization needs to be driven by the call site or not. If you have a handful of known types you want to specialize for up front, you can use the specialize pragma. If the set is large or unknown (like in the case of container keys/value, the inlinable pragma does the right thing.) On Thu, Jan 28, 2016 at 1:54 PM, Simon Peyton Jones wrote: > Aggressive inlining is one way, but specialisation ought to get a long > way, and makes fewer copies of the specialised code. > > > > It?s hard to help without a concrete example > > > > Simon > > > > *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Conal > Elliott > *Sent:* 28 January 2016 00:05 > *To:* ghc-devs at haskell.org > *Subject:* More aggressive dictionary removal? > > > > I'm looking for pointers on getting GHC to eliminate more overloading & > polymorphism. I think this sort of thing mainly happens in the Specialise > module. The default GHC flag settings get me a couple levels of > monomorphization and dictionary removal, but I want to go further. I've > tried -fspecialise-aggressively, but it didn't seem to make a difference, > and I haven't found this flag described in the GHC user's guide. Anyone > have pointers to more information? > > Thanks, - Conal > > _______________________________________________ > 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: From simonpj at microsoft.com Thu Jan 28 14:31:31 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 28 Jan 2016 14:31:31 +0000 Subject: More aggressive dictionary removal? In-Reply-To: References: Message-ID: <675e14857b7945d894b77f743f2d144e@DB4PR30MB030.064d.mgd.msft.net> I think the difference between the inlinable and specialize pragma is whether the specialization needs to be driven by the call site or not. If you have a handful of known types you want to specialize for up front, you can use the specialize pragma. If the set is large or unknown (like in the case of container keys/value, the inlinable pragma does the right thing.) Correct! And not well described anywhere. If someone writes something, I?ll willingly review S From: Johan Tibell [mailto:johan.tibell at gmail.com] Sent: 28 January 2016 13:40 To: Simon Peyton Jones Cc: Conal Elliott ; ghc-devs at haskell.org Subject: Re: More aggressive dictionary removal? I think the difference between the inlinable and specialize pragma is whether the specialization needs to be driven by the call site or not. If you have a handful of known types you want to specialize for up front, you can use the specialize pragma. If the set is large or unknown (like in the case of container keys/value, the inlinable pragma does the right thing.) On Thu, Jan 28, 2016 at 1:54 PM, Simon Peyton Jones > wrote: Aggressive inlining is one way, but specialisation ought to get a long way, and makes fewer copies of the specialised code. It?s hard to help without a concrete example Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Conal Elliott Sent: 28 January 2016 00:05 To: ghc-devs at haskell.org Subject: More aggressive dictionary removal? I'm looking for pointers on getting GHC to eliminate more overloading & polymorphism. I think this sort of thing mainly happens in the Specialise module. The default GHC flag settings get me a couple levels of monomorphization and dictionary removal, but I want to go further. I've tried -fspecialise-aggressively, but it didn't seem to make a difference, and I haven't found this flag described in the GHC user's guide. Anyone have pointers to more information? Thanks, - Conal _______________________________________________ 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: From simonpj at microsoft.com Thu Jan 28 15:40:38 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 28 Jan 2016 15:40:38 +0000 Subject: CallStack naming In-Reply-To: <1453918574.415584.504305722.15570A0D@webmail.messagingengine.com> References: <96F502AD-4AC6-40FA-BD9C-C9C063C2DDE0@cis.upenn.edu> <659dc968669143e0972602a72fb7753e@DB4PR30MB030.064d.mgd.msft.net> <1453305947.1797061.497600914.32732A90@webmail.messagingengine.com> <13f3ddc1d01a4f46ac15a051cc8ff049@DB4PR30MB030.064d.mgd.msft.net> <1453310647.1815559.497698170.68A46486@webmail.messagingengine.com> <1453367951.23159.6.camel@joachim-breitner.de> <1453918574.415584.504305722.15570A0D@webmail.messagingengine.com> Message-ID: <3086447f86064970bd1be9b1e62045f3@DB4PR30MB030.064d.mgd.msft.net> OK. Let's make sure the wiki page and documentation reflects this. Thanks SImon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Eric | Seidel | Sent: 27 January 2016 18:16 | To: ghc-devs at haskell.org | Subject: Re: CallStack naming | | On Thu, Jan 21, 2016, at 04:07, Simon Peyton Jones wrote: | > | It?d probably need a built-in function | > | | > | setCallStack :: CallStack -> (AppendsCallStack => a) -> a | > | > Correct. This is easy to write in Core but not in Haskell. | | Ugh, I just realized that we can't write setCallStack (with implicit | parameters) in Haskell either. Well, we can, but it adds an entry to | the stack.. Why? Let's look at the implementation | | setCallStack :: CallStack -> (HasCallStack => a) -> a | setCallStack stk do_this = | let ?callStack = stk in do_this | | Rebinding ?callStack works just fine, but the occurrence of do_this | causes GHC to push an entry onto the stack, which is less than ideal. | | What does this look like in practice? If we evaluate | | setCallStack foo (error "die") | | the resulting stack will be | | error | *do_this* | foo | | The rebinding trick works for withFrozenCallStack precisely because we | freeze the CallStack, so the push from do_this is ignored. | | So, long story short, I'm not convinced of the utility of setCallStack. | I think perhaps we should not provide it, and just do the rebinding | trick inside withFrozenCallStack (which was the only use-case for | setCallStack to begin with). | _______________________________________________ | 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%0a&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c37a3c50163ce4 | 0dc0ee408d32745f348%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=dVg%2b | q2D%2b2mgmgSWh8Ic9o09P%2f9mem4CpDgd0YzZZpPc%3d From rwbarton at gmail.com Thu Jan 28 18:08:09 2016 From: rwbarton at gmail.com (Reid Barton) Date: Thu, 28 Jan 2016 13:08:09 -0500 Subject: Unexpected lack of change in ghcspeed results In-Reply-To: References: <1453933405.1572.95.camel@joachim-breitner.de> Message-ID: On Wed, Jan 27, 2016 at 5:35 PM, Reid Barton wrote: > Oh! I guess the name ghcspeed was too memorable... and browser bar > autocompletion did the rest. Sorry for the noise! > I noticed that https://perf.haskell.org/ghc/ still says "GHC Speed" in the page title and the page header, so now I don't feel quite so silly for making this mistake. If http://ghcspeed-nomeata.rhcloud.com/ is not supported any more, how about adding a notice to that page pointing people to https://perf.haskell.org/ghc/? Regards, Reid Barton > On Wed, Jan 27, 2016 at 5:23 PM, Joachim Breitner < > mail at joachim-breitner.de> wrote: > >> Dear Reid, >> >> Am Mittwoch, den 27.01.2016, 14:50 -0500 schrieb Reid Barton: >> > I was interested to see what effect the recent commit "Restore >> > original alignment for info tables" (0dc7b36c) would have on >> > performance. However, when I look at http://ghcspeed-nomeata.rhcloud. >> > com/changes/?rev=0dc7b36c3c261b3eccf8460581fcd3d71f6e6ff6, I don't >> > see the expected binary size increase (about 1%) that I got in local >> > testing. Instead, the size increase appears to be attached to commit >> > 0d92d9cb6d65fd00f9910c3f6f85bc6c68f5543b. >> > >> > I notice that these two commits, along with three others, were >> > committed at exactly the same time (Wed Jan 27 11:32:15 2016 +0100), >> > presumably in a rebase. Could this be confusing ghcspeed? >> > >> >> heh, I?m surprised: Both that the ghcspeed server still runs, and that >> people are still using it :-) >> >> Indeed, you observe correctly, ghcspeed does not handle git rebases >> well. That was one of the reasons why I reimplemented the server from >> scratch. It now runs under perf.haskell.org, and there the expected >> changes are attributed to the right commit: >> >> https://perf.haskell.org/ghc/#revision/0dc7b36c3c261b3eccf8460581fcd3d71f6e6ff6 >> >> Is ghcspeed still linked somewhere, or was it an old bookmark from you >> that led you there? >> >> Greetings, >> Joachim >> >> -- >> Joachim ?nomeata? Breitner >> mail at joachim-breitner.de ? http://www.joachim-breitner.de/ >> Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F >> Debian Developer: nomeata at debian.org >> >> >> _______________________________________________ >> 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: From conal at conal.net Thu Jan 28 18:12:45 2016 From: conal at conal.net (Conal Elliott) Date: Thu, 28 Jan 2016 10:12:45 -0800 Subject: More aggressive dictionary removal? In-Reply-To: References: Message-ID: Hah! I had misread the signatures in the Core output. I'm getting exactly the dictionary removal I wanted. Fantastic! I'm attaching my sample source code and the Core it produces. Sorry for the misdirection, and kudos for specialis/zation in GHC! -- Conal On Thu, Jan 28, 2016 at 4:54 AM, Simon Peyton Jones wrote: > Aggressive inlining is one way, but specialisation ought to get a long > way, and makes fewer copies of the specialised code. > > > > It?s hard to help without a concrete example > > > > Simon > > > > *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Conal > Elliott > *Sent:* 28 January 2016 00:05 > *To:* ghc-devs at haskell.org > *Subject:* More aggressive dictionary removal? > > > > I'm looking for pointers on getting GHC to eliminate more overloading & > polymorphism. I think this sort of thing mainly happens in the Specialise > module. The default GHC flag settings get me a couple levels of > monomorphization and dictionary removal, but I want to go further. I've > tried -fspecialise-aggressively, but it didn't seem to make a difference, > and I haven't found this flag described in the GHC user's guide. Anyone > have pointers to more information? > > Thanks, - Conal > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SpecT.dump-simpl Type: application/octet-stream Size: 19512 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SpecT.hs Type: text/x-haskell Size: 1057 bytes Desc: not available URL: From ezyang at mit.edu Thu Jan 28 18:30:45 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Thu, 28 Jan 2016 10:30:45 -0800 Subject: GHC build time graphs Message-ID: <1454005734-sup-9633@sabre> Joachim, Anthony Cowley was recently complaining on Twitter that building GHC takes 39.5% longer now than it did for 7.10.1: https://twitter.com/a_cowley/status/692481516744634368 Do we have graphs for these metrics, e.g. can we see the breakdown of which commits increased the build time? Thanks, Edward From conal at conal.net Thu Jan 28 18:36:07 2016 From: conal at conal.net (Conal Elliott) Date: Thu, 28 Jan 2016 10:36:07 -0800 Subject: More aggressive dictionary removal? In-Reply-To: References: Message-ID: I just split the "library code" (data types and instances) and the client code (type-specialized use) into two modules. Same great results, as long as both modules are compiled with -O (not even -O2). Sweet! On Thu, Jan 28, 2016 at 10:12 AM, Conal Elliott wrote: > Hah! I had misread the signatures in the Core output. I'm getting exactly > the dictionary removal I wanted. Fantastic! > > I'm attaching my sample source code and the Core it produces. > > Sorry for the misdirection, and kudos for specialis/zation in GHC! > > -- Conal > > On Thu, Jan 28, 2016 at 4:54 AM, Simon Peyton Jones > wrote: > >> Aggressive inlining is one way, but specialisation ought to get a long >> way, and makes fewer copies of the specialised code. >> >> >> >> It?s hard to help without a concrete example >> >> >> >> Simon >> >> >> >> *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Conal >> Elliott >> *Sent:* 28 January 2016 00:05 >> *To:* ghc-devs at haskell.org >> *Subject:* More aggressive dictionary removal? >> >> >> >> I'm looking for pointers on getting GHC to eliminate more overloading & >> polymorphism. I think this sort of thing mainly happens in the Specialise >> module. The default GHC flag settings get me a couple levels of >> monomorphization and dictionary removal, but I want to go further. I've >> tried -fspecialise-aggressively, but it didn't seem to make a difference, >> and I haven't found this flag described in the GHC user's guide. Anyone >> have pointers to more information? >> >> Thanks, - Conal >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Thu Jan 28 22:16:39 2016 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 28 Jan 2016 23:16:39 +0100 Subject: GHC build time graphs In-Reply-To: <1454005734-sup-9633@sabre> References: <1454005734-sup-9633@sabre> Message-ID: <1454019399.1646.4.camel@joachim-breitner.de> Hi, Am Donnerstag, den 28.01.2016, 10:30 -0800 schrieb Edward Z. Yang: > Anthony Cowley was recently complaining on Twitter that > building GHC takes 39.5% longer now than it did for 7.10.1: > https://twitter.com/a_cowley/status/692481516744634368 > > Do we have graphs for these metrics, e.g. can we see the breakdown > of which commits increased the build time? well, we have https://perf.haskell.org/ghc/#graph/buildtime/make In theory, there would be a button to expand the graph on the left. In practice, that is not yet implemented... See?https://github.com/nomeata/gipeda/issues/14 Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From mail at joachim-breitner.de Thu Jan 28 22:17:13 2016 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 28 Jan 2016 23:17:13 +0100 Subject: Unexpected lack of change in ghcspeed results In-Reply-To: References: <1453933405.1572.95.camel@joachim-breitner.de> Message-ID: <1454019433.1646.5.camel@joachim-breitner.de> Hi, Am Donnerstag, den 28.01.2016, 13:08 -0500 schrieb Reid Barton: > On Wed, Jan 27, 2016 at 5:35 PM, Reid Barton wrote: > > Oh! I guess the name ghcspeed was too memorable... and browser bar autocompletion did the rest. Sorry for the noise! > > > I noticed that https://perf.haskell.org/ghc/ still says "GHC Speed" > in the page title and the page header, so now I don't feel quite so > silly for making this mistake. If http://ghcspeed- > nomeata.rhcloud.com/ is not supported any more, how about adding a > notice to that page pointing people to https://perf.haskell.org/ghc/ I simply turned it off now. (I found it too troublesome to figure out how to set up a redirect there, and also a waste of a free OpenShift application slot just for that.) Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From oleg.grenrus at iki.fi Thu Jan 28 22:22:35 2016 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Fri, 29 Jan 2016 00:22:35 +0200 Subject: GHC build time graphs In-Reply-To: <1454005734-sup-9633@sabre> References: <1454005734-sup-9633@sabre> Message-ID: <010A82CA-A36C-4739-ADFC-1B0035483351@iki.fi> Is the same compiler used to build HEAD and 7.10,1? - Oleg > On 28 Jan 2016, at 20:30, Edward Z. Yang wrote: > > Joachim, > > Anthony Cowley was recently complaining on Twitter that > building GHC takes 39.5% longer now than it did for 7.10.1: > https://twitter.com/a_cowley/status/692481516744634368 > > Do we have graphs for these metrics, e.g. can we see the breakdown > of which commits increased the build time? > > Thanks, > Edward > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mail at joachim-breitner.de Thu Jan 28 22:26:28 2016 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 28 Jan 2016 23:26:28 +0100 Subject: GHC build time graphs In-Reply-To: <010A82CA-A36C-4739-ADFC-1B0035483351@iki.fi> References: <1454005734-sup-9633@sabre> <010A82CA-A36C-4739-ADFC-1B0035483351@iki.fi> Message-ID: <1454019988.2635.2.camel@joachim-breitner.de> Hi Oleg, Am Freitag, den 29.01.2016, 00:22 +0200 schrieb Oleg Grenrus: > Is the same compiler used to build HEAD and 7.10,1? Good call. In fact, no: 7.10.1 is built with?7.6.3, while HEAD is built with 7.10.3. Anthony?s link, i.e. https://perf.haskell.org/ghc/#compare/ca00def1d7093d6b5b2a937ddfc8a01c152038eb/a496f82d5684f3025a60877600e82f0b29736e85 has links to the build logs of either build; there I could find that information. That might be (part) of the problem. But if it is, it is even worse, as it would mean not only building the compiler got slower, but the compiler itself... Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From ben at smart-cactus.org Thu Jan 28 22:34:33 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Thu, 28 Jan 2016 23:34:33 +0100 Subject: GHC build time graphs In-Reply-To: <1454019988.2635.2.camel@joachim-breitner.de> References: <1454005734-sup-9633@sabre> <010A82CA-A36C-4739-ADFC-1B0035483351@iki.fi> <1454019988.2635.2.camel@joachim-breitner.de> Message-ID: <87k2mtcozq.fsf@smart-cactus.org> Joachim Breitner writes: > Hi Oleg, > > Am Freitag, den 29.01.2016, 00:22 +0200 schrieb Oleg Grenrus: >> Is the same compiler used to build HEAD and 7.10,1? > > Good call. In fact, no: 7.10.1 is built with?7.6.3, while HEAD is built > with 7.10.3. > > Anthony?s link, i.e. > https://perf.haskell.org/ghc/#compare/ca00def1d7093d6b5b2a937ddfc8a01c152038eb/a496f82d5684f3025a60877600e82f0b29736e85 > has links to the build logs of either build; there I could find that information. > > That might be (part) of the problem. But if it is, it is even worse, as > it would mean not only building the compiler got slower, but the > compiler itself... > I can verify that the build itself is indeed slower. Validating the current state of ghc-7.10 takes 19 minutes, whereas ghc-8.0 takes 25.5 minutes. This isn't entirely unexpected but the change is quite a bit larger than I had thought. It would be nice to know which commits are responsible. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From omeragacan at gmail.com Thu Jan 28 22:48:57 2016 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Thu, 28 Jan 2016 17:48:57 -0500 Subject: a reliable way of dropping levity args? In-Reply-To: References: Message-ID: I finally had some time to have another look. I have this line in my compiler pass: | Just (tc, args) <- splitTyConApp_maybe ty , isUnboxedTupleTyCon tc = pprTrace "elimUbxSumRepTypes" (text "orig args:" <+> ppr args $$ text "dropWhile isLevityTy args = " <+> ppr (dropWhile isLevityTy args)) $ concatMap go (drop (length args `div` 2) args) This is one of the outputs: elimUbxSumRepTypes orig args: ['Lifted, 'Lifted, 'Lifted, String, String, String] dropWhile isLevityTy args = ['Lifted, 'Lifted, 'Lifted, String, String, String] Am I doing this wrong? 2016-01-25 7:30 GMT-05:00 Richard Eisenberg : > As discussed on IRC, your approach below looks right to me: dropWhile (isLevityTy . idType) args. But you then said this wasn't working for you. What does (map idType args) say? > > Richard > > On Jan 24, 2016, at 8:58 PM, ?mer Sinan A?acan wrote: > >> Hi all, >> >> I'm looking for a reliable way of dropping levity args from TyCon applications. >> When I know that a particular TyCon gets some number of levity args, I can just >> drop the args manually (for example, I can drop the first half of arguments of >> a tuple TyCon application) but the code looks fragile (what happens if I use a >> different TyCon in the future) and confusing to the reader because it looks >> like this: >> >> drop (length args `div` 2) args >> >> Ideally it'd look like this: >> >> dropWhile isLevityArg args >> >> Now, there's a function called isLevityTy, but I don't understand what it's >> supposed to do. This doesn't do anyting to 'Boxed and 'Unboxed arguments: >> >> dropWhile (isLevityArg . idType) args >> >> Any ideas on this? >> >> Thanks.. > From omeragacan at gmail.com Thu Jan 28 23:50:38 2016 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Thu, 28 Jan 2016 18:50:38 -0500 Subject: Adding a "release" setting in build.mk.sample (and some other build system questions) Message-ID: I'm trying to figure out how to generate a release build. I thought it should be "perf" setting, but then I realized ghc-stage1 is called with -O (instead of -O2) when building stage2 with perf setting. So either perf is not the release setting, or I need stage3 which is probably compiled with stage2 using -O2? In any case, it'd be great to document this process of generating a release build in build.mk.sample. If it's "perf" setting, then maybe we can rename it to "release" or at least add a comment saying that that's the release build and you should wait until stage3 is done. Another thing that always confuses me is these settings: SRC_HC_OPTS = -O -H64m GhcStage1HcOpts = -O GhcStage2HcOpts = -O2 GhcLibHcOpts = -O2 As far as I can see, there's no documentation about these in the source tree. I figured that `GhcStage1HcOpts` is passed to system GHC when compiling stage1, and `GhcStage2Hcopts` is passed to ghc-stage1 when compiling stage 2. The lib one is obvious, and it's passed to stage 1 as libs are built using stage 1. But I still don't understand how is `SRC_HC_OPTS` is used, and what is used when building stage 3. From thomasmiedema at gmail.com Fri Jan 29 00:23:27 2016 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Fri, 29 Jan 2016 01:23:27 +0100 Subject: Adding a "release" setting in build.mk.sample (and some other build system questions) In-Reply-To: References: Message-ID: https://ghc.haskell.org/trac/ghc/wiki/MakingReleases#Makingthebinarybuilds https://ghc.haskell.org/trac/ghc/wiki/Building/Using#Buildconfiguration On Fri, Jan 29, 2016 at 12:50 AM, ?mer Sinan A?acan wrote: > I'm trying to figure out how to generate a release build. I thought it > should > be "perf" setting, but then I realized ghc-stage1 is called with -O > (instead of > -O2) when building stage2 with perf setting. So either perf is not the > release > setting, or I need stage3 which is probably compiled with stage2 using -O2? > > In any case, it'd be great to document this process of generating a release > build in build.mk.sample. If it's "perf" setting, then maybe we can rename > it > to "release" or at least add a comment saying that that's the release > build and > you should wait until stage3 is done. > > Another thing that always confuses me is these settings: > > SRC_HC_OPTS = -O -H64m > GhcStage1HcOpts = -O > GhcStage2HcOpts = -O2 > GhcLibHcOpts = -O2 > > As far as I can see, there's no documentation about these in the source > tree. I > figured that `GhcStage1HcOpts` is passed to system GHC when compiling > stage1, > and `GhcStage2Hcopts` is passed to ghc-stage1 when compiling stage 2. The > lib > one is obvious, and it's passed to stage 1 as libs are built using stage > 1. But > I still don't understand how is `SRC_HC_OPTS` is used, and what is used > when > building stage 3. > _______________________________________________ > 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: From eir at cis.upenn.edu Fri Jan 29 00:39:13 2016 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Thu, 28 Jan 2016 19:39:13 -0500 Subject: a reliable way of dropping levity args? In-Reply-To: References: Message-ID: On Jan 28, 2016, at 5:48 PM, ?mer Sinan A?acan wrote: > > | Just (tc, args) <- splitTyConApp_maybe ty > , isUnboxedTupleTyCon tc > = pprTrace "elimUbxSumRepTypes" > (text "orig args:" <+> ppr args $$ > text "dropWhile isLevityTy args = " <+> ppr (dropWhile > isLevityTy args)) $ > concatMap go (drop (length args `div` 2) args) You want (dropWhile (isLevityTy . typeKind) args). isLevityTy simply checks if its argument is exactly `Levity`. Does that work? Richard From omeragacan at gmail.com Fri Jan 29 01:30:27 2016 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Thu, 28 Jan 2016 20:30:27 -0500 Subject: a reliable way of dropping levity args? In-Reply-To: References: Message-ID: Ahh, levity is type of kinds, right? For some reason I thought kinds are now levities (or whatever it's called). This makes sense. I just tried and I think it works, thanks. 2016-01-28 19:39 GMT-05:00 Richard Eisenberg : > > On Jan 28, 2016, at 5:48 PM, ?mer Sinan A?acan wrote: >> >> | Just (tc, args) <- splitTyConApp_maybe ty >> , isUnboxedTupleTyCon tc >> = pprTrace "elimUbxSumRepTypes" >> (text "orig args:" <+> ppr args $$ >> text "dropWhile isLevityTy args = " <+> ppr (dropWhile >> isLevityTy args)) $ >> concatMap go (drop (length args `div` 2) args) > > You want (dropWhile (isLevityTy . typeKind) args). isLevityTy simply checks if its argument is exactly `Levity`. > > Does that work? > > Richard From omeragacan at gmail.com Fri Jan 29 01:34:44 2016 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Thu, 28 Jan 2016 20:34:44 -0500 Subject: a reliable way of dropping levity args? In-Reply-To: References: Message-ID: It might be nice to actually replace `drop (length args `div` 2) args` with a function `dropLevityArgs = dropWhile (isLevityTy . typeKind)` (I did this in my branch). When I see a code that drops half of the type arguments it doesn't make sense right away, but `dropLevityArgs` is at least giving an idea of what's actually happening. 2016-01-28 20:30 GMT-05:00 ?mer Sinan A?acan : > Ahh, levity is type of kinds, right? For some reason I thought kinds are now > levities (or whatever it's called). This makes sense. I just tried and I think > it works, thanks. > > 2016-01-28 19:39 GMT-05:00 Richard Eisenberg : >> >> On Jan 28, 2016, at 5:48 PM, ?mer Sinan A?acan wrote: >>> >>> | Just (tc, args) <- splitTyConApp_maybe ty >>> , isUnboxedTupleTyCon tc >>> = pprTrace "elimUbxSumRepTypes" >>> (text "orig args:" <+> ppr args $$ >>> text "dropWhile isLevityTy args = " <+> ppr (dropWhile >>> isLevityTy args)) $ >>> concatMap go (drop (length args `div` 2) args) >> >> You want (dropWhile (isLevityTy . typeKind) args). isLevityTy simply checks if its argument is exactly `Levity`. >> >> Does that work? >> >> Richard From eir at cis.upenn.edu Fri Jan 29 03:07:41 2016 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Thu, 28 Jan 2016 22:07:41 -0500 Subject: a reliable way of dropping levity args? In-Reply-To: References: Message-ID: <7BFC41C3-19F9-46B1-9951-4FB3946683DD@cis.upenn.edu> Levity is very simple: > data Levity = Lifted | Unlifted And that's it, as far as Levity is concerned. The weird thing is TYPE, whose type is Levity -> TYPE 'Lifted. (Yes. TYPE's type mentions TYPE.) The * of yore is now spelled TYPE 'Lifted. The # of yore is now spelled TYPE 'Unlifted. * and # really are just type synonyms. (See them for yourself in GHC.Types.hs.) There is some discussion on wiki:NoSubKinds, but it may be a bit out of date. And, yes, a more obvious function to drop levity arguments (to unboxed tuples, presumably) is a good idea. Richard On Jan 28, 2016, at 8:30 PM, ?mer Sinan A?acan wrote: > Ahh, levity is type of kinds, right? For some reason I thought kinds are now > levities (or whatever it's called). This makes sense. I just tried and I think > it works, thanks. > > 2016-01-28 19:39 GMT-05:00 Richard Eisenberg : >> >> On Jan 28, 2016, at 5:48 PM, ?mer Sinan A?acan wrote: >>> >>> | Just (tc, args) <- splitTyConApp_maybe ty >>> , isUnboxedTupleTyCon tc >>> = pprTrace "elimUbxSumRepTypes" >>> (text "orig args:" <+> ppr args $$ >>> text "dropWhile isLevityTy args = " <+> ppr (dropWhile >>> isLevityTy args)) $ >>> concatMap go (drop (length args `div` 2) args) >> >> You want (dropWhile (isLevityTy . typeKind) args). isLevityTy simply checks if its argument is exactly `Levity`. >> >> Does that work? >> >> Richard > From simonpj at microsoft.com Fri Jan 29 08:36:17 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 29 Jan 2016 08:36:17 +0000 Subject: a reliable way of dropping levity args? In-Reply-To: References: Message-ID: Well, isLevityTy tests whether its argument is Levity But you want to test if the argument is a data constructor (e.g. Lifted, Unlifted) whose type is Levity. So you need something like isLevityCon :: Type -> Bool isLevityCon (TyConApp tc []) = isLevityTy (tyConKind tc) .. Please document both functions carefully ALSO there is a bug in isLevityTy; it is missing a coreView test. Would you like to fix this? Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of ?mer | Sinan Agacan | Sent: 28 January 2016 22:49 | To: Richard Eisenberg | Cc: ghc-devs | Subject: Re: a reliable way of dropping levity args? | | I finally had some time to have another look. I have this line in my | compiler pass: | | | Just (tc, args) <- splitTyConApp_maybe ty | , isUnboxedTupleTyCon tc | = pprTrace "elimUbxSumRepTypes" | (text "orig args:" <+> ppr args $$ | text "dropWhile isLevityTy args = " <+> ppr (dropWhile | isLevityTy args)) $ | concatMap go (drop (length args `div` 2) args) | | This is one of the outputs: | | elimUbxSumRepTypes | orig args: ['Lifted, 'Lifted, 'Lifted, String, String, String] | dropWhile isLevityTy args = ['Lifted, 'Lifted, 'Lifted, String, | String, String] | | Am I doing this wrong? | | 2016-01-25 7:30 GMT-05:00 Richard Eisenberg : | > As discussed on IRC, your approach below looks right to me: dropWhile | (isLevityTy . idType) args. But you then said this wasn't working for | you. What does (map idType args) say? | > | > Richard | > | > On Jan 24, 2016, at 8:58 PM, ?mer Sinan A?acan | wrote: | > | >> Hi all, | >> | >> I'm looking for a reliable way of dropping levity args from TyCon | applications. | >> When I know that a particular TyCon gets some number of levity args, | >> I can just drop the args manually (for example, I can drop the first | >> half of arguments of a tuple TyCon application) but the code looks | >> fragile (what happens if I use a different TyCon in the future) and | >> confusing to the reader because it looks like this: | >> | >> drop (length args `div` 2) args | >> | >> Ideally it'd look like this: | >> | >> dropWhile isLevityArg args | >> | >> Now, there's a function called isLevityTy, but I don't understand | >> what it's supposed to do. This doesn't do anyting to 'Boxed and | 'Unboxed arguments: | >> | >> dropWhile (isLevityArg . idType) args | >> | >> Any ideas on this? | >> | >> Thanks.. | > | _______________________________________________ | 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%0a&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c60501578c8024 | 97bb4a208d328354eff%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=2%2fOf | nL4IPh41UZLx2XskQF%2fTf6kSA%2bP%2bXmn3r346kiI%3d From voldermort at hotmail.com Fri Jan 29 13:47:15 2016 From: voldermort at hotmail.com (Harry .) Date: Fri, 29 Jan 2016 13:47:15 +0000 Subject: Adding a "release" setting in build.mk.sample (and some other build system questions) Message-ID: > https://ghc.haskell.org/trac/ghc/wiki/MakingReleases#Makingthebinarybuilds > https://ghc.haskell.org/trac/ghc/wiki/Building/Using#Buildconfiguration So the mysterious SRC_HC_OPTS = -O -H64m which appears in every build flavour isn't used for the release build? From omeragacan at gmail.com Fri Jan 29 14:48:52 2016 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Fri, 29 Jan 2016 09:48:52 -0500 Subject: a reliable way of dropping levity args? In-Reply-To: References: Message-ID: 2016-01-29 3:36 GMT-05:00 Simon Peyton Jones : > > So you need something like > > isLevityCon :: Type -> Bool > isLevityCon (TyConApp tc []) = isLevityTy (tyConKind tc) > .. > > Please document both functions carefully > > ALSO there is a bug in isLevityTy; it is missing a coreView test. Would you like to fix this? Just submitted a patch: https://phabricator.haskell.org/D1867 From thomasmiedema at gmail.com Fri Jan 29 16:44:56 2016 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Fri, 29 Jan 2016 17:44:56 +0100 Subject: Adding a "release" setting in build.mk.sample (and some other build system questions) In-Reply-To: References: Message-ID: The default (and thus release) `SRC_HC_OPTS` uses `-H32m` (see mk/ config.mk.in). Maybe you want to run some tests to see if it makes a difference on the total build time? I suggest also measuring without any `-H` flag, with just `-H` (see commit below), and with `-H1G` or some other large value. ``` commit 323950933d3260503186b93e7a5a7bdaa4822c1b Author: Simon Marlow Date: Mon Nov 30 15:18:36 2009 +0000 Implement a new heap-tuning option: -H -H alone causes the RTS to use a larger nursery, but without exceeding the amount of memory that the application is already using. It trades off GC time against locality: the default setting is to use a fixed-size 512k nursery, but this is sometimes worse than using a very large nursery despite the worse locality. Not all programs get faster, but some programs that use large heaps do much better with -H. e.g. this helps a lot with #3061 (binary-trees), though not as much as specifying -H. Typically using -H is better than plain -H, because the runtime doesn't know ahead of time how much memory you want to use. Should -H be on by default? I'm not sure, it makes some programs go slower, but others go faster. ``` On Fri, Jan 29, 2016 at 2:47 PM, Harry . wrote: > > > https://ghc.haskell.org/trac/ghc/wiki/MakingReleases#Makingthebinarybuilds > > https://ghc.haskell.org/trac/ghc/wiki/Building/Using#Buildconfiguration > > So the mysterious SRC_HC_OPTS = -O -H64m which appears in every build > flavour isn't used for the release build? > > _______________________________________________ > 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: From carter.schonwald at gmail.com Fri Jan 29 17:59:23 2016 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 29 Jan 2016 12:59:23 -0500 Subject: More aggressive dictionary removal? In-Reply-To: <675e14857b7945d894b77f743f2d144e@DB4PR30MB030.064d.mgd.msft.net> References: <675e14857b7945d894b77f743f2d144e@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Wait, inlinable creates a new specialization automatically at each new instances / use site? I always thought it just allows invoking specialize pragma in client modules. On Thursday, January 28, 2016, Simon Peyton Jones wrote: > I think the difference between the inlinable and specialize pragma is > whether the specialization needs to be driven by the call site or not. If > you have a handful of known types you want to specialize for up front, you > can use the specialize pragma. If the set is large or unknown (like in the > case of container keys/value, the inlinable pragma does the right thing.) > > Correct! And not well described anywhere. > > > > If someone writes something, I?ll willingly review > > > > S > > > > *From:* Johan Tibell [mailto:johan.tibell at gmail.com > ] > *Sent:* 28 January 2016 13:40 > *To:* Simon Peyton Jones > > *Cc:* Conal Elliott >; ghc-devs at haskell.org > > *Subject:* Re: More aggressive dictionary removal? > > > > I think the difference between the inlinable and specialize pragma is > whether the specialization needs to be driven by the call site or not. If > you have a handful of known types you want to specialize for up front, you > can use the specialize pragma. If the set is large or unknown (like in the > case of container keys/value, the inlinable pragma does the right thing.) > > > > On Thu, Jan 28, 2016 at 1:54 PM, Simon Peyton Jones > wrote: > > Aggressive inlining is one way, but specialisation ought to get a long > way, and makes fewer copies of the specialised code. > > > > It?s hard to help without a concrete example > > > > Simon > > > > *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org > ] *On > Behalf Of *Conal Elliott > *Sent:* 28 January 2016 00:05 > *To:* ghc-devs at haskell.org > > *Subject:* More aggressive dictionary removal? > > > > I'm looking for pointers on getting GHC to eliminate more overloading & > polymorphism. I think this sort of thing mainly happens in the Specialise > module. The default GHC flag settings get me a couple levels of > monomorphization and dictionary removal, but I want to go further. I've > tried -fspecialise-aggressively, but it didn't seem to make a difference, > and I haven't found this flag described in the GHC user's guide. Anyone > have pointers to more information? > > Thanks, - Conal > > > _______________________________________________ > 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: From voldermort at hotmail.com Sat Jan 30 17:57:17 2016 From: voldermort at hotmail.com (Harry .) Date: Sat, 30 Jan 2016 17:57:17 +0000 Subject: Adding a "release" setting in build.mk.sample (and some other build system questions) In-Reply-To: References: , Message-ID: > Date: Fri, 29 Jan 2016 17:44:56 +0100 > Subject: Re: Adding a "release" setting in build.mk.sample (and some > other build system questions) > From: thomasmiedema at gmail.com > To: voldermort at hotmail.com > CC: ghc-devs at haskell.org > > The default (and thus release) `SRC_HC_OPTS` uses `-H32m` (see > mk/config.mk.in). > > Maybe you want to run some tests to see if it makes a difference on the > total build time? > > I suggest also measuring without any `-H` flag, with just `-H` (see > commit below), and with `-H1G` or some other large value. I'm building in a container on a busy host at work (i.e. which I don't control), so unfortunately there's too much background noise to make meaningful measurements. Does SRC_HC_OPTS control memory usage while building GHC, or when it's running? And either way, why does this need setting for building GHC, but isn't normally used when compiling regular Haskell programs? From mainland at apeiron.net Sat Jan 30 22:32:07 2016 From: mainland at apeiron.net (Geoffrey Mainland) Date: Sat, 30 Jan 2016 17:32:07 -0500 Subject: Build broken Message-ID: <56AD39E7.4040204@apeiron.net> I attempted to rebase my fix for #11487, but I can no longer validate. The culprit is 6c7760b2. I am seeing the errors below under linux, building with 7.10.3. Herbert, I hope there is a quick fix? Thanks, Geoff libraries/unix/System/Posix/IO/Common.hsc:316:61: error: ? Couldn't match type ?()? with ?Base.CFLock? Expected type: Ptr Base.CFLock Actual type: Ptr CFLock ? In the third argument of ?Base.c_fcntl_lock?, namely ?p_flock? In the second argument of ?throwErrnoIfMinus1_?, namely ?(Base.c_fcntl_lock fd (5) p_flock)? In a stmt of a 'do' block: throwErrnoIfMinus1_ "getLock" (Base.c_fcntl_lock fd (5) p_flock) libraries/unix/System/Posix/IO/Common.hsc:364:61: error: ? Couldn't match type ?()? with ?Base.CFLock? Expected type: Ptr Base.CFLock Actual type: Ptr CFLock ? In the third argument of ?Base.c_fcntl_lock?, namely ?p_flock? In the second argument of ?throwErrnoIfMinus1_?, namely ?(Base.c_fcntl_lock fd (6) p_flock)? In the expression: throwErrnoIfMinus1_ "setLock" (Base.c_fcntl_lock fd (6) p_flock) libraries/unix/System/Posix/IO/Common.hsc:371:35: error: ? Couldn't match type ?()? with ?Base.CFLock? Expected type: Ptr Base.CFLock Actual type: Ptr CFLock ? In the third argument of ?Base.c_fcntl_lock?, namely ?p_flock? In the second argument of ?throwErrnoIfMinus1_?, namely ?(Base.c_fcntl_lock fd (7) p_flock)? In the expression: throwErrnoIfMinus1_ "waitToSetLock" (Base.c_fcntl_lock fd (7) p_flock) From andrey.mokhov at newcastle.ac.uk Sun Jan 31 00:44:27 2016 From: andrey.mokhov at newcastle.ac.uk (Andrey Mokhov) Date: Sun, 31 Jan 2016 00:44:27 +0000 Subject: [ANNOUNCE] Shaking up GHC In-Reply-To: <778fc21afb044e9fb8224d9e55a0b25f@DB4PR30MB030.064d.mgd.msft.net> References: <9c0cbf832813492aae0828fdf172f02c@DB4PR30MB030.064d.mgd.msft.net> <778fc21afb044e9fb8224d9e55a0b25f@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Simon & all, > Why not just make the 'validate' script invoke the shake build system > (instead of 'make') when you say 'sh validate --shake'? That would be > simple, wouldn't it? So shake builds GHC, and then 'validate' invokes > 'make test' (or whatever) to run the testsuite. > > Little things like this would significantly increase uptake I think! We can now run: shake-build/build.sh validate This will rebuild stage2 GHC, ghc-pkg and hpc if need be, and will then run GHC tests by executing `make fast` in `testsuite/tests` folder (https://github.com/snowleopard/shaking-up-ghc#testing). There is still a lot of work to add proper support for various useful command line settings like `TEST=abc` or `TEST_HC=xyz`. It would be great if someone could add support for `--shake` command line flag to the `validate` script, as Simon suggested. This would be a better solution, but I'm not confident enough to edit the validate script myself. Thanks to Thomas Miedema for his patient guidance on how GHC test suite works. Cheers, Andrey > -----Original Message----- > From: Simon Peyton Jones [mailto:simonpj at microsoft.com] > Sent: 26 January 2016 08:55 > To: Andrey Mokhov; Ben Gamari > Cc: ghc-devs at haskell.org > Subject: RE: [ANNOUNCE] Shaking up GHC > > | That's correct. Note though that the two build systems put (some) > | build results in the same directories, e.g. inplace/bin/ghc-stage1, > so > | there is some interaction between them. In future it would be > possible > | to decouple them completely (if need be). > > Documenting this side-by-side possibility on the home page would be > very helpful to up-take. > > | > How can I do that using Shake to build? Maybe > | > sh validate --shake --fast --no-clean > | > or something? Just modifying the validate script to make it > | >convenient to use shake for the build part would be great. > | > | This may be possible precisely because binaries are where validate > | expects them to be. I tried to pull this off, but unsuccessfully so > | far (validate starts rebuilding everything from scratch with make). > I > | think the reason is that we changed some naming conventions for > | directories (using stageN instead of dist, dist-boot, dist-install), > | so validate can't find some utils. I'll let you know if I find a > | workaround. > > Why not just make the 'validate' script invoke the shake build system > (instead of 'make') when you say 'sh validate --shake'? That would be > simple, wouldn't it? So shake builds GHC, and then 'validate' invokes > 'make test' (or whatever) to run the testsuite. > > Little things like this would significantly increase uptake I think! > > Simon > > > > | > | Ben, > | > | > > But User.hs is a source file, which we shouldn't normally modify > | > > lest we accidentally commit it. Could we have a non-source file > to > | > > modify (rather like > | > > > | https://na01.safelinks.protection.outlook.com/?url=build.mk&data=01% > | > > > | 7c01%7csimonpj%40064d.mgd.microsoft.com%7c7f0edcff3c78490bd0e808d325 > | > > > | be4774%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=8L%2b7QWlhbAwUnY > | > > fAfCEwTXTC2PUMd17m1ceCcD2TE%2fU%3d being based on > build.mk.sample) > | > > > | > One way around this would be to add User.hs to .gitignore. That > way > | > git will ignore changes to this files when you `git commit -a`. > You > | > can still, however, commit changes to it if you ask git > explicitly. > | > | Yes, I was thinking about the same idea. > | > | Cheers, > | Andrey > | > | -----Original Message----- > | From: Simon Peyton Jones [mailto:simonpj at microsoft.com] > | Sent: 25 January 2016 12:14 > | To: Andrey Mokhov ; ghc- > | devs at haskell.org > | Cc: Neil Mitchell ; Simon Marlow > | > | Subject: RE: [ANNOUNCE] Shaking up GHC > | > | Very good. > | > | As I understand it, it can work side-by-side with the existing build > | system, correct? That means we don't need to make an either/or > | choice, which is very helpful. > | > | Every day I do > | sh validate --fast --no-clean > | How can I do that using Shake to build? Maybe > | sh validate --shake --fast --no-clean > | or something? Just modifying the validate script to make it > | convenient to use shake for the build part would be great. > | > | You say: The make-based build system uses mk/build.mk to specify > user > | build settings. We use src/Settings/User.hs for the same purpose. > Feel > | free to experiment following the Haddock comments. > | > | But User.hs is a source file, which we shouldn't normally modify > lest > | we accidentally commit it. Could we have a non-source file to > modify > | (rather like > | > https://na01.safelinks.protection.outlook.com/?url=build.mk&data=01%7c > | > 01%7csimonpj%40064d.mgd.microsoft.com%7c7f0edcff3c78490bd0e808d325be47 > | > 74%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=8L%2b7QWlhbAwUnYfAfCEw > | TXTC2PUMd17m1ceCcD2TE%2fU%3d being based on build.mk.sample) > | > | Simon > | > | | -----Original Message----- > | | From: Andrey Mokhov [mailto:andrey.mokhov at newcastle.ac.uk] > | | Sent: 22 January 2016 14:27 > | | To: ghc-devs at haskell.org > | | Cc: Simon Peyton Jones ; Neil Mitchell > | | ; Simon Marlow > | | Subject: [ANNOUNCE] Shaking up GHC > | | > | | Dear GHC developers, > | | > | | I am happy to announce that the Shaking up GHC project has > finally > | | reached the first milestone. The goal of the project is to design > a > | | new GHC build system based on Shake that will eventually replace > the > | | current make-based one. See the project page for more details: > | | https://github.com/snowleopard/shaking-up-ghc. > | | > | | There is still a long way until we can match the capabilities of > | the > | | current build system. At the moment we only build vanilla way. > | | Validation, documentation, build flavours and cross-compilation > are > | | not yet implemented. Known limitations are listed here: > | | https://github.com/snowleopard/shaking-up-ghc#current- > limitations. > | | > | | The purpose of this announcement is to attract alpha testers and > | | collect early feedback across multiple platforms and build > | | configurations. We already have several success reports on Linux, > OS > | | X, Solaris and Windows. However, things will inevitably break and > we > | | hope to catch and fix as many of these cases as possible with your > | | help. The instructions on how to try the new build system can be > | found > | | here: https://github.com/snowleopard/shaking-up-ghc#your-first- > | build. > | | > | | We plan to be ready to become a part of the GHC tree around 1 > March > | | 2016, and catch up with the make build system around 1 June 2016. > | The > | | dates are tentative and depend on how much time it takes us to > | resolve > | | the remaining issues: https://github.com/snowleopard/shaking-up- > | | ghc/milestones. > | | > | | I would like thank everyone who contributed to this project so > far: > | | Simon Peyton Jones, Neil Mitchell and Simon Marlow came up with > the > | | idea and guided me throughout the project; Moritz Angermann, Ben > | | Gamari, Karel Gardas, David Luposchainsky, and Neil Mitchell > | | contributed to the codebase. Thank you all! > | | > | | Kind regards, > | | Andrey From cma at bitemyapp.com Sun Jan 31 01:56:56 2016 From: cma at bitemyapp.com (Christopher Allen) Date: Sat, 30 Jan 2016 19:56:56 -0600 Subject: Nailing down what we expect IO to do and not do - and why Message-ID: I'm writing a book, I'd like to get this nailed down and to get it right. If anyone on here that's familiar with the various ways in which IO/State#/realWorld# work in GHC and you have time to reply, anything at all would be welcome. Any pointers, links, references, details, anecdotes, or faint memories of GHC bugs will be greatly appreciated! Getting this written up (possibly for addition to Michael Snoyman's wiki article?) would make me, and I imagine others, a lot happier with trying to understand how the different bits and bobs fit together. I will be dumping my notes as I don't want to get linked to stuff that can be googled because I've already lost 10-15 hours to just that in the past 3-4 days. Digging it up in the compiler is hard because compiler behavior that influences how IO actions are treated don't necessarily have "IO" or "realWorld" mentioned in the relevant parts of the compiler, optimizations, etc. What I'm hoping for is answers on what specifically preserves the listed properties we want from IO in the compiler, prims, or structure of how we write IO actions. What we expect IO to do: - Disable sharing of results, even when it's not a lambda and is evaluated multiple times by the same name. ie, getCurrentTime :: IO UTCTime should get evaluated more than once. - Not reorder sequential IO actions, such as in a do-block. Called "linearity" below - Not duplicate the effects of IO actions. Effects shouldn't be spuriously duplicated during optimization passes. - Effects should not be discarded separately of the value returned by an IO action, merged, or elided. # Sharing A friend suggested that perhaps one-shot semantics via the state hack for State# in the IO type is responsible for disabling sharing, I don't believe so, but here are my notes. >-fno-state-hack >Turn off the "state hack" whereby any lambda with a State# token as argument is considered to be single-entry, hence it is considered OK to inline things inside it. This can improve performance of IO and ST monad code, but it runs the risk of reducing sharing. >A one shot lambda >State hack, makes the lambda over State# assume it's one-shot universally by default. >one-shot/state hack is an anti-inlining heuristic, suggesting that inlining is costly. Also I found this on Trac, does anyone know the answer to this? Is the summary above accurate? >Can the IO state hack be avoided if oneShot is used in the right places in library code, e.g. in IO?s definition of >>=? This seems related how the state token works, for differentiating which IO action is which and how many times an IO action should run, when it should run, etc. >From the prims: >data State# s >State# is the primitive, unlifted type of states. It has one type parameter, thus State# RealWorld, or State# s, where s is a type variable. The only purpose of the type parameter is to keep different state threads separate. It is represented by nothing at all. >data RealWorld >RealWorld is deeply magical. It is primitive, but it is not unlifted (hence ptrArg). We never manipulate values of type RealWorld; it's only used in the type system, to parameterise State#. # Linearity Is this from the nesting of lambdas? It doesn't seem like that's enough based on the various examples using State/State# in GHC Trac bug tickets. The RealWorld token seems to be what's driving this but precisely how that works hasn't been easy to find. # Discarding, not inlining effects I believe these are addressed by has_side_effects in the prim ops. I could very well be wrong. can_fail has_side_effects Discard NO NO Float in YES YES Float out NO NO Duplicate YES NO * Duplication. You cannot duplicate a has_side_effect primop. You might wonder how this can occur given the state token threading, but just look at Control.Monad.ST.Lazy.Imp.strictToLazy! We get something like this p = case readMutVar# s v of (# s', r #) -> (S# s', r) s' = case p of (s', r) -> s' r = case p of (s', r) -> r I believe duplication addresses inlining IO actions more generally but I could be wrong. Here's a note I found regarding elision/merging: * Use the compiler flag @-fno-cse@ to prevent common sub-expression elimination being performed on the module, which might combine two side effects that were meant to be separate. A good example is using multiple global variables (like @test@ in the example below). Any help or pointers for nailing down and documenting this would be greatly appreciated. Also if there's a more detailed explanation of what behavior is expected out of each unsafe function, that would help as well. There are bits and pieces I've been able to aggregate from the GHC trac tickets. References used (not exhaustive): - Referential Transparency; Haskell Wiki https://wiki.haskell.org/Referential_transparency - IO Inside; Haskell Wiki https://wiki.haskell.org/IO_inside - Unraveling the mystery of the IO Monad; Edward Z. Yang http://blog.ezyang.com/2011/05/unraveling-the-mystery-of-the-io-monad/ - Evaluation order and state tokens; Michael Snoyman https://wiki.haskell.org/Evaluation_order_and_state_tokens - Haskell GHC Illustrated; Takenobu Tani - Tackling the Awkward Squad; Simon Peyton Jones http://research.microsoft.com/en-us/um/people/simonpj/papers/marktoberdorf/mark.pdf - Note [IO hack in the demand analyser]; GHC source code - Monadic I/O in Haskell 1.3; Andrew D. Gordon and Kevin Hammond - Haskell Report 1.2 http://haskell.cs.yale.edu/wp-content/uploads/2011/01/haskell-report-1.2.pdf Thank you for your time, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From mainland at apeiron.net Sun Jan 31 18:10:42 2016 From: mainland at apeiron.net (Geoffrey Mainland) Date: Sun, 31 Jan 2016 13:10:42 -0500 Subject: Best practices for merging? Message-ID: <56AE4E22.8070502@apeiron.net> I've been away from GHC for a while, and it's not clear to me what the best practices for merging are now. My usual git workflow is to work on a feature branch, get a nice clean set of patches, each of which implements a discrete bit of functionality, rebase onto master, and then merge with an empty merge commit, i..e, *not* fast-forward. This lets me look at the repo history and easily see where a feature branch landed and get a good idea of what changes it contains. I have used this approach in the past with GHC, e.g., SIMD support and typed TH. For smaller sets of changes, I might skip the merge commit, but I still break up my changes into discreet bits, which helps anyone reading the change set to see what's going on. It seems the current policy is to submit changes via Phab and then, after approval, squash everything into a single patch and apply it with arc. At least that is my reading of https://ghc.haskell.org/trac/ghc/wiki/Phabricator/Extras#Landingreviews. Is that what I should be doing? For feature branches, is that also what is advised? Thanks, Geoff From mail at joachim-breitner.de Sun Jan 31 18:24:47 2016 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sun, 31 Jan 2016 19:24:47 +0100 Subject: Best practices for merging? In-Reply-To: <56AE4E22.8070502@apeiron.net> References: <56AE4E22.8070502@apeiron.net> Message-ID: <1454264687.1627.42.camel@joachim-breitner.de> Hi, Am Sonntag, den 31.01.2016, 13:10 -0500 schrieb Geoffrey Mainland: > My usual git workflow is to work on a feature branch, get a nice clean > set of patches, each of which implements a discrete bit of > functionality, rebase onto master, and then merge with an empty merge > commit, i..e, *not* fast-forward. if you want to go through the trouble, you are certainly welcome to do so. The fact that phab squashes commits into one is more an artifact of its VCS-agnosticity rather than a deliberate decision by us. When I want a git history (or just my nice git commit messages) preserved, I create a phab differetian revision as usual, but then manually amend the git commit to contain the line Differential Revision:?https://phabricator.haskell.org/Dnnnn and push, once the DR has been accepted, by normal git means. I just have to remember to indicate in the DR (e.g. in the summary) that I want to do it this way. Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From tuncer.ayaz at gmail.com Sun Jan 31 19:47:29 2016 From: tuncer.ayaz at gmail.com (Tuncer Ayaz) Date: Sun, 31 Jan 2016 20:47:29 +0100 Subject: Best practices for merging? In-Reply-To: <1454264687.1627.42.camel@joachim-breitner.de> References: <56AE4E22.8070502@apeiron.net> <1454264687.1627.42.camel@joachim-breitner.de> Message-ID: On 31 January 2016 at 19:24, Joachim Breitner wrote: > Hi, > > Am Sonntag, den 31.01.2016, 13:10 -0500 schrieb Geoffrey Mainland: > > My usual git workflow is to work on a feature branch, get a nice > > clean set of patches, each of which implements a discrete bit of > > functionality, rebase onto master, and then merge with an empty > > merge commit, i..e, *not* fast-forward. > > if you want to go through the trouble, you are certainly welcome to do > so. The fact that phab squashes commits into one is more an artifact > of its VCS-agnosticity rather than a deliberate decision by us. > > When I want a git history (or just my nice git commit messages) > preserved, I create a phab differetian revision as usual, but then > manually amend the git commit to contain the line Differential > Revision: https://phabricator.haskell.org/Dnnnn and push, once the DR > has been accepted, by normal git means. I just have to remember to > indicate in the DR (e.g. in the summary) that I want to do it this > way. FWIW, I agree with Geoffrey, and in addition to the benefits he listed, I appreciate that committing "kernel.org-style" improves bisect'ability. I used to dislike merge commits myself until I realized the usefulness of finding merge points in the history. So, I don't understand how collapsing everything into one big commit can make any sense. Is it really impossible to tell phabricator (or arcanist) to preserve a carefully prepared patch set, and if so, why does it insist on that? From mainland at apeiron.net Sun Jan 31 21:01:56 2016 From: mainland at apeiron.net (Geoffrey Mainland) Date: Sun, 31 Jan 2016 16:01:56 -0500 Subject: Best practices for merging? In-Reply-To: References: <56AE4E22.8070502@apeiron.net> <1454264687.1627.42.camel@joachim-breitner.de> Message-ID: <56AE7644.5070704@apeiron.net> On 01/31/2016 02:47 PM, Tuncer Ayaz wrote: > On 31 January 2016 at 19:24, Joachim Breitner wrote: >> Hi, >> >> Am Sonntag, den 31.01.2016, 13:10 -0500 schrieb Geoffrey Mainland: >>> My usual git workflow is to work on a feature branch, get a nice >>> clean set of patches, each of which implements a discrete bit of >>> functionality, rebase onto master, and then merge with an empty >>> merge commit, i..e, *not* fast-forward. >> if you want to go through the trouble, you are certainly welcome to do >> so. The fact that phab squashes commits into one is more an artifact >> of its VCS-agnosticity rather than a deliberate decision by us. >> >> When I want a git history (or just my nice git commit messages) >> preserved, I create a phab differetian revision as usual, but then >> manually amend the git commit to contain the line Differential >> Revision: https://phabricator.haskell.org/Dnnnn and push, once the DR >> has been accepted, by normal git means. I just have to remember to >> indicate in the DR (e.g. in the summary) that I want to do it this >> way. > FWIW, I agree with Geoffrey, and in addition to the benefits he listed, > I appreciate that committing "kernel.org-style" improves bisect'ability. > I used to dislike merge commits myself until I realized the usefulness > of finding merge points in the history. So, I don't understand how > collapsing everything into one big commit can make any sense. > > Is it really impossible to tell phabricator (or arcanist) to preserve > a carefully prepared patch set, and if so, why does it insist on that? Not that I don't think these things are worth discussing, but to be clear, I was not trying to impose my preferred git workflow on GHC :) I was just looking for clarification, which Joachim provided---thanks! Cheers, Geoff From conal at conal.net Sun Jan 31 21:58:18 2016 From: conal at conal.net (Conal Elliott) Date: Sun, 31 Jan 2016 13:58:18 -0800 Subject: Specializing expressions beyond names? Message-ID: It seems to be the case that SPECIALIZE pragmas are syntactically restricted to type specializations of a *name* (identifier) rather than a general expression. Is my understanding correct here? If so, is there any reason for this restriction? I ask because I?m reifying Core code (into code that constructs a corresponding run-time representation for further processing), and I?m looking for a clean way to integrate that process with GHC, to support separate compilation and to avoid interfering with GHC?s regular flow. It occurred to me that I could enable separate compilation via a pragma of the form ?{-# SPECIALIZE reify foo ? E t #-}? for some t, where E t is a reified form of values of type t. Type checking would infer the specialized type of foo, and the usual specialization phase would do its usual thing on that specialization, leaving ?reify foo = reify specialized_foo?, and then the reification compiler plugin would transform the right-hand side, pushing the reify inward. Some reify calls may remain (e.g., due to polymorphism), triggering future rule applications. As much as possible of the fully-reified version would be factored out of the generated rule?s RHS for cheap reuse. Thanks, - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuncer.ayaz at gmail.com Sun Jan 31 22:58:44 2016 From: tuncer.ayaz at gmail.com (Tuncer Ayaz) Date: Sun, 31 Jan 2016 23:58:44 +0100 Subject: Best practices for merging? In-Reply-To: <56AE7644.5070704@apeiron.net> References: <56AE4E22.8070502@apeiron.net> <1454264687.1627.42.camel@joachim-breitner.de> <56AE7644.5070704@apeiron.net> Message-ID: On 31 January 2016 at 22:01, Geoffrey Mainland wrote: > On 01/31/2016 02:47 PM, Tuncer Ayaz wrote: > > On 31 January 2016 at 19:24, Joachim Breitner wrote: > > > Hi, > > > > > > Am Sonntag, den 31.01.2016, 13:10 -0500 schrieb Geoffrey Mainland: > > > > My usual git workflow is to work on a feature branch, get a > > > > nice clean set of patches, each of which implements a discrete > > > > bit of functionality, rebase onto master, and then merge with > > > > an empty merge commit, i..e, *not* fast-forward. > > > > > > if you want to go through the trouble, you are certainly welcome > > > to do so. The fact that phab squashes commits into one is more > > > an artifact of its VCS-agnosticity rather than a deliberate > > > decision by us. > > > > > > When I want a git history (or just my nice git commit messages) > > > preserved, I create a phab differetian revision as usual, but > > > then manually amend the git commit to contain the line > > > Differential Revision: https://phabricator.haskell.org/Dnnnn and > > > push, once the DR has been accepted, by normal git means. I just > > > have to remember to indicate in the DR (e.g. in the summary) > > > that I want to do it this way. > > > > FWIW, I agree with Geoffrey, and in addition to the benefits he > > listed, I appreciate that committing "kernel.org-style" improves > > bisect'ability. I used to dislike merge commits myself until I > > realized the usefulness of finding merge points in the history. > > So, I don't understand how collapsing everything into one big > > commit can make any sense. > > > > Is it really impossible to tell phabricator (or arcanist) to > > preserve a carefully prepared patch set, and if so, why does it > > insist on that? > > Not that I don't think these things are worth discussing, but to be > clear, I was not trying to impose my preferred git workflow on GHC > :) I was just looking for clarification, which Joachim > provided---thanks! I'll have to deal a lot more with Phabricator in another project soon, and your question reminded me to figure out why this happens, etc. Open source communication has conditioned me to discuss publicly, so I may have hijacked the thread. Sorry. For anybody who's curious: I actually looked this up and it seems that Facebook decided to default to squash for cleaning up branches that are full of fixup commits and thereby make phab not support branches with a clean history, where each commit gets you a working state (not some in-between broken revision). So it's to support all those devs who do not create patch sets. There are some suggestions like setting history.immutable in .arcconfig or invoking land with --merge. Will try these the next time I use arc.