From matthewtpickering at gmail.com Thu Oct 1 11:23:15 2015 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Thu, 1 Oct 2015 12:23:15 +0100 Subject: Pattern Synonym Signature Confusion Message-ID: I think that the current state of pattern synonym signatures is quite confusing, especially regarding the constraints. For those unfamiliar, a signature looks like the following, pattern ExNumPat :: (Show b) => (Num a, Eq a) => b -> T a The first constraint being the "provided constraints" and the second the "required constraints". My main concern is when only a single constraint is specified then these are treated as the provided constraints. The manual gives the reason that this is the "more common" choice. It seems that this motivation is driven by the original ticket which had a lengthy discussion about GADTs. In my experience, the opposite is true, it is more common to have required constraints. This is true especially in a few common cases such as "pattern Foo = 27", where users define pattern synonyms which have (overloaded) literals on the RHS. The most general signature for such a pattern is "pattern :: () => (Eq a, Num a) => a". For this reason, I think it would be better if either 1. Only specifying one constraint corresponded to the required constraints 2. We required users to specify both sets of constraints, even if the provided constraints are empty. In terms of breakage, I don't think that pattern synonym signatures are widely used yet. In both schemes it is possible to write backwards compatible code by writing both sets of constraints. I think a lot of the confusion also arises from the unusual form of the signature, it is unusual to specify two sets of constraints and I suspect users tends to assume that a single set of constraints is either provided or required depending on what they want it to mean. Forcing the specification of both, forces the user to make the distinction earlier rather than trying to decipher error messages. Thoughts? Matt From svenpanne at gmail.com Thu Oct 1 17:12:43 2015 From: svenpanne at gmail.com (Sven Panne) Date: Thu, 1 Oct 2015 19:12:43 +0200 Subject: Pattern Synonym Signature Confusion In-Reply-To: References: Message-ID: 2015-10-01 13:23 GMT+02:00 Matthew Pickering : > I think that the current state of pattern synonym signatures is quite > confusing, especially regarding the constraints. [...] Thanks to an off-list email from Matthew (thanks for that!) I found out that pattern FOO = 1234 :: Int behaves differently from pattern FOO :: Int pattern FOO = 1234 In the former case one has to use ScopedTypeVariables, in the latter case it works without it. This is not really intuitive, although I'll have to admit that I've had only a cursory look at the "Typing of pattern synonyms" section in the GHC manual. But even after re-reading it, it's not really clear where the difference in the above example comes from. So in a nutshell: +1 for the "quite confusing" argument. Cheers, S. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ganesh at earth.li Thu Oct 1 17:56:40 2015 From: ganesh at earth.li (Ganesh Sittampalam) Date: Thu, 1 Oct 2015 18:56:40 +0100 Subject: Pattern Synonym Signature Confusion In-Reply-To: References: Message-ID: <560D73D8.3050209@earth.li> On 01/10/2015 18:12, Sven Panne wrote: > 2015-10-01 13:23 GMT+02:00 Matthew Pickering > >: > > I think that the current state of pattern synonym signatures is quite > confusing, especially regarding the constraints. [...] > > > Thanks to an off-list email from Matthew (thanks for that!) I found out that > > pattern FOO = 1234 :: Int > > behaves differently from > > pattern FOO :: Int > pattern FOO = 1234 > > In the former case one has to use ScopedTypeVariables, in the latter > case it works without it. This is not really intuitive, although I'll > have to admit that I've had only a cursory look at the "Typing of > pattern synonyms" section in the GHC manual. But even after re-reading > it, it's not really clear where the difference in the above example > comes from. > > So in a nutshell: +1 for the "quite confusing" argument. Isn't that consistent with patterns in general, where something like f (5 :: Int) = 6 is only legal with ScopedTypeVariables on? Cheers, Ganesh From simonpj at microsoft.com Thu Oct 1 21:48:24 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 1 Oct 2015 21:48:24 +0000 Subject: Pattern Synonym Signature Confusion In-Reply-To: References: Message-ID: Matthew What you say sounds reasonable to me. I certainly don't have a strong opinion that the current design is the "right" one. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Matthew | Pickering | Sent: 01 October 2015 12:23 | To: GHC developers | Subject: Pattern Synonym Signature Confusion | | I think that the current state of pattern synonym signatures is quite | confusing, especially regarding the constraints. For those unfamiliar, | a signature looks like the following, | | pattern ExNumPat :: (Show b) => (Num a, Eq a) => b -> T a | | The first constraint being the "provided constraints" and the second | the "required constraints". | | My main concern is when only a single constraint is specified then | these are treated as the provided constraints. The manual gives the | reason that this is the "more common" choice. It seems that this | motivation is driven by the original ticket which had a lengthy | discussion about GADTs. In my experience, the opposite is true, it is | more common to have required constraints. | | This is true especially in a few common cases such as "pattern Foo = | 27", where users define pattern synonyms which have (overloaded) | literals on the RHS. The most general signature for such a pattern is | "pattern :: () => (Eq a, Num a) => a". | | For this reason, I think it would be better if either | | 1. Only specifying one constraint corresponded to the required constraints | 2. We required users to specify both sets of constraints, even if the | provided constraints are empty. | | In terms of breakage, I don't think that pattern synonym signatures | are widely used yet. In both schemes it is possible to write backwards | compatible code by writing both sets of constraints. | | I think a lot of the confusion also arises from the unusual form of | the signature, it is unusual to specify two sets of constraints and I | suspect users tends to assume that a single set of constraints is | either provided or required depending on what they want it to mean. | Forcing the specification of both, forces the user to make the | distinction earlier rather than trying to decipher error messages. | | Thoughts? | | Matt | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haske | ll.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c403e493d2a54438d264 | 408d2ca52b5b9%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=sjc2n0Gm1A%2ffe | OKEpntmEYqTfbYaLvk2sb%2b2vUqIqLU%3d From matthewtpickering at gmail.com Fri Oct 2 11:58:28 2015 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Fri, 2 Oct 2015 12:58:28 +0100 Subject: Pattern Synonym Signature Confusion In-Reply-To: References: Message-ID: I have grepped the whole of hackage. There are only 10 pattern synonym signatures in total in three separate packages (one of them being my own). None of them specify provided constraints, three of them specify required constraints. Of course this is a very small sample size but it means that there wouldn't be any widespread breakage either way with this proposal. ``` ../hackage-packages//ghc-exactprint-0.4.1.0/tests/examples/Sigs.hs:pattern Single :: () => (Show a) => a -> [a] ../hackage-packages//structs-0/src/Data/Struct/Internal.hs:pattern Struct :: () => Struct t => SmallMutableArray# s Any -> t s ../hackage-packages//structs-0/src/Data/Struct/Internal.hs:pattern Nil :: forall t s. () => Struct t => t s ../hackage-packages//transformations-0.2.0.0/examples/MultiRec.hs:pattern Ref' :: Path phi ix top -> HWithRef phi top ix ../hackage-packages//transformations-0.2.0.0/examples/MultiRec.hs:pattern Const' :: forall top. Integer -> HWithRef AST top AExpr ../hackage-packages//transformations-0.2.0.0/examples/MultiRec.hs:pattern BConst' :: forall top. Bool -> HWithRef AST top BExpr ../hackage-packages//transformations-0.2.0.0/examples/MultiRec.hs:pattern And' :: forall top. HWithRef AST top BExpr -> HWithRef AST top BExpr ../hackage-packages//transformations-0.2.0.0/examples/MultiRec.hs:pattern GT' :: forall top. HWithRef AST top AExpr -> HWithRef AST top AExpr ../hackage-packages//transformations-0.2.0.0/examples/MultiRec.hs:pattern GT_0 :: Path AST top AExpr -> Path AST top BExpr ../hackage-packages//transformations-0.2.0.0/examples/MultiRec.hs:pattern Neg_0 :: Path AST top AExpr -> Path AST top AExpr ``` On Thu, Oct 1, 2015 at 10:48 PM, Simon Peyton Jones wrote: > Matthew > > What you say sounds reasonable to me. I certainly don't have a strong opinion that the current design is the "right" one. > > Simon > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Matthew > | Pickering > | Sent: 01 October 2015 12:23 > | To: GHC developers > | Subject: Pattern Synonym Signature Confusion > | > | I think that the current state of pattern synonym signatures is quite > | confusing, especially regarding the constraints. For those unfamiliar, > | a signature looks like the following, > | > | pattern ExNumPat :: (Show b) => (Num a, Eq a) => b -> T a > | > | The first constraint being the "provided constraints" and the second > | the "required constraints". > | > | My main concern is when only a single constraint is specified then > | these are treated as the provided constraints. The manual gives the > | reason that this is the "more common" choice. It seems that this > | motivation is driven by the original ticket which had a lengthy > | discussion about GADTs. In my experience, the opposite is true, it is > | more common to have required constraints. > | > | This is true especially in a few common cases such as "pattern Foo = > | 27", where users define pattern synonyms which have (overloaded) > | literals on the RHS. The most general signature for such a pattern is > | "pattern :: () => (Eq a, Num a) => a". > | > | For this reason, I think it would be better if either > | > | 1. Only specifying one constraint corresponded to the required constraints > | 2. We required users to specify both sets of constraints, even if the > | provided constraints are empty. > | > | In terms of breakage, I don't think that pattern synonym signatures > | are widely used yet. In both schemes it is possible to write backwards > | compatible code by writing both sets of constraints. > | > | I think a lot of the confusion also arises from the unusual form of > | the signature, it is unusual to specify two sets of constraints and I > | suspect users tends to assume that a single set of constraints is > | either provided or required depending on what they want it to mean. > | Forcing the specification of both, forces the user to make the > | distinction earlier rather than trying to decipher error messages. > | > | Thoughts? > | > | Matt > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs at haskell.org > | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haske > | ll.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- > | devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c403e493d2a54438d264 > | 408d2ca52b5b9%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=sjc2n0Gm1A%2ffe > | OKEpntmEYqTfbYaLvk2sb%2b2vUqIqLU%3d From ben at smart-cactus.org Fri Oct 2 13:14:53 2015 From: ben at smart-cactus.org (Ben Gamari) Date: Fri, 02 Oct 2015 15:14:53 +0200 Subject: Switching users guide to ReStructuredText Message-ID: <87twq91kfm.fsf@smart-cactus.org> Hello friendly GHCers, Last week I sent out poll asking opinions on moving the Users' Guide From Docbook to ReStructuredText. While the response wasn't particularly large in volume, those that did reply were quite supportive of the idea. This week I took the time to clean up my hacked prototype. After quite some build system wrangling, it's finally in a merge-worthy state as D1294. You can see the output at, http://smart-cactus.org/~ben/ghc-users-guide/html/index.html http://smart-cactus.org/~ben/ghc-users-guide/users_guide.pdf In addition to converting the DocBook to ReST, this also involved ripping out the previously rather fragile system for building the `ghc` manpage and describing GHC's flags in utils/mkUserGuidePart. Feel free to look over the output. If there are no objections I'll merge this tomorrow. Future Work ----------- * Verify the flag description in mkUserGuidePart against DynFlags (checking for missing or invalid flags) * Perhaps incorporate make flags representation a bit richer, encoding, for instance, implication relationships between flags * Generate flag descriptions for bash_completion and other shells * Improve manpage content * Be more precise about which code samples should be syntax highlighted 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 Fri Oct 2 13:31:48 2015 From: ben at smart-cactus.org (Ben Gamari) Date: Fri, 02 Oct 2015 15:31:48 +0200 Subject: Switching users guide to ReStructuredText In-Reply-To: <87twq91kfm.fsf@smart-cactus.org> References: <87twq91kfm.fsf@smart-cactus.org> Message-ID: <87r3ld1jnf.fsf@smart-cactus.org> Ben Gamari writes: > Hello friendly GHCers, > > Last week I sent out poll asking opinions on moving the Users' Guide > From Docbook to ReStructuredText. While the response wasn't particularly > large in volume, those that did reply were quite supportive of the idea. > > This week I took the time to clean up my hacked prototype. After quite > some build system wrangling, it's finally in a merge-worthy state as > D1294. You can see the output at, > > http://smart-cactus.org/~ben/ghc-users-guide/html/index.html > http://smart-cactus.org/~ben/ghc-users-guide/users_guide.pdf > I should also point out that our documentation now has documentation, http://smart-cactus.org/~ben/ghc-users-guide/html/editing-guide.html Anyone edits the Users Guide should at least glance as this document as it contains a few notes that are otherwise not terribly discoverable. 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 Oct 2 13:52:38 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 2 Oct 2015 13:52:38 +0000 Subject: Switching users guide to ReStructuredText In-Reply-To: <87twq91kfm.fsf@smart-cactus.org> References: <87twq91kfm.fsf@smart-cactus.org> Message-ID: <601bc0b771334c97835f0f8eade954cd@DB4PR30MB030.064d.mgd.msft.net> It looks lovely. Please please can we have section numbers?! It is so helpful to be able to say "see section 3.2.42 in the user manual". And the numbers give a clearer indication of sub-nesting than does the font in which the heading is rendered. It's a big manual to navigate! Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Ben | Gamari | Sent: 02 October 2015 14:15 | To: GHC developers | Subject: Switching users guide to ReStructuredText | | | Hello friendly GHCers, | | Last week I sent out poll asking opinions on moving the Users' Guide | From Docbook to ReStructuredText. While the response wasn't | particularly large in volume, those that did reply were quite | supportive of the idea. | | This week I took the time to clean up my hacked prototype. After quite | some build system wrangling, it's finally in a merge-worthy state as | D1294. You can see the output at, | | | https://na01.safelinks.protection.outlook.com/?url=http:%2f%2fsmart- | cactus.org%2f~ben%2fghc-users- | guide%2fhtml%2findex.html&data=01%7C01%7Csimonpj%40064d.mgd.microsoft. | com%7Ce2f529a35e3345f36f3908d2cb2b7b65%7C72f988bf86f141af91ab2d7cd011d | b47%7C1&sdata=YZmhxdubnVPtHZhDN2in%2fRkgf9qvOrvjZVDe7gIDr%2f4%3d | | https://na01.safelinks.protection.outlook.com/?url=http:%2f%2fsmart- | cactus.org%2f~ben%2fghc-users- | guide%2fusers_guide.pdf&data=01%7C01%7Csimonpj%40064d.mgd.microsoft.co | m%7Ce2f529a35e3345f36f3908d2cb2b7b65%7C72f988bf86f141af91ab2d7cd011db4 | 7%7C1&sdata=gwQMm9GqhwbjcSqZImB%2fru5EEStL%2bBHAykGXf1Tr9YI%3d | | In addition to converting the DocBook to ReST, this also involved | ripping out the previously rather fragile system for building the | `ghc` manpage and describing GHC's flags in utils/mkUserGuidePart. | | Feel free to look over the output. If there are no objections I'll | merge this tomorrow. | | | Future Work | ----------- | | * Verify the flag description in mkUserGuidePart against DynFlags | (checking for missing or invalid flags) | * Perhaps incorporate make flags representation a bit richer, | encoding, | for instance, implication relationships between flags | * Generate flag descriptions for bash_completion and other shells | * Improve manpage content | * Be more precise about which code samples should be syntax | highlighted | | | Cheers, | | - Ben From simonpj at microsoft.com Fri Oct 2 13:56:05 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 2 Oct 2015 13:56:05 +0000 Subject: Switching users guide to ReStructuredText In-Reply-To: <87r3ld1jnf.fsf@smart-cactus.org> References: <87twq91kfm.fsf@smart-cactus.org> <87r3ld1jnf.fsf@smart-cactus.org> Message-ID: | I should also point out that our documentation now has documentation, | | | https://na01.safelinks.protection.outlook.com/?url=http:%2f%2fsmart- | cactus.org%2f~ben%2fghc-users-guide%2fhtml%2fediting- | guide.html&data=01%7C01%7Csimonpj%40064d.mgd.microsoft.com%7Cad191576d | 71949b1486708d2cb2dd891%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=i | IDVdqchctelJGtliVXp3rprcA5ErWrvMyBJZ2Kfacw%3d | | Anyone edits the Users Guide should at least glance as this document | as it contains a few notes that are otherwise not terribly | discoverable. Very good. But in each case can there be, side by side - here is what you write - here is how it looks ? What about lists with bullets/numbers, including multi-level lists? | | Cheers, | | - Ben From ryan.gl.scott at gmail.com Fri Oct 2 14:06:50 2015 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Fri, 2 Oct 2015 10:06:50 -0400 Subject: Switching users guide to ReStructuredText Message-ID: To be honest, I'm not sure if referring to sections by numbers is a great idea. New subsections get spliced into the users' guide quite frequently, which can cause all subsequent subsections to have their numbers incremented. As a result, section numbers could become out-of-date rather quickly. Thankfully, one thing that ReStructured Text does much better than the previous system is make the entire page hyperlinkable. It's now incredibly easy to click on the symbol to the right of any section header and get a link to that spot. Ryan S. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Fri Oct 2 14:11:53 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Fri, 2 Oct 2015 16:11:53 +0200 Subject: Switching users guide to ReStructuredText In-Reply-To: References: Message-ID: But at least they are stable for the life of a release. On Fri, Oct 2, 2015 at 4:06 PM, Ryan Scott wrote: > To be honest, I'm not sure if referring to sections by numbers is a great > idea. New subsections get spliced into the users' guide quite frequently, > which can cause all subsequent subsections to have their numbers > incremented. As a result, section numbers could become out-of-date rather > quickly. > > Thankfully, one thing that ReStructured Text does much better than the > previous system is make the entire page hyperlinkable. It's now incredibly > easy to click on the symbol to the right of any section header and get a > link to that spot. > > 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 ben at smart-cactus.org Fri Oct 2 14:26:01 2015 From: ben at smart-cactus.org (Ben Gamari) Date: Fri, 02 Oct 2015 16:26:01 +0200 Subject: Switching users guide to ReStructuredText In-Reply-To: <601bc0b771334c97835f0f8eade954cd@DB4PR30MB030.064d.mgd.msft.net> References: <87twq91kfm.fsf@smart-cactus.org> <601bc0b771334c97835f0f8eade954cd@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <87lhbl1h52.fsf@smart-cactus.org> Simon Peyton Jones writes: > It looks lovely. > > Please please can we have section numbers?! It is so helpful to be > able to say "see section 3.2.42 in the user manual". And the numbers > give a clearer indication of sub-nesting than does the font in which > the heading is rendered. It's a big manual to navigate! > Ahh, that's a good point. Indeed we can. I've uploaded an updated build with section numbers. 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 Fri Oct 2 14:35:49 2015 From: ben at well-typed.com (Ben Gamari) Date: Fri, 02 Oct 2015 16:35:49 +0200 Subject: Switching users guide to ReStructuredText In-Reply-To: References: <87twq91kfm.fsf@smart-cactus.org> <87r3ld1jnf.fsf@smart-cactus.org> Message-ID: <87io6p1goq.fsf@smart-cactus.org> Simon Peyton Jones writes: > | I should also point out that our documentation now has documentation, > | > | > | https://na01.safelinks.protection.outlook.com/?url=http:%2f%2fsmart- > | cactus.org%2f~ben%2fghc-users-guide%2fhtml%2fediting- > | guide.html&data=01%7C01%7Csimonpj%40064d.mgd.microsoft.com%7Cad191576d > | 71949b1486708d2cb2dd891%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=i > | IDVdqchctelJGtliVXp3rprcA5ErWrvMyBJZ2Kfacw%3d > | > | Anyone edits the Users Guide should at least glance as this document > | as it contains a few notes that are otherwise not terribly > | discoverable. > > Very good. But in each case can there be, side by side > - here is what you write > - here is how it looks > ? I originally included renderings for each of the examples in the document but decided to cut out some of them to shorten things up. I would love to be able to show the code and rendering literally side-by-side, although I don't believe Sphinx natively supports this degree of layout control (although it may be possible to write a custom directive for this). > > What about lists with bullets/numbers, including multi-level lists? > ReST of course supports these although I didn't describe them to avoid making the document a complete guide to ReST; perhaps I was too conservative here. I'll add a bit more description of the list syntax. I originally wanted to focus primarily on GHC-specific conventions, leaving the most of ReST to the documentation I cite in the Resources section. That being said, I would be willing to add more language describing ReST itself if this would be helpful. 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 vagarenko at gmail.com Fri Oct 2 15:00:02 2015 From: vagarenko at gmail.com (Alexey Vagarenko) Date: Fri, 2 Oct 2015 21:00:02 +0600 Subject: Switching users guide to ReStructuredText In-Reply-To: <87lhbl1h52.fsf@smart-cactus.org> References: <87twq91kfm.fsf@smart-cactus.org> <601bc0b771334c97835f0f8eade954cd@DB4PR30MB030.064d.mgd.msft.net> <87lhbl1h52.fsf@smart-cactus.org> Message-ID: > Ahh, that's a good point. Indeed we can. I've uploaded an updated > build with section numbers. Perhaps also hide bullets on list items on contents page? They look redundant. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Fri Oct 2 15:13:19 2015 From: ben at smart-cactus.org (Ben Gamari) Date: Fri, 02 Oct 2015 17:13:19 +0200 Subject: Switching users guide to ReStructuredText In-Reply-To: References: <87twq91kfm.fsf@smart-cactus.org> <601bc0b771334c97835f0f8eade954cd@DB4PR30MB030.064d.mgd.msft.net> <87lhbl1h52.fsf@smart-cactus.org> Message-ID: <87fv1t1ey8.fsf@smart-cactus.org> Alexey Vagarenko writes: >> Ahh, that's a good point. Indeed we can. I've uploaded an updated >> build with section numbers. > > Perhaps also hide bullets on list items on contents page? They look > redundant. Fair point. I'll take care of 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 ben at well-typed.com Fri Oct 2 17:19:26 2015 From: ben at well-typed.com (Ben Gamari) Date: Fri, 02 Oct 2015 19:19:26 +0200 Subject: Status of recent DWARF work Message-ID: <87bnch1941.fsf@smart-cactus.org> Hello everyone! Over the last month or so I've been working on better incorporating Peter Wortmann's DWARF work into the GHC. The immedate goals are two-fold, * Allow access to reified stacks in the RTS and user programs * Introduce some basic statistical profiling functionality into the RTS While I have been slowly writing up a more general description of the work, this work has already gone too long unannounced so I'm just going to plop the list of relevant Differentials here. Note that this is also available on the Wiki (https://ghc.haskell.org/trac/ghc/wiki/DWARF/80Status), complete with hyperlinked Diffs. The hope here is that this summary will make it easier for others to review this work. Cheers, - Ben Notation -------- These are in various states of completion which I'll encode with the following designations, * MERGED: Already merged to `master`, listed here for completeness * REVIEW: Believed to be finished with no expectation of major rework being necessary. Should be in merge-worthy condition, pending code review. * RFC: Code done, builds, and tested to some extent; needs design review. * EXPLOR: Exploratory work, may not even build but included to document the expected future direction of the work. * IDEA: Just an idea, no implementation yet. I'll list the commits in the order of their logical progression, The Patches ----------- These preparatory commits address a few bugs and deficiencies in the current DWARF production implementation, * [MERGED] Phab:D1172 Dwarf: Fix DW_AT_use_UTF8 attribute * [MERGED] Phab:D1173 Dwarf: Produce {low,high}_pc attributes for compilation units * [MERGED] Phab:D1174 Dwarf: Produce .dwarf_aranges section * [MERGED] Phab:D1220 Dwarf: Ensure block length is encoded correctly These introduce DWARF parsing and stack unwinding to the RTS by introducing an optional dependency on `libdw`. This is the same library used by `perf`. * [REVIEW] Phab:D1196: Libdw: Add libdw-based stack unwinding * [REVIEW] Phab:D1197: Signals: Print backtrace on SIGUSR2 With the RTS groundwork in place we can plumb things in for use by user programs, * [REVIEW] Phab:D1198: Provide DWARF-based backtraces to Haskell-land Unfortunately up until this point we have no ability to unwind out of Haskell code back to the C stack. These commits introduce the ability to unwind all the way back to `_start`, * [REVIEW] Phab:D1224: Dwarf: Preserve stack pointer register * [REVIEW] Phab:D1225: cmm: Expose machine's stack pointer and return address registers * [REVIEW] Phab:D1223: StgStartup: Add DWARF unwinding annotations for stg_stop_thread This should be enough to get reasonable backtraces for error-handling and reporting. However, we also want profiling. For this, however, DWARF annotations alone aren't sufficient. The plan here is to incorporate a more details From the source notes produced by GHC into the DWARF vendor extension DIEs. The RTS then takes these DIEs during program initialiation and emits a representation of them to the eventlog for later use by analysis code, * [RFC] Phab:D1279: Output source notes in extended DWARF DIEs * [RFC] Phab:D1280: rts: Emit debug information about program to event log * [REVIEW] Phab:D1281: Support multiple debug output levels Now we have everything necessary to add some basic statistical profiling. Here we collect samples from heap checks and black hole block events and emit them to the event log, * [RFC] Phab:D1215: A simple statistical profiler * [RFC] Phab:D1216: StatProfile: Heap and black-hole sampling This all appears to work and I have some rather crude analysis tools which I should really clean up a bit. Ideally someone would dust off Peter's Threadscope integration as this would make for an extremely compelling performance analysis story. I also have yet to examine the impact of profiling on performance when not enabled. In principle it should be cheap enough to compile in unconditionally (although event log support is needed) but this needs to be measured. In his prototype implementation Peter also had the lovely ability to preserve simplified Core for later examination. This would be a nice thing to have but probably won't happen for 8.0. The challenge here is recording the Core fragments without introducing enormous amounts of redundancy. * [EXPLOR] Phab:D1213: Core notes * [IDEA] Record tree of Core fragments into DWARF DIEs -------------- 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 Fri Oct 2 21:18:42 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 02 Oct 2015 23:18:42 +0200 Subject: Switching users guide to ReStructuredText In-Reply-To: <87twq91kfm.fsf@smart-cactus.org> References: <87twq91kfm.fsf@smart-cactus.org> Message-ID: <1443820722.28954.1.camel@joachim-breitner.de> Hi, Am Freitag, den 02.10.2015, 15:14 +0200 schrieb Ben Gamari: > In addition to converting the DocBook to ReST, this also involved > ripping out the previously rather fragile system for building the > `ghc` manpage and describing GHC's flags in utils/mkUserGuidePart. when you say you ripped out the system for building the manpage, do you mean that you have replaced it by a different system? The manpage is important, and I would hate to see it got. (I don?t think you implied that, but I want to check nevertheless.) 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 Fri Oct 2 22:05:35 2015 From: ben at smart-cactus.org (Ben Gamari) Date: Sat, 03 Oct 2015 00:05:35 +0200 Subject: Switching users guide to ReStructuredText In-Reply-To: <1443820722.28954.1.camel@joachim-breitner.de> References: <87twq91kfm.fsf@smart-cactus.org> <1443820722.28954.1.camel@joachim-breitner.de> Message-ID: <87612p0vv4.fsf@smart-cactus.org> Joachim Breitner writes: > Hi, > > Am Freitag, den 02.10.2015, 15:14 +0200 schrieb Ben Gamari: >> In addition to converting the DocBook to ReST, this also involved >> ripping out the previously rather fragile system for building the >> `ghc` manpage and describing GHC's flags in utils/mkUserGuidePart. > > when you say you ripped out the system for building the manpage, do you > mean that you have replaced it by a different system? The manpage is > important, and I would hate to see it got. (I don?t think you implied > that, but I want to check nevertheless.) > Of course; I should have been more clear. The manpage is now generated by Sphinx from ReST source like the user guide. Hopefully the fact that it's written in ReST will mean that it will be updated more frequently than it has been in the past. 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 andres-loeh.de Sat Oct 3 10:04:14 2015 From: mail at andres-loeh.de (Andres Loeh) Date: Sat, 3 Oct 2015 12:04:14 +0200 Subject: Pattern Synonym Signature Confusion In-Reply-To: References: Message-ID: Hi. Matthew, I'm in favour of your proposed change (probably slightly in favour of option 2 compared to option 1). I must say that the whole "double constraint" syntax is very confusing no matter what. If we could somehow find a better / more explicit way to specify provided constraints, that would be even better. Cheers, Andres On Fri, Oct 2, 2015 at 1:58 PM, Matthew Pickering wrote: > I have grepped the whole of hackage. There are only 10 pattern synonym > signatures in total in three separate packages (one of them being my > own). None of them specify provided constraints, three of them specify > required constraints. Of course this is a very small sample size but > it means that there wouldn't be any widespread breakage either way > with this proposal. > > ``` > ../hackage-packages//ghc-exactprint-0.4.1.0/tests/examples/Sigs.hs:pattern > Single :: () => (Show a) => a -> [a] > ../hackage-packages//structs-0/src/Data/Struct/Internal.hs:pattern > Struct :: () => Struct t => SmallMutableArray# s Any -> t s > ../hackage-packages//structs-0/src/Data/Struct/Internal.hs:pattern Nil > :: forall t s. () => Struct t => t s > ../hackage-packages//transformations-0.2.0.0/examples/MultiRec.hs:pattern > Ref' :: Path phi ix top -> HWithRef phi top ix > ../hackage-packages//transformations-0.2.0.0/examples/MultiRec.hs:pattern > Const' :: forall top. Integer -> HWithRef AST top AExpr > ../hackage-packages//transformations-0.2.0.0/examples/MultiRec.hs:pattern > BConst' :: forall top. Bool -> HWithRef AST top BExpr > ../hackage-packages//transformations-0.2.0.0/examples/MultiRec.hs:pattern > And' :: forall top. HWithRef AST top BExpr -> HWithRef AST top BExpr > ../hackage-packages//transformations-0.2.0.0/examples/MultiRec.hs:pattern > GT' :: forall top. HWithRef AST top AExpr -> HWithRef AST top AExpr > ../hackage-packages//transformations-0.2.0.0/examples/MultiRec.hs:pattern > GT_0 :: Path AST top AExpr -> Path AST top BExpr > ../hackage-packages//transformations-0.2.0.0/examples/MultiRec.hs:pattern > Neg_0 :: Path AST top AExpr -> Path AST top AExpr > ``` > > On Thu, Oct 1, 2015 at 10:48 PM, Simon Peyton Jones > wrote: >> Matthew >> >> What you say sounds reasonable to me. I certainly don't have a strong opinion that the current design is the "right" one. >> >> Simon >> >> | -----Original Message----- >> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Matthew >> | Pickering >> | Sent: 01 October 2015 12:23 >> | To: GHC developers >> | Subject: Pattern Synonym Signature Confusion >> | >> | I think that the current state of pattern synonym signatures is quite >> | confusing, especially regarding the constraints. For those unfamiliar, >> | a signature looks like the following, >> | >> | pattern ExNumPat :: (Show b) => (Num a, Eq a) => b -> T a >> | >> | The first constraint being the "provided constraints" and the second >> | the "required constraints". >> | >> | My main concern is when only a single constraint is specified then >> | these are treated as the provided constraints. The manual gives the >> | reason that this is the "more common" choice. It seems that this >> | motivation is driven by the original ticket which had a lengthy >> | discussion about GADTs. In my experience, the opposite is true, it is >> | more common to have required constraints. >> | >> | This is true especially in a few common cases such as "pattern Foo = >> | 27", where users define pattern synonyms which have (overloaded) >> | literals on the RHS. The most general signature for such a pattern is >> | "pattern :: () => (Eq a, Num a) => a". >> | >> | For this reason, I think it would be better if either >> | >> | 1. Only specifying one constraint corresponded to the required constraints >> | 2. We required users to specify both sets of constraints, even if the >> | provided constraints are empty. >> | >> | In terms of breakage, I don't think that pattern synonym signatures >> | are widely used yet. In both schemes it is possible to write backwards >> | compatible code by writing both sets of constraints. >> | >> | I think a lot of the confusion also arises from the unusual form of >> | the signature, it is unusual to specify two sets of constraints and I >> | suspect users tends to assume that a single set of constraints is >> | either provided or required depending on what they want it to mean. >> | Forcing the specification of both, forces the user to make the >> | distinction earlier rather than trying to decipher error messages. >> | >> | Thoughts? >> | >> | Matt >> | _______________________________________________ >> | ghc-devs mailing list >> | ghc-devs at haskell.org >> | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haske >> | ll.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- >> | devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c403e493d2a54438d264 >> | 408d2ca52b5b9%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=sjc2n0Gm1A%2ffe >> | OKEpntmEYqTfbYaLvk2sb%2b2vUqIqLU%3d > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From matthewtpickering at gmail.com Sat Oct 3 13:11:20 2015 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Sat, 3 Oct 2015 14:11:20 +0100 Subject: Pattern Synonym Signature Confusion In-Reply-To: References: Message-ID: I made a ticket[1] to track the progress of this issue. I agree that the whole situation is confusing but I can't see anything much better. [1]: https://ghc.haskell.org/trac/ghc/ticket/10928#ticket On Sat, Oct 3, 2015 at 11:04 AM, Andres Loeh wrote: > Hi. > > Matthew, I'm in favour of your proposed change (probably slightly in > favour of option 2 compared to option 1). I must say that the whole > "double constraint" syntax is very confusing no matter what. If we > could somehow find a better / more explicit way to specify provided > constraints, that would be even better. > > Cheers, > Andres > > On Fri, Oct 2, 2015 at 1:58 PM, Matthew Pickering > wrote: >> I have grepped the whole of hackage. There are only 10 pattern synonym >> signatures in total in three separate packages (one of them being my >> own). None of them specify provided constraints, three of them specify >> required constraints. Of course this is a very small sample size but >> it means that there wouldn't be any widespread breakage either way >> with this proposal. >> >> ``` >> ../hackage-packages//ghc-exactprint-0.4.1.0/tests/examples/Sigs.hs:pattern >> Single :: () => (Show a) => a -> [a] >> ../hackage-packages//structs-0/src/Data/Struct/Internal.hs:pattern >> Struct :: () => Struct t => SmallMutableArray# s Any -> t s >> ../hackage-packages//structs-0/src/Data/Struct/Internal.hs:pattern Nil >> :: forall t s. () => Struct t => t s >> ../hackage-packages//transformations-0.2.0.0/examples/MultiRec.hs:pattern >> Ref' :: Path phi ix top -> HWithRef phi top ix >> ../hackage-packages//transformations-0.2.0.0/examples/MultiRec.hs:pattern >> Const' :: forall top. Integer -> HWithRef AST top AExpr >> ../hackage-packages//transformations-0.2.0.0/examples/MultiRec.hs:pattern >> BConst' :: forall top. Bool -> HWithRef AST top BExpr >> ../hackage-packages//transformations-0.2.0.0/examples/MultiRec.hs:pattern >> And' :: forall top. HWithRef AST top BExpr -> HWithRef AST top BExpr >> ../hackage-packages//transformations-0.2.0.0/examples/MultiRec.hs:pattern >> GT' :: forall top. HWithRef AST top AExpr -> HWithRef AST top AExpr >> ../hackage-packages//transformations-0.2.0.0/examples/MultiRec.hs:pattern >> GT_0 :: Path AST top AExpr -> Path AST top BExpr >> ../hackage-packages//transformations-0.2.0.0/examples/MultiRec.hs:pattern >> Neg_0 :: Path AST top AExpr -> Path AST top AExpr >> ``` >> >> On Thu, Oct 1, 2015 at 10:48 PM, Simon Peyton Jones >> wrote: >>> Matthew >>> >>> What you say sounds reasonable to me. I certainly don't have a strong opinion that the current design is the "right" one. >>> >>> Simon >>> >>> | -----Original Message----- >>> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Matthew >>> | Pickering >>> | Sent: 01 October 2015 12:23 >>> | To: GHC developers >>> | Subject: Pattern Synonym Signature Confusion >>> | >>> | I think that the current state of pattern synonym signatures is quite >>> | confusing, especially regarding the constraints. For those unfamiliar, >>> | a signature looks like the following, >>> | >>> | pattern ExNumPat :: (Show b) => (Num a, Eq a) => b -> T a >>> | >>> | The first constraint being the "provided constraints" and the second >>> | the "required constraints". >>> | >>> | My main concern is when only a single constraint is specified then >>> | these are treated as the provided constraints. The manual gives the >>> | reason that this is the "more common" choice. It seems that this >>> | motivation is driven by the original ticket which had a lengthy >>> | discussion about GADTs. In my experience, the opposite is true, it is >>> | more common to have required constraints. >>> | >>> | This is true especially in a few common cases such as "pattern Foo = >>> | 27", where users define pattern synonyms which have (overloaded) >>> | literals on the RHS. The most general signature for such a pattern is >>> | "pattern :: () => (Eq a, Num a) => a". >>> | >>> | For this reason, I think it would be better if either >>> | >>> | 1. Only specifying one constraint corresponded to the required constraints >>> | 2. We required users to specify both sets of constraints, even if the >>> | provided constraints are empty. >>> | >>> | In terms of breakage, I don't think that pattern synonym signatures >>> | are widely used yet. In both schemes it is possible to write backwards >>> | compatible code by writing both sets of constraints. >>> | >>> | I think a lot of the confusion also arises from the unusual form of >>> | the signature, it is unusual to specify two sets of constraints and I >>> | suspect users tends to assume that a single set of constraints is >>> | either provided or required depending on what they want it to mean. >>> | Forcing the specification of both, forces the user to make the >>> | distinction earlier rather than trying to decipher error messages. >>> | >>> | Thoughts? >>> | >>> | Matt >>> | _______________________________________________ >>> | ghc-devs mailing list >>> | ghc-devs at haskell.org >>> | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haske >>> | ll.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- >>> | devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c403e493d2a54438d264 >>> | 408d2ca52b5b9%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=sjc2n0Gm1A%2ffe >>> | OKEpntmEYqTfbYaLvk2sb%2b2vUqIqLU%3d >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From ryan.gl.scott at gmail.com Mon Oct 5 17:06:50 2015 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Mon, 5 Oct 2015 13:06:50 -0400 Subject: Generic instances for GHC AST Message-ID: > If the unboxed types are a problem for the automatic Generic derivation, a > manual instance could be written instead. As of recently [1], -XDeriveGeneric should be capable of handing unboxed types, so that removes one major technical limitation. I'm not sure which unboxed types GHC's API uses off of the top of my head, but if you need something other than Addr#, Char#, Double#, Int#, or Word#, it wouldn't be too difficult to add support for them. Ryan S. ----- [1] https://git.haskell.org/ghc.git/commit/6cde981a8788b225819be28659caddc35b77972d From alan.zimm at gmail.com Mon Oct 5 18:36:08 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Mon, 5 Oct 2015 20:36:08 +0200 Subject: Generic instances for GHC AST In-Reply-To: References: Message-ID: I did note this commit and intend revisiting the AST generic instances [1] in future. Alan [1] https://github.com/alanz/ghc-generic-instances On Mon, Oct 5, 2015 at 7:06 PM, Ryan Scott wrote: > > If the unboxed types are a problem for the automatic Generic derivation, > a > > manual instance could be written instead. > > As of recently [1], -XDeriveGeneric should be capable of handing > unboxed types, so that removes one major technical limitation. I'm not > sure which unboxed types GHC's API uses off of the top of my head, but > if you need something other than Addr#, Char#, Double#, Int#, or > Word#, it wouldn't be too difficult to add support for them. > > > Ryan S. > ----- > [1] > https://git.haskell.org/ghc.git/commit/6cde981a8788b225819be28659caddc35b77972d > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sumit.sahrawat.apm13 at iitbhu.ac.in Tue Oct 6 10:39:59 2015 From: sumit.sahrawat.apm13 at iitbhu.ac.in (Sumit Sahrawat, Maths & Computing, IIT (BHU)) Date: Tue, 6 Oct 2015 16:09:59 +0530 Subject: [Haskell-cafe] A GC'd heap using weak pointers In-Reply-To: References: Message-ID: This would be well recieved on ghc-devs mailing list. Adding to cc. On 6 October 2015 at 15:55, Thomas Koster wrote: > Good afternoon list, > > I am implementing a simple, interpreted language that needs a garbage- > collected heap for storage. Like most discussions on memory management, > I use the term "heap" by analogy - the actual data structure is not > necessarily a true heap. > > My Heap type is basically a map of "addresses" (Int) to values. Values > may themselves contain addresses, perhaps recursively to each other > (like letrec). The extra field in Heap stores the next unused address, > used to allocate fresh slots, as you can see in "heapAlloc". > > > type Address = Int > > data Value = ...things with Addresses... > > data Heap = Heap !Address (Map Address Value) > > > > heapAlloc :: Heap -> (Address, Heap) > > heapAlloc (Heap nextFreeAddr binds) = > > (nextFreeAddr, Heap (succ nextFreeAddr) binds) > > There is also a stack of roots and an expression under evaluation. > > > type Stack = [...things with Addresses...] > > data Expr = ...things with Addresses... > > The function I need to write is: > > > heapGC :: [Address] -> Heap -> Heap > > heapGC roots heap = ...collect unreachable values from heap... > > Rather than re-invent this particularly complex wheel, I am wondering > if I could use GHC weak pointers and have the GHC runtime collect values > in my heap for me. Something like this: > > > type Address = Int > > data Reference = Reference Address > > data Value = ...things with References... > > data Heap = Heap !Address (Map Address (Weak Value)) > > > > heapAlloc :: Heap -> (Reference, Heap) > > heapAlloc (Heap nextFreeAddr binds) = > > (Reference nextFreeAddr, Heap (succ nextFreeAddr) binds) > > > > heapStore :: Reference -> Value -> Heap -> IO Heap > > heapStore ref@(Reference addr) val (Heap nextFreeAddr binds) = do > > weakVal <- mkWeak ref val Nothing > > return $ Heap nextFreeAddr (Map.insert addr weakVal binds) > > Note the new type, Reference. This replaces Address everywhere except > in the heap's internal structure, which continues to use Address. > Reference values are opaque, unique and obtained from the heap using > heapAlloc. > > The idea is that only two things should cause Values to stay alive: > 1. reachable holders of Reference (by GHC's definition of "reachable"), > 2. ordinary Haskell closures arising from stepping the interpreter. > "Being in the Heap" should not be enough to keep a Value alive. Then, > my heapGC function should only have to prune dead addresses from the > map. > > I am having trouble getting a proof-of-concept working (I am unable to > observe any finalizers running, ever), but before I get into that, is > this idea sound? Has somebody else implemented this in a library > already? > > Thanks, > Thomas Koster > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -- Regards Sumit Sahrawat -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Oct 6 12:07:09 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 6 Oct 2015 12:07:09 +0000 Subject: ghc-7.10 branch broken Message-ID: <4013a7e0528a47ab9c900f045d1edac2@DB4PR30MB030.064d.mgd.msft.net> On the ghc-7.10 branch, PPC.Regs has duplicate exports (see below). The offending lines are fReg, sp, r3, r4, r27, r28, r30, r0, sp, r3, r4, r27, r28, r30, tmpReg, and indeed there are duplicates. Why? git branch -v * ghc-7.10 e22d7dc nativeGen PPC: fix > 16 bit offsets in stack handling master f17992a [behind 1397] Updaete perf numbers for 32-bit machines wip/T10527 eb66575 Use lazy substitution in simplCast wip/T10527-2 9e4908b Add an ambient Id substitution to Subst Simon compiler/nativeGen/PPC/Regs.hs:41:13: Warning: 'sp' is exported by 'sp' and 'sp' compiler/nativeGen/PPC/Regs.hs:41:17: Warning: 'r3' is exported by 'r3' and 'r3' compiler/nativeGen/PPC/Regs.hs:41:21: Warning: 'r4' is exported by 'r4' and 'r4' -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Oct 6 13:17:16 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 6 Oct 2015 13:17:16 +0000 Subject: [GHC] #10928: Refine pattern synonym signatures In-Reply-To: <064.327b3025c7154316da46ef8608c3d7a6@haskell.org> References: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> <064.327b3025c7154316da46ef8608c3d7a6@haskell.org> Message-ID: <759e6b015f5342bb83b89e3dca44b947@DB4PR30MB030.064d.mgd.msft.net> I'm getting 501 "Internal server error" from Trac. Simon | -----Original Message----- | From: ghc-tickets [mailto:ghc-tickets-bounces at haskell.org] On Behalf Of GHC | Sent: 06 October 2015 13:57 | Cc: ghc-tickets at haskell.org | Subject: Re: [GHC] #10928: Refine pattern synonym signatures | | #10928: Refine pattern synonym signatures | -------------------------------------+---------------------------------- | -------------------------------------+--- | Reporter: mpickering | Owner: | Type: bug | Status: new | Priority: normal | Milestone: 8.0.1 | Component: Compiler | Version: 7.10.2 | Resolution: | Keywords: | Operating System: Unknown/Multiple | Architecture: | | Unknown/Multiple | Type of failure: Other | Test Case: | Blocked By: | Blocking: | Related Tickets: | Differential Rev(s): | -------------------------------------+---------------------------------- | -------------------------------------+--- | | Comment (by rwbarton): | | One thing that bothers me about the current syntax is that `C1 a => C2 a | => T a` in general already has a meaning. It's the same thing as `(C1 a, | C2 a) => T a`. I don't know if this is actually valid Haskell 98 (I | suspect not), but GHC accepts it without any language flags. | | Just to throw out another option, long ago user "ski" on IRC suggested a | syntax for existentials-plus-constraints, dual to constrained polymorphic | values. The idea is dual to {{{ forall a. C a => T a }}} which is a sort | of function that accepts a `C a` constraint and produces a value, we have | {{{ exists a. C a *> T a }}} which is a sort of pair of a `C a` | constraint (dictionary) and a value. | (Mnemonic: `*` is like a pair and `>` is from `=>`. Not sure I am | convinced myself.) | | I'm not sure whether this applies directly to pattern synonyms since a | pattern is not really the same thing as a value. But, we could at least use | the idea of two different bits of syntax for provided and required | constraints, e.g., {{{ pattern P :: (Eq a, Num a) => (Show a, Show b) *> b | -> T a }}} Here I am thinking of `(Eq a, Num a)` as in negative position | and `(Show a, Show b)` in positive position, so tentatively using the | corresponding `=>` and `*>`. | | Advantages: | | * Does not use syntax that already has another meaning (`C1 a => C2 a => T | a`) | | * You can write patterns with either empty required constraints or empty | provided constraints (`Cr a => T a`, `Cp a *> T a`) without having to add | an empty context | | * Not extremely verbose like Richard's verbose syntax | | Disadvantages: | | * Another funny bit of syntax to learn. But at least it appears in only | one context. | | -- | Ticket URL: | | GHC | | The Glasgow Haskell Compiler | _______________________________________________ | ghc-tickets mailing list | ghc-tickets at haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell | .org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | tickets&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c36aef97285934ba72d | f008d2ce4ded93%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=T8hBjZDRWulMjNrG | nrLd5TRA1cR8yEmmnuO9LfNjNG8%3d From trp at bluewin.ch Tue Oct 6 16:06:43 2015 From: trp at bluewin.ch (Peter Trommler) Date: Tue, 6 Oct 2015 18:06:43 +0200 Subject: ghc-7.10 branch broken In-Reply-To: <4013a7e0528a47ab9c900f045d1edac2@DB4PR30MB030.064d.mgd.msft.net> References: <4013a7e0528a47ab9c900f045d1edac2@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Dear Simon and Ben, The line starting in `sp` must be deleted. It looks like a merge problem in commit e22d7dc434b64709a4b19b11f2e0a41676c04035. I attached a patch. @Ben: Would you mind committing it on branch ghc-7.10 for me? Thanks, Peter > On 06.10.2015, at 14:07, Simon Peyton Jones wrote: > > On the ghc-7.10 branch, PPC.Regs has duplicate exports (see below). The offending lines are > > fReg, > sp, r3, r4, r27, r28, r30, > r0, sp, r3, r4, r27, r28, r30, > tmpReg, > and indeed there are duplicates. Why? > > git branch -v > * ghc-7.10 e22d7dc nativeGen PPC: fix > 16 bit offsets in stack handling > master f17992a [behind 1397] Updaete perf numbers for 32-bit machines > wip/T10527 eb66575 Use lazy substitution in simplCast > wip/T10527-2 9e4908b Add an ambient Id substitution to Subst > Simon > > > > compiler/nativeGen/PPC/Regs.hs:41:13: Warning: > > ?sp? is exported by ?sp? and ?sp? > > > > compiler/nativeGen/PPC/Regs.hs:41:17: Warning: > > ?r3? is exported by ?r3? and ?r3? > > > > compiler/nativeGen/PPC/Regs.hs:41:21: Warning: > > ?r4? is exported by ?r4? and ?r4? > > > > _______________________________________________ > 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: 0001-Fix-merge-error.patch Type: application/octet-stream Size: 681 bytes Desc: not available URL: From dan.doel at gmail.com Thu Oct 8 01:20:03 2015 From: dan.doel at gmail.com (Dan Doel) Date: Wed, 7 Oct 2015 21:20:03 -0400 Subject: Unlifted data types In-Reply-To: References: <1441353701-sup-9422@sabre> <6707b31c94d44af89ba2a90580ac46ce@DB4PR30MB030.064d.mgd.msft.net> <6e2bcecf1a284c62a656e80992e9862e@DB4PR30MB030.064d.mgd.msft.net> <0196B07B-156B-4731-B0A1-CE7A892E0680@cis.upenn.edu> <072d804f206c47aeb49ca7d610d120e5@DB4PR30MB030.064d.mgd.msft.net> <3481E4D1-F4DD-47BA-9818-665F22928CAD@cis.upenn.edu> Message-ID: I've added a section on parametric levity polymorphism to the wiki. Sorry it took so long. I might add some thoughts about first-class `!a` being the only semantic hole in our current strict data type situation later if I remember to do so. On Thu, Sep 10, 2015 at 10:26 AM, Richard Eisenberg wrote: > These observations from Ed and Dan are quite helpful. Could one of you put > them on the wiki page? I hadn't considered the possibility of truly > parametric levity polymorphism. > > Thanks! > Richard > > On Sep 9, 2015, at 3:30 PM, Edward Kmett wrote: > > I think ultimately the two views of levity that we've been talking diverge > along the same lines as the pi vs forall discussion from your Levity > polymorphism talk. > > I've been focused entirely on situations where forall suffices, and no > distinction is needed in how you compile for both levities. > > Maybe could be polymorphic using a mere forall in the levity of the boxed > argument it carries as it doesn't care what it is, it never forces it, > pattern matching on it just gives it back when you pattern match on it. > > Eq or Ord could just as easily work over anything boxed. The particular Eq > _instance_ needs to care about the levity. > > Most of the combinators for working with Maybe do need to care about that > levity however. > > e.g. consider fmap in Functor, the particular instances would care. Because > you ultimately wind up using fmap to build 'f a' values and those need to > know how the let binding should work. There seems to be a pi at work there. > Correct operational behavior would depend on the levity. > > But if we look at what inference should probably grab for the levity of > Functor: > > you'd get: > > class Functor (l : Levity) (l' : Levity') (f :: GC l -> GC l') where > fmap :: forall a b. (a :: GC l) (b :: GC l). (a -> b) -> f a -> f b > > Baed on the notion that given current practices, f would cause us to pick a > common kind for a and b, and the results of 'f'. Depending on how and if we > decided to default to * unless annotated in various situations would drive > this closer and closer to the existing Functor by default. > > These are indeed distinct functors with distinct operational behavior, and > we could implement each of them by supplying separate instances, as the > levity would take part in the instance resolution like any other kind > argument. > > Whether we could expect an average Haskeller to be willing to do so is an > entirely different matter. > > -Edward > > > On Wed, Sep 9, 2015 at 12:44 PM, Dan Doel wrote: >> >> On Wed, Sep 9, 2015 at 9:03 AM, Richard Eisenberg >> wrote: >> > No functions (excepting `error` and friends) are truly levity >> > polymorphic. >> >> I was talking with Ed Kmett about this yesterday, and he pointed out >> that this isn't true. There are a significant array of levity >> polymorphic functions having to do with reference types. They simply >> shuffle around pointers with the right calling convention, and don't >> really care what levity their arguments are, because they're just >> operating uniformly either way. So if we had: >> >> MVar# :: forall (l :: Levity). * -> TYPE (Boxed l) -> TYPE (Boxed >> Unlifted) >> >> then: >> >> takeMVar :: forall s (l :: Levity) (a :: TYPE (Boxed l)). MVar# s >> l a -> State# s -> (# State# s, a #) >> putMVar :: forall s (l :: Levity) (a :: Type (Boxed l)). MVar# s l >> a -> a -> State# s -> State# s >> >> are genuinely parametric in l. And the same is true for MutVar#, >> Array#, MutableArray#, etc. >> >> I think data type constructors are actually parametric, too (ignoring >> data with ! in them for the moment; the underlying constructors of >> those). Using a constructor just puts the pointers for the fields in >> the type, and matching on a constructor gives them back. They don't >> need to care whether their fields are lifted or not, they just >> preserve whatever the case is. >> >> But this: >> >> > We use levity polymorphism in the types to get GHC to use its existing >> > type inference to infer strictness. By the time type inference is done, we >> > must ensure that no levity polymorphism remains, because the code generator >> > won't be able to deal with it. >> >> Is not parametric polymorphism; it is ad-hoc polymorphism. It even has >> the defaulting step from type classes. Except the ad-hoc has been >> given the same notation as the genuinely parametric, so you can no >> longer identify the latter. (I'm not sure I'm a great fan of the >> ad-hoc part anyway, to be honest.) >> >> -- Dan >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > From simonpj at microsoft.com Thu Oct 8 10:02:59 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 8 Oct 2015 10:02:59 +0000 Subject: Unlifted data types In-Reply-To: References: <1441353701-sup-9422@sabre> <6707b31c94d44af89ba2a90580ac46ce@DB4PR30MB030.064d.mgd.msft.net> <6e2bcecf1a284c62a656e80992e9862e@DB4PR30MB030.064d.mgd.msft.net> <0196B07B-156B-4731-B0A1-CE7A892E0680@cis.upenn.edu> <072d804f206c47aeb49ca7d610d120e5@DB4PR30MB030.064d.mgd.msft.net> <3481E4D1-F4DD-47BA-9818-665F22928CAD@cis.upenn.edu> Message-ID: <89504f03668b4bb18d9d2ef9c2fe5701@DB4PR30MB030.064d.mgd.msft.net> | I've added a section on parametric levity polymorphism to the wiki. | Sorry it took so long. What's the wiki page? Simon | | I might add some thoughts about first-class `!a` being the only | semantic hole in our current strict data type situation later if I | remember to do so. From simonpj at microsoft.com Thu Oct 8 10:42:31 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 8 Oct 2015 10:42:31 +0000 Subject: Floating and CorePrep Message-ID: Luke asks | Also, can you explain why CorePrep does some floating of its own? I thought that there was a good reason that CorePrep does floating, but the more I tried to explain it, the less sense the explanation made. So here's the reasoning. Maybe I'm missing things, or maybe there's an opportunity here to simplify GHC. So I'm cc'ing ghc-devs. CorePrep convets to ANF. So if we have this: x = f (g y) we might naively generate this x = let a = g y in f a Instead CorePrep generates this a = g y x = f a However now I think about it again, I'm suddenly not sure why this is important. * If x is a lazy thunk, the floated version will allocate 'a' early. So we should only float if (f a) is a head-normal form. (And that happens; see CorePrep.wantFloatNested). But if (f a) is a HNF, the simplifier will already have ANF'd it in prepareRhs. * If x is marked demanded (strict), then the naive ANF'ing might generate case (let a = g y in f a) of .... because CorePrep converts the 'let x' into a case. But that's OK because I think the code generator is fine with a let nested inside a case like that. So, for nested bindings, maybe we can simply NEVER do floating? Ah, there is on gotcha. Consider x = f raise# where f has arity 2. Currently raise# responds True to Id.hasNoBinding, so CorePrep must eta-expand to x = f (\x. raise# x) and now we really would like to ANF to z = \x. raise# x x = f a because the (f a) is not a thunk, but it would be if we introduced a nested let. Bother. For top level, things are slightly different. Here if we see x = f (g y) we do want to float to get a = g y x = f a because not the allocation of 'a' is done statically rather than dynamically. This is particularly important for large static lists e.g. p = f [a,b,c,d,e] when we want all those cons cells to be statically allocated. This is all a bit unsatisfactory. It would be much cleaner if all floating was done by the simplifier, and CorePrep did none. And I think it'd be worth a try at doing that. I think the needful stuff would be: * Always saturate hsaNoBinding functions in Core, not just at CorePrep * Be more aggressive about floating top-level bindings like 'p' in the simplifier I'm not likely to undertake this myself soon, but I could advise. Simon From fryguybob at gmail.com Thu Oct 8 13:07:54 2015 From: fryguybob at gmail.com (Ryan Yates) Date: Thu, 8 Oct 2015 09:07:54 -0400 Subject: Unlifted data types In-Reply-To: <89504f03668b4bb18d9d2ef9c2fe5701@DB4PR30MB030.064d.mgd.msft.net> References: <1441353701-sup-9422@sabre> <6707b31c94d44af89ba2a90580ac46ce@DB4PR30MB030.064d.mgd.msft.net> <6e2bcecf1a284c62a656e80992e9862e@DB4PR30MB030.064d.mgd.msft.net> <0196B07B-156B-4731-B0A1-CE7A892E0680@cis.upenn.edu> <072d804f206c47aeb49ca7d610d120e5@DB4PR30MB030.064d.mgd.msft.net> <3481E4D1-F4DD-47BA-9818-665F22928CAD@cis.upenn.edu> <89504f03668b4bb18d9d2ef9c2fe5701@DB4PR30MB030.064d.mgd.msft.net> Message-ID: https://ghc.haskell.org/trac/ghc/wiki/UnliftedDataTypes On Thu, Oct 8, 2015 at 6:02 AM, Simon Peyton Jones wrote: > | I've added a section on parametric levity polymorphism to the wiki. > | Sorry it took so long. > > What's the wiki page? > > Simon > | > | I might add some thoughts about first-class `!a` being the only > | semantic hole in our current strict data type situation later if I > | remember to do so. > _______________________________________________ > 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 marek.28.93 at gmail.com Thu Oct 8 14:22:01 2015 From: marek.28.93 at gmail.com (Marek Wawrzos) Date: Thu, 8 Oct 2015 16:22:01 +0200 Subject: Fwd: Compiling Core Haskell using GHC API In-Reply-To: References: Message-ID: Hello, I'm trying to compile some module with GHC API. I'm going to feed GHC with Core generated by me. So far is noticed, that function compileCoreToObj ends with an runtime error on each call. In spide of this function produces some *.o and *.hi files. However, produced interface file does not contain any item in exports field, what makes compiled module unusable. Because of this problem, I tried to achieve my goal by using steps described here: https://wiki.haskell.org/GHC/As_a_library (the second example) I was able to print out Core produced form file. If I'm not wrong, modifying structures passing on between sequent calls does not effect on produced *.hi and *.o files. Both files are generated by `load LoadAllTargets' call, and further calls (parseModule, loadModule, ...) does not effect on generated files. Could You give me any advices in that topic? Am I right about compileCoreToObj and functions mentioned above? Best Regards, Marek -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Thu Oct 8 12:36:00 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Thu, 8 Oct 2015 08:36:00 -0400 Subject: Unlifted data types In-Reply-To: <89504f03668b4bb18d9d2ef9c2fe5701@DB4PR30MB030.064d.mgd.msft.net> References: <1441353701-sup-9422@sabre> <6707b31c94d44af89ba2a90580ac46ce@DB4PR30MB030.064d.mgd.msft.net> <6e2bcecf1a284c62a656e80992e9862e@DB4PR30MB030.064d.mgd.msft.net> <0196B07B-156B-4731-B0A1-CE7A892E0680@cis.upenn.edu> <072d804f206c47aeb49ca7d610d120e5@DB4PR30MB030.064d.mgd.msft.net> <3481E4D1-F4DD-47BA-9818-665F22928CAD@cis.upenn.edu> <89504f03668b4bb18d9d2ef9c2fe5701@DB4PR30MB030.064d.mgd.msft.net> Message-ID: On Oct 8, 2015, at 6:02 AM, Simon Peyton Jones wrote: > What's the wiki page? https://ghc.haskell.org/trac/ghc/wiki/UnliftedDataTypes From ezyang at mit.edu Thu Oct 8 17:02:17 2015 From: ezyang at mit.edu (Edward Z. Yang) Date: Thu, 08 Oct 2015 10:02:17 -0700 Subject: Fwd: Compiling Core Haskell using GHC API In-Reply-To: References: Message-ID: <1444323665-sup-2038@sabre> If we look at the source code for hscCompileCore, it would seem that it creates a ModGuts with mkModGuts which has an empty mg_exports, which means that in all cases there will be no exported items. So it's not very useful! You should file a bug. We should fix this, but in the mean time, you could simply copypaste the definition of hscCompileCore, and modify it so that you do set up the ModGuts correctly with a real mg_exports field. Edward Excerpts from Marek Wawrzos's message of 2015-10-08 07:22:01 -0700: > Hello, > > I'm trying to compile some module with GHC API. I'm going to feed GHC with > Core generated by me. > > So far is noticed, that function compileCoreToObj ends with an runtime > error on each call. In spide of this function produces some *.o and *.hi > files. However, produced interface file does not contain any item in > exports field, what makes compiled module unusable. > > Because of this problem, I tried to achieve my goal by using steps > described here: https://wiki.haskell.org/GHC/As_a_library (the second > example) > I was able to print out Core produced form file. If I'm not wrong, > modifying structures passing on between sequent calls does not effect on > produced *.hi and *.o files. Both files are generated by `load > LoadAllTargets' call, and further calls (parseModule, loadModule, ...) does > not effect on generated files. > > Could You give me any advices in that topic? Am I right about > compileCoreToObj and functions mentioned above? > > Best Regards, > Marek From david.feuer at gmail.com Thu Oct 8 23:25:40 2015 From: david.feuer at gmail.com (David Feuer) Date: Thu, 8 Oct 2015 19:25:40 -0400 Subject: Context for typed holes In-Reply-To: References: Message-ID: Unless something has changed really recently that I've missed, the typed holes messages are missing some really important information: instance information for types in scope. When I am trying to fill in a hole, I look to the "relevant bindings" to show me what pieces I have available to use. Those pieces don't include contexts! Is there something fundamentally hard about adding this information? I'd only want instance information for type variables--providing it for concrete types would make too much noise. I'd also want information on equality constraints, of course. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Fri Oct 9 16:31:39 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Fri, 9 Oct 2015 12:31:39 -0400 Subject: Template Haskell bikeshedding: UnboundVarE or not? Message-ID: <3B06B5AD-9DC2-4D64-BD1E-BFA75D874CB5@cis.upenn.edu> Hi devs, Jan Stolarek has been hard at work allowing Template Haskell to deal with holes in expressions. Thanks, Janek. In this patch, any unbound variable is treated like a hole, which is exactly the way that GHC normally treats unbound variables these days. This is great -- it allows TH quotes to work with unbound names. The question is this: suppose a user writes [| x |], where x is unbound. Should that produce a (VarE (mkName "x")) or an (UnboundVarE (mkName "x")), where UnboundVarE is a new constructor for Exp? Reasons for UnboundVarE: - It communicates information GHC has to clients of TH. Reasons against UnboundVarE: - UnboundVarE and VarE are treated identically in *splices*. The only point of UnboundVarE is in the output of *quotes*. This may be confusing to users. - The information communicated by GHC to TH can be gotten by other means. Specifically, if you try to `reify` an unbound name, you'll get an error (which can be caught gracefully). Bound names `reify` correctly. So a TH client can figure out the boundedness of a variable, albeit awkwardly and in a monad. This counts as a reason against UnboundVarE because the distinction between UnboundVarE and VarE is technically redundant. (You could also probably learn this information by looking to see if a Name has a Unique attached to it. But that's a bit dirty. At least it's pure, though.) So, what do you think? To UnboundVarE or not to UnboundVarE, that is the question. Ticket: https://ghc.haskell.org/trac/ghc/ticket/10267 Diff: https://phabricator.haskell.org/D835 Thanks! Richard From simonpj at microsoft.com Fri Oct 9 21:31:10 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 9 Oct 2015 21:31:10 +0000 Subject: Template Haskell bikeshedding: UnboundVarE or not? In-Reply-To: <3B06B5AD-9DC2-4D64-BD1E-BFA75D874CB5@cis.upenn.edu> References: <3B06B5AD-9DC2-4D64-BD1E-BFA75D874CB5@cis.upenn.edu> Message-ID: My instinct is UnboundVarE: it's explicit, and that is seldom bad. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Richard | Eisenberg | Sent: 09 October 2015 17:32 | To: ghc-devs at haskell.org Devs | Subject: Template Haskell bikeshedding: UnboundVarE or not? | | Hi devs, | | Jan Stolarek has been hard at work allowing Template Haskell to deal with | holes in expressions. Thanks, Janek. In this patch, any unbound variable | is treated like a hole, which is exactly the way that GHC normally treats | unbound variables these days. This is great -- it allows TH quotes to work | with unbound names. | | The question is this: suppose a user writes [| x |], where x is unbound. | Should that produce a (VarE (mkName "x")) or an (UnboundVarE (mkName | "x")), where UnboundVarE is a new constructor for Exp? | | Reasons for UnboundVarE: | - It communicates information GHC has to clients of TH. | | Reasons against UnboundVarE: | - UnboundVarE and VarE are treated identically in *splices*. The only | point of UnboundVarE is in the output of *quotes*. This may be confusing | to users. | - The information communicated by GHC to TH can be gotten by other means. | Specifically, if you try to `reify` an unbound name, you'll get an error | (which can be caught gracefully). Bound names `reify` correctly. So a TH | client can figure out the boundedness of a variable, albeit awkwardly and | in a monad. This counts as a reason against UnboundVarE because the | distinction between UnboundVarE and VarE is technically redundant. (You | could also probably learn this information by looking to see if a Name has | a Unique attached to it. But that's a bit dirty. At least it's pure, | though.) | | So, what do you think? To UnboundVarE or not to UnboundVarE, that is the | question. | | Ticket: https://ghc.haskell.org/trac/ghc/ticket/10267 | Diff: https://phabricator.haskell.org/D835 | | Thanks! | Richard | | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haske | ll.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c31384b65553a47651fa | a08d2d0c721fc%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=WBXdy40hgMEz3EP | n5OX8OXc30PkNJIY6B91Q0BDb%2beY%3d From dan.doel at gmail.com Sat Oct 10 00:42:04 2015 From: dan.doel at gmail.com (Dan Doel) Date: Fri, 9 Oct 2015 20:42:04 -0400 Subject: Template Haskell bikeshedding: UnboundVarE or not? In-Reply-To: References: <3B06B5AD-9DC2-4D64-BD1E-BFA75D874CB5@cis.upenn.edu> Message-ID: I'm not much of a TH user, but this would be my choice, too. Requiring error/exception handling to get a piece of information doesn't seem like a typical design for Haskell libraries (and I'm happy that's the case). On Fri, Oct 9, 2015 at 5:31 PM, Simon Peyton Jones wrote: > My instinct is UnboundVarE: it's explicit, and that is seldom bad. > > Simon > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Richard > | Eisenberg > | Sent: 09 October 2015 17:32 > | To: ghc-devs at haskell.org Devs > | Subject: Template Haskell bikeshedding: UnboundVarE or not? > | > | Hi devs, > | > | Jan Stolarek has been hard at work allowing Template Haskell to deal with > | holes in expressions. Thanks, Janek. In this patch, any unbound variable > | is treated like a hole, which is exactly the way that GHC normally treats > | unbound variables these days. This is great -- it allows TH quotes to work > | with unbound names. > | > | The question is this: suppose a user writes [| x |], where x is unbound. > | Should that produce a (VarE (mkName "x")) or an (UnboundVarE (mkName > | "x")), where UnboundVarE is a new constructor for Exp? > | > | Reasons for UnboundVarE: > | - It communicates information GHC has to clients of TH. > | > | Reasons against UnboundVarE: > | - UnboundVarE and VarE are treated identically in *splices*. The only > | point of UnboundVarE is in the output of *quotes*. This may be confusing > | to users. > | - The information communicated by GHC to TH can be gotten by other means. > | Specifically, if you try to `reify` an unbound name, you'll get an error > | (which can be caught gracefully). Bound names `reify` correctly. So a TH > | client can figure out the boundedness of a variable, albeit awkwardly and > | in a monad. This counts as a reason against UnboundVarE because the > | distinction between UnboundVarE and VarE is technically redundant. (You > | could also probably learn this information by looking to see if a Name has > | a Unique attached to it. But that's a bit dirty. At least it's pure, > | though.) > | > | So, what do you think? To UnboundVarE or not to UnboundVarE, that is the > | question. > | > | Ticket: https://ghc.haskell.org/trac/ghc/ticket/10267 > | Diff: https://phabricator.haskell.org/D835 > | > | Thanks! > | Richard > | > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs at haskell.org > | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haske > | ll.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- > | devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c31384b65553a47651fa > | a08d2d0c721fc%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=WBXdy40hgMEz3EP > | n5OX8OXc30PkNJIY6B91Q0BDb%2beY%3d > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From alexander at plaimi.net Sat Oct 10 10:58:11 2015 From: alexander at plaimi.net (Alexander Berntsen) Date: Sat, 10 Oct 2015 12:58:11 +0200 Subject: (Don't) remove unused flags? [#10935] Message-ID: <5618EF43.20904@plaimi.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I want to tackle [0], but I disagree with the proposed solution. At least with regards to the first three flags. Instead, I want to make the flags work. Thoughts? [0] - -- Alexander alexander at plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJWGO9CAAoJENQqWdRUGk8BUiMP/1PfMfXr4p1jWCasPHvWMrXj Ep0/e5boThJs3bsD+xf1eVl2NIjT4dAONO7zI7PkohvkjbgjXGWFE+SDJKI6iWXV Kb06GM73q7vBL3sL45SFy8/tofn0J//jSAkXoNzJ64Nlny2xXxLg91e0mj79fbGx Y3rwv7SB9ZpBm/ov41PtiX5+5hc3mWDwZS/+UIUj1tUdfFHk8BR4HMEXEfihU0mh yrxdPHWsAYmIPYfoE/9HAbQ6SqynUErW8kOrr47/kZO0yBl2xkK7XvA7I0fy0upG HS6teTcxtVmzFFPBrDvZGEz0cawT56/jpMBNHNgkLUOF3lssjLpMCl3KyoJXV9PB kaHxICISubBsLoIZti/MQBshjwbLzT6MCItMIlD77w21mp3MEqiFQ9+M+ePCwGp8 WmX5iAFc8ze6bku51cYGSxiIjIMcpJVNI4Sr+8aRFuFBUqiOe/GKn0t5UvyPMekb FTcYLH4JKjBEXkkuF2WWr+Ey+d87XQ1ioN+wwg+v2pFGP4NtwepoNbYsQG4WbHYx gFAdWAnirsdSrio5VTZWVz05ouIIUG6CtDM6QfaC3EUCLDWePz+fd63U+gjO3A4s AW8Rfm/rDQBNs7USIgODjKdDtGwAJM4i+PxypWW8rg9sfOBwGEcS8XngphxWb6pp bHkPHy6k+vGOrZUUSMFb =B8HY -----END PGP SIGNATURE----- From d at vidr.cc Mon Oct 12 08:09:44 2015 From: d at vidr.cc (David A Roberts) Date: Mon, 12 Oct 2015 08:09:44 +0000 Subject: Applicative Comprehensions Message-ID: Hi, I raised this question on #haskell, and was advised that this was probably the best place to discuss. I see that Applicative Do is scheduled for GHC 8.0 [1], and was hoping that this might also enable support for Applicative Comprehensions [2]. Is this likely to be the case? If not, would it be difficult to extend the support for Applicative Do to also handle comprehensions? I'm willing to submit patches if necessary, but I'm not at all familiar with GHC internals, so would need some guidance. I understand that comprehensions tend not to be used much in idiomatic Haskell, but I find them to be useful for implementing DSLs, so would really like to see this be supported. For example, a matrix could be written in a familiar notation: > [ i + 2*j | i <- rows, j <- cols ] which is a little more readable (to those not familiar with Haskell) than > (\i j -> i + 2*j) <$> row <*> cols or > do { i <- rows; j <- cols; return (i + 2*j) } [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1#LandedinHEAD [2] https://ghc.haskell.org/trac/ghc/wiki/GeneralizedMonadComprehensions#Applicativefunctor -- David A Roberts https://davidar.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Mon Oct 12 08:58:05 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 12 Oct 2015 10:58:05 +0200 Subject: Applicative Comprehensions In-Reply-To: References: Message-ID: <1444640285.2250.9.camel@joachim-breitner.de> Hi, Am Montag, den 12.10.2015, 08:09 +0000 schrieb David A Roberts: > I understand that comprehensions tend not to be used much in > idiomatic Haskell, quite contrary! I use them extensively in real-world-projects, and I claim to write idomatic code :-) 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 Mon Oct 12 09:08:00 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 12 Oct 2015 09:08:00 +0000 Subject: Applicative Comprehensions In-Reply-To: References: Message-ID: <3360432041bd475ea3b8b7b7a0125fdf@DB4PR30MB030.064d.mgd.msft.net> Sounds reasonable to me. Do-notation and comprehension notation are really just syntactic sugar for the same thing. Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of David A Roberts Sent: 12 October 2015 09:10 To: ghc-devs at haskell.org Subject: Applicative Comprehensions Hi, I raised this question on #haskell, and was advised that this was probably the best place to discuss. I see that Applicative Do is scheduled for GHC 8.0 [1], and was hoping that this might also enable support for Applicative Comprehensions [2]. Is this likely to be the case? If not, would it be difficult to extend the support for Applicative Do to also handle comprehensions? I'm willing to submit patches if necessary, but I'm not at all familiar with GHC internals, so would need some guidance. I understand that comprehensions tend not to be used much in idiomatic Haskell, but I find them to be useful for implementing DSLs, so would really like to see this be supported. For example, a matrix could be written in a familiar notation: > [ i + 2*j | i <- rows, j <- cols ] which is a little more readable (to those not familiar with Haskell) than > (\i j -> i + 2*j) <$> row <*> cols or > do { i <- rows; j <- cols; return (i + 2*j) } [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1#LandedinHEAD [2] https://ghc.haskell.org/trac/ghc/wiki/GeneralizedMonadComprehensions#Applicativefunctor -- David A Roberts https://davidar.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From roma at ro-che.info Mon Oct 12 09:14:00 2015 From: roma at ro-che.info (Roman Cheplyaka) Date: Mon, 12 Oct 2015 12:14:00 +0300 Subject: Applicative Comprehensions In-Reply-To: References: Message-ID: <561B79D8.6030700@ro-che.info> I like this idea because having the pure function call at the beginning (rather than at the end, as with do-notation) is more consistent with the original <$>,<*>-notation. It only slightly bothers me that the bracket notation in this form has nothing to do with lists, so that may be a bit confusing. But this is already true for monad comprehensions. It might make more sense to reuse the parallel list comprehension syntax (https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/syntax-extns.html#parallel-list-comprehensions), as applicatives are "parallel". So, [ i + 2*j | i <- rows | j <- cols ]. On 10/12/2015 11:09 AM, David A Roberts wrote: > Hi, > > I raised this question on #haskell, and was advised that this was > probably the best place to discuss. > > I see that Applicative Do is scheduled for GHC 8.0 [1], and was hoping > that this might also enable support for Applicative Comprehensions [2]. > Is this likely to be the case? If not, would it be difficult to extend > the support for Applicative Do to also handle comprehensions? I'm > willing to submit patches if necessary, but I'm not at all familiar with > GHC internals, so would need some guidance. > > I understand that comprehensions tend not to be used much in idiomatic > Haskell, but I find them to be useful for implementing DSLs, so would > really like to see this be supported. For example, a matrix could be > written in a familiar notation: > >> [ i + 2*j | i <- rows, j <- cols ] > > which is a little more readable (to those not familiar with Haskell) than > >> (\i j -> i + 2*j) <$> row <*> cols > > or > >> do { i <- rows; j <- cols; return (i + 2*j) } > > [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1#LandedinHEAD > [2] > https://ghc.haskell.org/trac/ghc/wiki/GeneralizedMonadComprehensions#Applicativefunctor > > -- > David A Roberts > https://davidar.io > > > _______________________________________________ > 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: 819 bytes Desc: OpenPGP digital signature URL: From oleg.grenrus at iki.fi Mon Oct 12 09:17:36 2015 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Mon, 12 Oct 2015 10:17:36 +0100 Subject: Applicative Comprehensions In-Reply-To: <561B79D8.6030700@ro-che.info> References: <561B79D8.6030700@ro-che.info> Message-ID: <12FA18F9-87C4-4E86-90E3-5692DF948CB8@iki.fi> Paralell comprehension syntax will be confusing. If user have both MonadComprehensions and ApplicativeDo enabled, it makes total sense to desugar monad comprehensions into Applicative expression when it?s possible, and into Monadic otherwise. I?m actually a bit surprised if it?s not already a case. - Oleg > On 12 Oct 2015, at 10:14, Roman Cheplyaka wrote: > > I like this idea because having the pure function call at the beginning (rather than at the end, as with do-notation) is more consistent with the original <$>,<*>-notation. > > It only slightly bothers me that the bracket notation in this form has nothing to do with lists, so that may be a bit confusing. But this is already true for monad comprehensions. > > It might make more sense to reuse the parallel list comprehension syntax > (https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/syntax-extns.html#parallel-list-comprehensions), > as applicatives are "parallel". So, [ i + 2*j | i <- rows | j <- cols ]. > > On 10/12/2015 11:09 AM, David A Roberts wrote: >> Hi, >> >> I raised this question on #haskell, and was advised that this was >> probably the best place to discuss. >> >> I see that Applicative Do is scheduled for GHC 8.0 [1], and was hoping >> that this might also enable support for Applicative Comprehensions [2]. >> Is this likely to be the case? If not, would it be difficult to extend >> the support for Applicative Do to also handle comprehensions? I'm >> willing to submit patches if necessary, but I'm not at all familiar with >> GHC internals, so would need some guidance. >> >> I understand that comprehensions tend not to be used much in idiomatic >> Haskell, but I find them to be useful for implementing DSLs, so would >> really like to see this be supported. For example, a matrix could be >> written in a familiar notation: >> >>> [ i + 2*j | i <- rows, j <- cols ] >> >> which is a little more readable (to those not familiar with Haskell) than >> >>> (\i j -> i + 2*j) <$> row <*> cols >> >> or >> >>> do { i <- rows; j <- cols; return (i + 2*j) } >> >> [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1#LandedinHEAD >> [2] >> https://ghc.haskell.org/trac/ghc/wiki/GeneralizedMonadComprehensions#Applicativefunctor >> >> -- >> David A Roberts >> https://davidar.io >> >> >> _______________________________________________ >> 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: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From christiaan.baaij at gmail.com Mon Oct 12 16:38:15 2015 From: christiaan.baaij at gmail.com (Christiaan Baaij) Date: Mon, 12 Oct 2015 18:38:15 +0200 Subject: Strictness/demand analysis without worker/wrapper, or, reviving -fmax-worker-args Message-ID: Hi, As a GHC API user, I would like to run GHC?s strictness and demand analysis pass, but I don?t want any worker/wrappers. My specific use-case is to generate digital circuits from Haskell code, where I?ve yet to encounter any benefit from worker/wrappers: the generated circuits do not get any smaller or faster. They do however induce longer compilation times for my compiler. I still want to have GHC?s strictness and demand analysis, because, if I understand correctly, the demand and strictness annotations are needed by GHC?s dead code analysis (and other optimisations) which is beneficial for my use case. Looking through DynFlags, I encountered the ?maxWorkerArgs? field, which is controlled by ?-fmax-worker-args?. The user guide says the following: "If a worker has that many arguments, none will be unpacked anymore (default: 10)? I don?t know exactly what this means, but I was hoping that if I would set that number to 0 (zero), no worker/wrapper pairs would be created. Is that correct? The reason that I?m asking is because -fmax-worker-args is basically dead code. The ?maxWorkerArgs? field of DynFlags is not used anywhere. If setting ?-fmax-worker-args? to zero does indeed prevent any worker/wrappers from being generated, should I reimplement the flag and submit it as a patch? Or, is it preferable to simply remove ?-fmax-worker-args? (given that it doesn?t do anything right now), and create a new flag, ?-fno-worker-wrapper?, that simply disables the creation of worker/wrapper pairs everywhere? Regards, Christiaan From mark.lentczner at gmail.com Tue Oct 13 03:08:44 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Mon, 12 Oct 2015 20:08:44 -0700 Subject: "Excuse me, I think this i my stop..." - Resigning from the Platform Message-ID: I think this is the right time for me to exit: The truth is, I still can't bring myself to use a version of Haskell post the Foldable-Traversable-aPocalypse, let alone some future Haskell after the changes now in the works. My personal machines are all still 7.8. My personal projects are all pre-FTP. The Haskell I love to code in, the Haskell I'm passionate about, the Haskell I've advocated for real world use, and the Haskell I like to teach, is 7.8, pre-FTP. It's not that I'm dead set against change and evolution in a language, or even breaking changes. But FTP and beyond are changes that have lost the balance that Haskell had between abstraction and clarity, between elaborate and practical engineering. I don't see any restraint going forward, so I'm getting off the train. This puts me in an odd position with respect to Haskell Platform: I find myself building the Platform for a version of Haskell that I don't use. This isn't healthy for either the Platform or me. Hence, I'm resigning as release manager. I am sad because I believed that Haskell's path to much wider adoption was within reach. Now, especially with the ramping up of the Haskell Prime committee, which seems preordained to codify FTP and beyond into standard, we are approaching our Algol 68 moment: Building a major language revision with less opportunity than it's predecessor. I'll still see you 'round at meet-ups and conferences. I'll just be coding with an older accent. - Mark "mzero" Lentczner -------------- next part -------------- An HTML attachment was scrubbed... URL: From gershomb at gmail.com Tue Oct 13 03:43:14 2015 From: gershomb at gmail.com (Gershom B) Date: Mon, 12 Oct 2015 23:43:14 -0400 Subject: "Excuse me, I think this i my stop..." - Resigning from the Platform In-Reply-To: References: Message-ID: Thanks Mark for all your work over the years! Haskell has the adoption it does today in no small part because of your work in making sure it has been consistently easy to install over a range of systems. You?ve put many years and long hours into the work you?ve done as release manager, and we all appreciate it. I certainly suspect the applicatipocalypse is less around-the-bend than you perhaps prophesy (sorry, couldn?t resist). But as they say, horses for courses. I look forward to catching up with you at those meetups and conferences. Everyone else: I?m happy to step in for the immediate time being as release manager to bring to completion the minimal-platform-with-cabal-and-stack plans (aka ?Improving the Get Haskell Experience? proposal). I?ve already started to do so a very tiny bit, helping with a new OS X release to help with compatibility with El Capitan. I also want to note that lots of contributions lately have been coming courtesy of ?Randy Polen and Erik?Rantapaa in particular, so we have some great resources to build on. Especially medium term and long term more volunteers will be very welcome (I certainly can?t imagine remaining ?Mr. Platform? for as many tireless years as Mark has). A fair amount of the work I plan to spend on platform stuff in the immediate future will be to take the good work Mark has done in making easier the platform build and release process and further document it. The end goal should be that, at least for the foreseeable future, the release manager job should become straightforward and demystified enough that passing the baton becomes easier yet. If you have experience with installers in either the Windows or Mac world and would like to get involved (maybe just as a voice of experience and wisdom) please reach out to me and let me know. Alternately, if you have a friend with such experience, and you think you could convince them to lend a hand, perhaps suggest to them that they reach out to me :-P. Also, if you have either a range of boxes (or hardware with images of different flavors of systems) and some time to act as a tester ? please reach out as well. A designated team of installer-testers would be a good thing as well. Best, Gershom On October 12, 2015 at 11:09:12 PM, Mark Lentczner (mark.lentczner at gmail.com) wrote: > I think this is the right time for me to exit: > > The truth is, I still can't bring myself to use a version of Haskell post > the Foldable-Traversable-aPocalypse, let alone some future Haskell after > the changes now in the works. My personal machines are all still 7.8. My > personal projects are all pre-FTP. The Haskell I love to code in, the > Haskell I'm passionate about, the Haskell I've advocated for real world > use, and the Haskell I like to teach, is 7.8, pre-FTP. > > It's not that I'm dead set against change and evolution in a language, or > even breaking changes. But FTP and beyond are changes that have lost the > balance that Haskell had between abstraction and clarity, between elaborate > and practical engineering. I don't see any restraint going forward, so I'm > getting off the train. > > This puts me in an odd position with respect to Haskell Platform: I find > myself building the Platform for a version of Haskell that I don't use. > This isn't healthy for either the Platform or me. Hence, I'm resigning as > release manager. > > I am sad because I believed that Haskell's path to much wider adoption was > within reach. Now, especially with the ramping up of the Haskell Prime > committee, which seems preordained to codify FTP and beyond into standard, > we are approaching our Algol 68 moment: Building a major language revision > with less opportunity than it's predecessor. > > I'll still see you 'round at meet-ups and conferences. I'll just be coding > with an older accent. > > - Mark "mzero" Lentczner > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > From simonpj at microsoft.com Tue Oct 13 09:39:58 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 13 Oct 2015 09:39:58 +0000 Subject: "Excuse me, I think this i my stop..." - Resigning from the Platform In-Reply-To: References: Message-ID: <6a9c4156788d43e1a5a0f55fa046ab32@DB4PR30MB030.064d.mgd.msft.net> Mark You have given a lot to the Haskell community through your steady leadership of the Haskell Platform, and I want to add my personal thank-you for that. The Haskell community flourishes only because volunteers step up to the (not always comfortable) tasks of developing consensus and then actually getting the job done. You have done this brilliantly ? thank you. I know that your concerns reflect those of many. In the olden days when Haskell was a university research language, we could change it whenever we wanted and no one minded. But now it is used for lots of things, and people rightly complain about changes. Moreover, thoughtful and intelligent people differ in their judgement about what is and is not a good change. These are nice problems to have: they reflect a large, passionate, committed community of people who care about the language, its ecosystem, and its users. But of course they are still challenging problems! There is a genuine tension between innovation and change (which make Haskell so dynamic), and dependability and stability (which make it useful). I?m sure we will not always get it right. But it is my earnest hope that by respecting genuine differences of judgement, by being willing to see the world through others? eyes, by being willing to accept a choice that is not our own ? in short, by expressing true respect in our dealings with each other ? we will be able to work together on a journey in which none of us knows the True Path. So I?m very sorry to lose you as the driver of the HP train, but do hope you won?t get off the train altogether! With true thanks Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Mark Lentczner Sent: 13 October 2015 04:09 To: haskell-platform at projects.haskell.org; Haskell Libraries; ghc-devs at haskell.org Subject: "Excuse me, I think this i my stop..." - Resigning from the Platform I think this is the right time for me to exit: The truth is, I still can't bring myself to use a version of Haskell post the Foldable-Traversable-aPocalypse, let alone some future Haskell after the changes now in the works. My personal machines are all still 7.8. My personal projects are all pre-FTP. The Haskell I love to code in, the Haskell I'm passionate about, the Haskell I've advocated for real world use, and the Haskell I like to teach, is 7.8, pre-FTP. It's not that I'm dead set against change and evolution in a language, or even breaking changes. But FTP and beyond are changes that have lost the balance that Haskell had between abstraction and clarity, between elaborate and practical engineering. I don't see any restraint going forward, so I'm getting off the train. This puts me in an odd position with respect to Haskell Platform: I find myself building the Platform for a version of Haskell that I don't use. This isn't healthy for either the Platform or me. Hence, I'm resigning as release manager. I am sad because I believed that Haskell's path to much wider adoption was within reach. Now, especially with the ramping up of the Haskell Prime committee, which seems preordained to codify FTP and beyond into standard, we are approaching our Algol 68 moment: Building a major language revision with less opportunity than it's predecessor. I'll still see you 'round at meet-ups and conferences. I'll just be coding with an older accent. - Mark "mzero" Lentczner -------------- next part -------------- An HTML attachment was scrubbed... URL: From austin at well-typed.com Tue Oct 13 13:34:36 2015 From: austin at well-typed.com (Austin Seipp) Date: Tue, 13 Oct 2015 08:34:36 -0500 Subject: HEADS UP: HCAR due at the end of this month Message-ID: Hi *, The November edition of the HCAR is soon, so it's that time of the year again! https://ghc.haskell.org/trac/ghc/wiki/Status/Oct15 I've gone ahead and taken most of the basic info directly from the 8.0.1 status page. Everyone, please take 5 minutes to read over this page and make sure whatever you want mentioned is there. Remember: this is *not* the status report for 8.0 necessarily - so if you have something planned after 8.0 that you're working on, go ahead and add it! I'll be touching up the markup etc to bring it in line with what we usually have (bold highlights, etc). In the mean time, just write your blurb - I'll do the wordsmithing for the final draft... -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From takenobu.hs at gmail.com Tue Oct 13 13:36:17 2015 From: takenobu.hs at gmail.com (Takenobu Tani) Date: Tue, 13 Oct 2015 22:36:17 +0900 Subject: "Excuse me, I think this i my stop..." - Resigning from the Platform In-Reply-To: References: Message-ID: Dear Mark, Thank you for your efforts. You've gave us a lot of opportunity to meet haskell. There are many people on the back side of the firewall. They can't access over the firewall. HP, all-in-one and web downloadable package, is very useful for them. Thanks to you, we were able to enjoy the haskell. Thank you very much, Takenobu 2015-10-13 12:08 GMT+09:00 Mark Lentczner : > I think this is the right time for me to exit: > > The truth is, I still can't bring myself to use a version of Haskell post > the Foldable-Traversable-aPocalypse, let alone some future Haskell after > the changes now in the works. My personal machines are all still 7.8. My > personal projects are all pre-FTP. The Haskell I love to code in, the > Haskell I'm passionate about, the Haskell I've advocated for real world > use, and the Haskell I like to teach, is 7.8, pre-FTP. > > It's not that I'm dead set against change and evolution in a language, or > even breaking changes. But FTP and beyond are changes that have lost the > balance that Haskell had between abstraction and clarity, between elaborate > and practical engineering. I don't see any restraint going forward, so I'm > getting off the train. > > This puts me in an odd position with respect to Haskell Platform: I find > myself building the Platform for a version of Haskell that I don't use. > This isn't healthy for either the Platform or me. Hence, I'm resigning as > release manager. > > I am sad because I believed that Haskell's path to much wider adoption was > within reach. Now, especially with the ramping up of the Haskell Prime > committee, which seems preordained to codify FTP and beyond into standard, > we are approaching our Algol 68 moment: Building a major language revision > with less opportunity than it's predecessor. > > I'll still see you 'round at meet-ups and conferences. I'll just be coding > with an older accent. > > - Mark "mzero" Lentczner > > > _______________________________________________ > 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 Oct 13 14:29:01 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 13 Oct 2015 14:29:01 +0000 Subject: MonadFail decisions Message-ID: Dear Edward and Core Libraries Committee Can you tell us what plan you want to execute for MonadFail? Specifically, in https://wiki.haskell.org/MonadFail_Proposal ? Is the specification in 1.3 what you have agreed? ? Is the transition strategy in 1.7 exactly what you want? We can?t implement 8.0 without being sure of the specification! The current Phab is https://phabricator.haskell.org/D1248 Also, David, did our conversation at HX help you get un-stuck? Thanks Simon From: haskell-core-libraries at googlegroups.com [mailto:haskell-core-libraries at googlegroups.com] On Behalf Of Edward Kmett Sent: 13 October 2015 01:43 To: core-libraries-committee at haskell.org Subject: [core libraries] Prelude: 3 Release Policy Recently there has been a bunch of chatter about ways to mitigate the amount of CPP pushed on users by changes to the Prelude. In particular the discussion has been around the idea of trying to ensure that it is possible to write code in _some_ way without CPP that can run backwards for 3 releases of GHC, preferably in a -Wall safe manner. The approach they may have to use may not be the idiomatic way, but in general it should exist. Gershom ran around at the Haskell Exchange sounding folks out about this idea, and it seems to codify a reasonable tension between the "change nothing" and "change everything" camps. The feedback thus far seems to be noises of "grumbling acceptance" rather than the current state of outright panic that we might do anything at any time. I'm personally considering this a very high priority for all changes to Prelude going forward. The 3 years forms a backward-facing window, not a guarantee against future change, but we should of course try to let folks know what is coming with a decent time horizon so folks can look forward as well. That is a separate concern, though. I'm not ready to give the "3 release policy" outright veto power over new functionality, but at least if we have two plans that can in the end yield the same end state, we should definitely err on the side of the plan that falls within these guidelines, and be very well ready to explain to a rather irate community when we violate this rubric. It shouldn't be done lightly, if at all, if we can help it! All in all it is a fairly weak guarantee, but it does have some impact on current items under consideration. Off the top of my head: * A number of new members for Floating were passed by proposal back before 7.10 went out the door, but haven't found their way into base yet: expm1, log1p, etc. are absolutely required for decent precision numerics. When the proposal passed we ultimately decided _not_ to include default definitions for these to force authors to implement them explicitly. Under the guidelines here, the plan would likely have to include default definitions for these to start when introducing them in 8.0. Then in 8.4 we could in theory remove the defaults and remain in compliance with the letter of the law here or introduce an ad hoc warning about lack of implementation, and remove the defaults in 8.6, depending on how gradual an introduction we wanted to give. We wouldn't be able to do the warnings in 8.2, however, and remain within the letter of the law, and we wouldn't be able to introduce them without defaults without violating the no-warnings guideline. * MonadFail reform proposal wouldn't be able to start issuing warnings about missing instances until 8.4 even if we put in MonadFail into a module today. This would likely delay the full implementation of the proposal to 8.6 as well. * The Semigroup as a superclass of Monoid proposal runs into a similar clock. An immediate consequence is that creating a class in base (or moving one into base) and moving it into Prelude changes picks up a 3-4 year window for implementation. (3 years from this guideline, and a year if we want to / should give warnings about missing instances, which as mentioned above, is a separate concern.) Observations: This doesn't imply the lack of warnings for new names coming into Prelude, because code can be changed to use the new names in a backwards compatible way. The AMP warnings would be in compliance. I don't think we can viably apply this reasoning to other modules in base or even most other packages under the core libraries purview: It'd be nice, but things like template-haskell change on too quick a clock. For other modules in base or other libraries in scope of the core libraries process, I'd probably consider this guideline demoted from "should" to "may". When Data.Proxy or Data.Void were brought into base they were brought in more or less unmolested from tagged and void respectively with only minor differences. This means that code that wants to use them with older versions of the compiler can use their pre-existing dependency as a conditional (or mandatory) listed dependency. This means that code that was using them before continues to work fine despite their incorporation into base. Compliance with this rule also acts as a hedge against severe bikeshedding when we incorporate more stuff. In the case of Semigroup you can use the semigroups package today in a form that is backwards compatible for a half dozen We could ship a 'fail' package that gave you access to the MonadFail class across older GHC versions. The question then becomes is it worth trying to use the existence of those packages to try to "cheat the clock"? I think we'd almost assuredly be rightly called out for 'cheating' by package maintainers where a fresh 'fail' package was concerned, but given the widespread distribution of 'semigroups' it might be plausible to use that to justify finishing out that proposal in 8.4 (end of 2017) rather than 8.6 (end of 2018). Personally, I'm content with the longer clock and don't think it'd be worth doing in this case, but it was an informative exercise to consider. At the least, the existence of such packages lets us go much farther back than 3 releases for folks who have a wider support window. Again, the above guideline would basically imply that if you wanted to add a thing to base and get it into the Prelude you can't do it in less than 3 years. Given the stability of Prelude this is the _least_ we can do. Now nobody needs to worry about us rushing off to add Pointed or Semiapplicative to Prelude in the short term. It simply can't move into base and happen that fast. Things already in base could admittedly take a shorter path and comply, but it is worth noting that this is just one guideline -- both the AMP and Foldable/Traversable Proposal would pass this litmus test. I'm mostly just running through active proposals and trying to understand the impact of such a policy, but so far I can't find anything that causes me to object. I'm content to codify it as my own personal "best practice", and would be willing to see us as an organization draft it up into a form that other people could rely upon to get a sense of stability. In all of the above cases I think it actually improves upon the timeline a bit. Lengthening the timelines above means we'll need to work harder on transferring institutional memory at the very least. Wiki and Trac items for these sorts of proposals will become even more important. It will become almost impossible to spawn a from-scratch Prelude-affecting proposal and finish it during one 3-year cycle tenure on the committee. Ideas? -Edward -- You received this message because you are subscribed to the Google Groups "haskell-core-libraries" group. To unsubscribe from this group and stop receiving emails from it, send an email to haskell-core-libraries+unsubscribe at googlegroups.com. For more options, visit https://groups.google.com/d/optout. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Tue Oct 13 15:24:47 2015 From: ekmett at gmail.com (Edward Kmett) Date: Tue, 13 Oct 2015 11:24:47 -0400 Subject: MonadFail decisions In-Reply-To: References: Message-ID: On Tue, Oct 13, 2015 at 10:29 AM, Simon Peyton Jones wrote: > Dear Edward and Core Libraries Committee > > > > Can you tell us what plan you want to execute for MonadFail? > Specifically, in https://wiki.haskell.org/MonadFail_Proposal > > ? Is the specification in 1.3 what you have agreed? > The main concern I have with section 1.3 is the statement about view pattern desugaring. It really should just borrow the failability of the pattern part. The view pattern component adds nothing. Getting better introspection on pattern synonyms to avoid them becoming a huge source of MonadFail constraints would be good as well. We can in theory incorporate improvements on this front gradually however. > ? Is the transition strategy in 1.7 exactly what you want? > > The "3 release policy" informs the design here a bit. Notably it puts off warnings for this for a while, as we can't warn about it in 8.0 (or really even 8.2) which means that at least in 8.0 this is almost entirely a library change. Under that policy we can't do the warnings until 8.4 and cut-over til 8.6. For 8.0 the change to 1.7 basically comes down to "don't turn on the warnings by default yet". We can?t implement 8.0 without being sure of the specification! The > current Phab is > > https://phabricator.haskell.org/D1248 > > > > Also, David, did our conversation at HX help you get un-stuck? > > -Edward > > > Thanks > > > > Simon > > > > *From:* haskell-core-libraries at googlegroups.com [mailto: > haskell-core-libraries at googlegroups.com] *On Behalf Of *Edward Kmett > *Sent:* 13 October 2015 01:43 > *To:* core-libraries-committee at haskell.org > *Subject:* [core libraries] Prelude: 3 Release Policy > > > > Recently there has been a bunch of chatter about ways to mitigate the > amount of CPP pushed on users by changes to the Prelude. > > > > In particular the discussion has been around the idea of trying to ensure > that it is possible to write code in _some_ way without CPP that can run > backwards for 3 releases of GHC, preferably in a -Wall safe manner. The > approach they may have to use may not be the idiomatic way, but in general > it should exist. > > > > Gershom ran around at the Haskell Exchange sounding folks out about this > idea, and it seems to codify a reasonable tension between the "change > nothing" and "change everything" camps. The feedback thus far seems to be > noises of "grumbling acceptance" rather than the current state of outright > panic that we might do anything at any time. > > > > I'm personally considering this a very high priority for all changes to > Prelude going forward. > > > > The 3 years forms a backward-facing window, not a guarantee against future > change, but we should of course try to let folks know what is coming with a > decent time horizon so folks can look forward as well. That is a separate > concern, though. > > > > I'm not ready to give the "3 release policy" outright veto power over new > functionality, but at least if we have two plans that can in the end yield > the same end state, we should definitely err on the side of the plan that > falls within these guidelines, and be very well ready to explain to a > rather irate community when we violate this rubric. It shouldn't be done > lightly, if at all, if we can help it! > > > > All in all it is a fairly weak guarantee, but it does have some impact on > current items under consideration. > > > > Off the top of my head: > > > > * A number of new members for Floating were passed by proposal back before > 7.10 went out the door, but haven't found their way into base yet: expm1, > log1p, etc. are absolutely required for decent precision numerics. When the > proposal passed we ultimately decided _not_ to include default definitions > for these to force authors to implement them explicitly. Under the > guidelines here, the plan would likely have to include default definitions > for these to start when introducing them in 8.0. Then in 8.4 we could in > theory remove the defaults and remain in compliance with the letter of the > law here or introduce an ad hoc warning about lack of implementation, and > remove the defaults in 8.6, depending on how gradual an introduction we > wanted to give. We wouldn't be able to do the warnings in 8.2, however, and > remain within the letter of the law, and we wouldn't be able to introduce > them without defaults without violating the no-warnings guideline. > > > > * MonadFail reform proposal wouldn't be able to start issuing warnings > about missing instances until 8.4 even if we put in MonadFail into a module > today. This would likely delay the full implementation of the proposal to > 8.6 as well. > > > > * The Semigroup as a superclass of Monoid proposal runs into a similar > clock. > > > > An immediate consequence is that creating a class in base (or moving one > into base) and moving it into Prelude changes picks up a 3-4 year window > for implementation. (3 years from this guideline, and a year if we want to > / should give warnings about missing instances, which as mentioned above, > is a separate concern.) > > > > Observations: > > > > This doesn't imply the lack of warnings for new names coming into Prelude, > because code can be changed to use the new names in a backwards compatible > way. The AMP warnings would be in compliance. > > > > I don't think we can viably apply this reasoning to other modules in base > or even most other packages under the core libraries purview: It'd be nice, > but things like template-haskell change on too quick a clock. For other > modules in base or other libraries in scope of the core libraries process, > I'd probably consider this guideline demoted from "should" to "may". > > > > When Data.Proxy or Data.Void were brought into base they were brought in > more or less unmolested from tagged and void respectively with only minor > differences. > > > > This means that code that wants to use them with older versions of the > compiler can use their pre-existing dependency as a conditional (or > mandatory) listed dependency. This means that code that was using them > before continues to work fine despite their incorporation into base. > Compliance with this rule also acts as a hedge against severe bikeshedding > when we incorporate more stuff. > > > > In the case of Semigroup you can use the semigroups package today in a > form that is backwards compatible for a half dozen We could ship a 'fail' > package that gave you access to the MonadFail class across older GHC > versions. > > > > The question then becomes is it worth trying to use the existence of those > packages to try to "cheat the clock"? I think we'd almost assuredly be > rightly called out for 'cheating' by package maintainers where a fresh > 'fail' package was concerned, but given the widespread distribution of > 'semigroups' it might be plausible to use that to justify finishing out > that proposal in 8.4 (end of 2017) rather than 8.6 (end of 2018). > Personally, I'm content with the longer clock and don't think it'd be worth > doing in this case, but it was an informative exercise to consider. At the > least, the existence of such packages lets us go much farther back than 3 > releases for folks who have a wider support window. > > > > Again, the above guideline would basically imply that if you wanted to add > a thing to base and get it into the Prelude you can't do it in less than 3 > years. Given the stability of Prelude this is the _least_ we can do. Now > nobody needs to worry about us rushing off to add Pointed or > Semiapplicative to Prelude in the short term. It simply can't move into > base and happen that fast. > > > > Things already in base could admittedly take a shorter path and comply, > but it is worth noting that this is just one guideline -- both the AMP and > Foldable/Traversable Proposal would pass this litmus test. > > > > I'm mostly just running through active proposals and trying to understand > the impact of such a policy, but so far I can't find anything that causes > me to object. > > > > I'm content to codify it as my own personal "best practice", and would be > willing to see us as an organization draft it up into a form that other > people could rely upon to get a sense of stability. In all of the above > cases I think it actually improves upon the timeline a bit. > > > > Lengthening the timelines above means we'll need to work harder on > transferring institutional memory at the very least. Wiki and Trac items > for these sorts of proposals will become even more important. It will > become almost impossible to spawn a from-scratch Prelude-affecting proposal > and finish it during one 3-year cycle tenure on the committee. > > > > Ideas? > > > > -Edward > > -- > You received this message because you are subscribed to the Google Groups > "haskell-core-libraries" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to haskell-core-libraries+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/d/optout > > . > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gregmainland at gmail.com Tue Oct 13 16:39:45 2015 From: gregmainland at gmail.com (Greg Horn) Date: Tue, 13 Oct 2015 16:39:45 +0000 Subject: "Excuse me, I think this i my stop..." - Resigning from the Platform In-Reply-To: References: Message-ID: Hi Mark, I know how frustrating and demotivating it can be to be on the dissenting side of of a change like this. Thanks for all of your contributions to the community. Best regards On Tue, Oct 13, 2015, 06:36 Takenobu Tani wrote: > Dear Mark, > > Thank you for your efforts. > > You've gave us a lot of opportunity to meet haskell. > There are many people on the back side of the firewall. > They can't access over the firewall. > HP, all-in-one and web downloadable package, is very useful for them. > > Thanks to you, we were able to enjoy the haskell. > > Thank you very much, > Takenobu > > > 2015-10-13 12:08 GMT+09:00 Mark Lentczner : > >> I think this is the right time for me to exit: >> >> The truth is, I still can't bring myself to use a version of Haskell post >> the Foldable-Traversable-aPocalypse, let alone some future Haskell after >> the changes now in the works. My personal machines are all still 7.8. My >> personal projects are all pre-FTP. The Haskell I love to code in, the >> Haskell I'm passionate about, the Haskell I've advocated for real world >> use, and the Haskell I like to teach, is 7.8, pre-FTP. >> >> It's not that I'm dead set against change and evolution in a language, or >> even breaking changes. But FTP and beyond are changes that have lost the >> balance that Haskell had between abstraction and clarity, between elaborate >> and practical engineering. I don't see any restraint going forward, so I'm >> getting off the train. >> >> This puts me in an odd position with respect to Haskell Platform: I find >> myself building the Platform for a version of Haskell that I don't use. >> This isn't healthy for either the Platform or me. Hence, I'm resigning as >> release manager. >> >> I am sad because I believed that Haskell's path to much wider adoption >> was within reach. Now, especially with the ramping up of the Haskell Prime >> committee, which seems preordained to codify FTP and beyond into standard, >> we are approaching our Algol 68 moment: Building a major language revision >> with less opportunity than it's predecessor. >> >> I'll still see you 'round at meet-ups and conferences. I'll just be >> coding with an older accent. >> >> - Mark "mzero" Lentczner >> >> >> _______________________________________________ >> 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 Oct 13 16:42:12 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 13 Oct 2015 16:42:12 +0000 Subject: MonadFail decisions In-Reply-To: References: Message-ID: <571919ff17ca453aa9d57bcea6c667f6@DB4PR30MB030.064d.mgd.msft.net> Great. But it still leaves me hazy about precisely what you have agreed for the 8.0 release. Would it be possible to revise that page and announce ?This is what CLC has agreed?? Then (a) I know exactly what David is trying to implement for 8.0, and (b) everyone is in the loop and can yell if they want. More generally, I think it would be great to have an authoritative page (or something) where CLC decisions are recorded. Like minutes of the meeting, as it were, but recording only outcomes, not discussion. thanks Simon From: Edward Kmett [mailto:ekmett at gmail.com] Sent: 13 October 2015 16:25 To: Simon Peyton Jones Cc: core-libraries-committee at haskell.org; David Luposchainsky; ghc-devs at haskell.org Subject: Re: MonadFail decisions On Tue, Oct 13, 2015 at 10:29 AM, Simon Peyton Jones > wrote: Dear Edward and Core Libraries Committee Can you tell us what plan you want to execute for MonadFail? Specifically, in https://wiki.haskell.org/MonadFail_Proposal ? Is the specification in 1.3 what you have agreed? The main concern I have with section 1.3 is the statement about view pattern desugaring. It really should just borrow the failability of the pattern part. The view pattern component adds nothing. Getting better introspection on pattern synonyms to avoid them becoming a huge source of MonadFail constraints would be good as well. We can in theory incorporate improvements on this front gradually however. ? Is the transition strategy in 1.7 exactly what you want? The "3 release policy" informs the design here a bit. Notably it puts off warnings for this for a while, as we can't warn about it in 8.0 (or really even 8.2) which means that at least in 8.0 this is almost entirely a library change. Under that policy we can't do the warnings until 8.4 and cut-over til 8.6. For 8.0 the change to 1.7 basically comes down to "don't turn on the warnings by default yet". We can?t implement 8.0 without being sure of the specification! The current Phab is https://phabricator.haskell.org/D1248 Also, David, did our conversation at HX help you get un-stuck? -Edward Thanks Simon From: haskell-core-libraries at googlegroups.com [mailto:haskell-core-libraries at googlegroups.com] On Behalf Of Edward Kmett Sent: 13 October 2015 01:43 To: core-libraries-committee at haskell.org Subject: [core libraries] Prelude: 3 Release Policy Recently there has been a bunch of chatter about ways to mitigate the amount of CPP pushed on users by changes to the Prelude. In particular the discussion has been around the idea of trying to ensure that it is possible to write code in _some_ way without CPP that can run backwards for 3 releases of GHC, preferably in a -Wall safe manner. The approach they may have to use may not be the idiomatic way, but in general it should exist. Gershom ran around at the Haskell Exchange sounding folks out about this idea, and it seems to codify a reasonable tension between the "change nothing" and "change everything" camps. The feedback thus far seems to be noises of "grumbling acceptance" rather than the current state of outright panic that we might do anything at any time. I'm personally considering this a very high priority for all changes to Prelude going forward. The 3 years forms a backward-facing window, not a guarantee against future change, but we should of course try to let folks know what is coming with a decent time horizon so folks can look forward as well. That is a separate concern, though. I'm not ready to give the "3 release policy" outright veto power over new functionality, but at least if we have two plans that can in the end yield the same end state, we should definitely err on the side of the plan that falls within these guidelines, and be very well ready to explain to a rather irate community when we violate this rubric. It shouldn't be done lightly, if at all, if we can help it! All in all it is a fairly weak guarantee, but it does have some impact on current items under consideration. Off the top of my head: * A number of new members for Floating were passed by proposal back before 7.10 went out the door, but haven't found their way into base yet: expm1, log1p, etc. are absolutely required for decent precision numerics. When the proposal passed we ultimately decided _not_ to include default definitions for these to force authors to implement them explicitly. Under the guidelines here, the plan would likely have to include default definitions for these to start when introducing them in 8.0. Then in 8.4 we could in theory remove the defaults and remain in compliance with the letter of the law here or introduce an ad hoc warning about lack of implementation, and remove the defaults in 8.6, depending on how gradual an introduction we wanted to give. We wouldn't be able to do the warnings in 8.2, however, and remain within the letter of the law, and we wouldn't be able to introduce them without defaults without violating the no-warnings guideline. * MonadFail reform proposal wouldn't be able to start issuing warnings about missing instances until 8.4 even if we put in MonadFail into a module today. This would likely delay the full implementation of the proposal to 8.6 as well. * The Semigroup as a superclass of Monoid proposal runs into a similar clock. An immediate consequence is that creating a class in base (or moving one into base) and moving it into Prelude changes picks up a 3-4 year window for implementation. (3 years from this guideline, and a year if we want to / should give warnings about missing instances, which as mentioned above, is a separate concern.) Observations: This doesn't imply the lack of warnings for new names coming into Prelude, because code can be changed to use the new names in a backwards compatible way. The AMP warnings would be in compliance. I don't think we can viably apply this reasoning to other modules in base or even most other packages under the core libraries purview: It'd be nice, but things like template-haskell change on too quick a clock. For other modules in base or other libraries in scope of the core libraries process, I'd probably consider this guideline demoted from "should" to "may". When Data.Proxy or Data.Void were brought into base they were brought in more or less unmolested from tagged and void respectively with only minor differences. This means that code that wants to use them with older versions of the compiler can use their pre-existing dependency as a conditional (or mandatory) listed dependency. This means that code that was using them before continues to work fine despite their incorporation into base. Compliance with this rule also acts as a hedge against severe bikeshedding when we incorporate more stuff. In the case of Semigroup you can use the semigroups package today in a form that is backwards compatible for a half dozen We could ship a 'fail' package that gave you access to the MonadFail class across older GHC versions. The question then becomes is it worth trying to use the existence of those packages to try to "cheat the clock"? I think we'd almost assuredly be rightly called out for 'cheating' by package maintainers where a fresh 'fail' package was concerned, but given the widespread distribution of 'semigroups' it might be plausible to use that to justify finishing out that proposal in 8.4 (end of 2017) rather than 8.6 (end of 2018). Personally, I'm content with the longer clock and don't think it'd be worth doing in this case, but it was an informative exercise to consider. At the least, the existence of such packages lets us go much farther back than 3 releases for folks who have a wider support window. Again, the above guideline would basically imply that if you wanted to add a thing to base and get it into the Prelude you can't do it in less than 3 years. Given the stability of Prelude this is the _least_ we can do. Now nobody needs to worry about us rushing off to add Pointed or Semiapplicative to Prelude in the short term. It simply can't move into base and happen that fast. Things already in base could admittedly take a shorter path and comply, but it is worth noting that this is just one guideline -- both the AMP and Foldable/Traversable Proposal would pass this litmus test. I'm mostly just running through active proposals and trying to understand the impact of such a policy, but so far I can't find anything that causes me to object. I'm content to codify it as my own personal "best practice", and would be willing to see us as an organization draft it up into a form that other people could rely upon to get a sense of stability. In all of the above cases I think it actually improves upon the timeline a bit. Lengthening the timelines above means we'll need to work harder on transferring institutional memory at the very least. Wiki and Trac items for these sorts of proposals will become even more important. It will become almost impossible to spawn a from-scratch Prelude-affecting proposal and finish it during one 3-year cycle tenure on the committee. Ideas? -Edward -- You received this message because you are subscribed to the Google Groups "haskell-core-libraries" group. To unsubscribe from this group and stop receiving emails from it, send an email to haskell-core-libraries+unsubscribe at googlegroups.com. For more options, visit https://groups.google.com/d/optout. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Tue Oct 13 17:32:30 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Tue, 13 Oct 2015 13:32:30 -0400 Subject: Kind equalities update Message-ID: <590FE375-7B7A-486F-884B-789BC7F847D0@cis.upenn.edu> Hi devs, In a chat with Simon this morning about kind equalities, he expressed that you all might want to know about the plans for kind equalities in 8.0. The wiki page both for user-facing changes and for implementation notes is here: https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Phase1 It is my intent that all user-facing changes mentioned there will be available in 8.0. I am hard at work getting my branch ready to merge, and hope to do so mid-November. Note: this is almost fully backward-compatible. Here are some areas where there are known incompatibilities: - Template Haskell will have to be updated. But there's a raft of changes there, anyway. - GHC will do a more careful job of checking for termination of instances regarding the use of kind variables. This may require new UndecidableInstances declarations. But the fact that these definitions (like `instance (C a, C b) => C (a b)` for a polykinded C) were accepted previously could be called a bug. That's actually all I know of so far. You can take kind equalities for a spin at github.com/goldfirere/ghc, on the "nokinds" branch. Note that this hasn't been merged with `master` since December of last year, so expect a little strange behavior compared with 7.10. These wrinkles will get smoothed out, of course. Richard From acfoltzer at gmail.com Tue Oct 13 21:56:04 2015 From: acfoltzer at gmail.com (Adam Foltzer) Date: Tue, 13 Oct 2015 14:56:04 -0700 Subject: Request to reopen the issue of 7.8 on El Capitan Message-ID: Hello, The issue was brought up on this list [1] that the released versions of GHC 7.8 do not work on El Capitan due to an older `unix` package. In a subsequent GHC weekly news [2], it was announced that since El Capitan wasn't yet released, it wasn't worthwhile to put more developer time into 7.8. Now that El Capitan is out, and the existing 7.8 binaries continue to not work, I'd like to reopen this issue and request a point release with an updated `unix` package. Thank you, Adam Foltzer Research Engineer Galois, Inc. [1]: https://mail.haskell.org/pipermail/ghc-devs/2015-July/009403.html [2]: https://ghc.haskell.org/trac/ghc/blog/weekly20150721#MacOSXElCapitansupport -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Tue Oct 13 23:19:33 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 13 Oct 2015 19:19:33 -0400 Subject: Request to reopen the issue of 7.8 on El Capitan In-Reply-To: References: Message-ID: There are no plans to do a new 7.8 release at this Time. Even doing a point release for 7.10.3 is still speculative. We should reflect the capitan issue in the installation documentation. And or remark that only 7.10 or newer is supported on El Capitan. If a user needs a 7.8 build that works on capitan, they will need to build a source dist with an updated UNIX package. On Tuesday, October 13, 2015, Adam Foltzer wrote: > Hello, > > The issue was brought up on this list [1] that the released versions of > GHC 7.8 do not work on El Capitan due to an older `unix` package. In a > subsequent GHC weekly news [2], it was announced that since El Capitan > wasn't yet released, it wasn't worthwhile to put more developer time into > 7.8. > > Now that El Capitan is out, and the existing 7.8 binaries continue to not > work, I'd like to reopen this issue and request a point release with an > updated `unix` package. > > Thank you, > > Adam Foltzer > Research Engineer > Galois, Inc. > > [1]: https://mail.haskell.org/pipermail/ghc-devs/2015-July/009403.html > [2]: > https://ghc.haskell.org/trac/ghc/blog/weekly20150721#MacOSXElCapitansupport > -------------- next part -------------- An HTML attachment was scrubbed... URL: From austin at well-typed.com Wed Oct 14 00:37:00 2015 From: austin at well-typed.com (Austin Seipp) Date: Tue, 13 Oct 2015 19:37:00 -0500 Subject: Kind equalities update In-Reply-To: <590FE375-7B7A-486F-884B-789BC7F847D0@cis.upenn.edu> References: <590FE375-7B7A-486F-884B-789BC7F847D0@cis.upenn.edu> Message-ID: Hey Richard, Thanks a lot. I'm very eager to see this land ASAP! It's exciting. But... Looking at the page, I really, really am still not a fan of using 'type' in place of *, and I still think (as I mentioned on Reddit I believe) that 'Type' is the best choice for this. I mentioned this to Simon earlier, and I kind of hate to make even more work for you, but my basic reasoning is: - '*' is not a good choice because it's a lexical wart. But in terms of 'theory', the statement '* :: *' is completely OK, or 'type :: type' or or 'U :: U' or 'Type :: Type'. That is, the reason star is bad is because it's a lexical problem that leads to weird ambiguous parsing, not that it's necessarily confusing or using any particular word I think. - 'type' is not a good choice, because while in theory any name is kind of arbitrary, it's very confusing for Haskell IMO - we have _chosen_ the distinction between type variables and type constructors through the use of capitalization. I think it's a bit strange to say '*' or what have you has type 'type' yet 'type' is not an actual variable, nor a keyword in a meaningful sense, but an actual type on its own. Yet 0-arity type constructors of all sorts (like Int or Bool) have this lexical capitalization! That is, 'type' isn't confusing because it's a lexical wart, or has bad parsing - but because it violates how we syntactically distinguish type variables from constructors of types. - (Correct if I'm wrong) As far as I understand, 'Type' doesn't need to be reserved unless -XTypeInType is enabled, correct? I think it is fairly reasonable to say that extensions may take up parts of your namespace should you enable them - for example, -XStaticPointers steals the term 'static' for itself, which I think is OK! - As far as code breakage goes, I think the prior point makes the outright breakage minimal-to-none if true, which is great. Even GHC uses the name `Type`, but we wouldn't even be able to use -XTypeInType for another few years at best! So we have plenty of time to address that when we want to use it... I suppose #2 is a little 'feels-y', since 'violating' how we expect to read Haskell is maybe subjective. But I figure I might as well make a last ditch effort at the cost of a little stirring. I think that mostly sums it up. I'm still reading over the full page, I just got to this point and decided to shout. (Wadler's Law strikes again!) On Tue, Oct 13, 2015 at 12:32 PM, Richard Eisenberg wrote: > Hi devs, > > In a chat with Simon this morning about kind equalities, he expressed that you all might want to know about the plans for kind equalities in 8.0. > > The wiki page both for user-facing changes and for implementation notes is here: https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Phase1 > It is my intent that all user-facing changes mentioned there will be available in 8.0. I am hard at work getting my branch ready to merge, and hope to do so mid-November. > > Note: this is almost fully backward-compatible. Here are some areas where there are known incompatibilities: > - Template Haskell will have to be updated. But there's a raft of changes there, anyway. > - GHC will do a more careful job of checking for termination of instances regarding the use of kind variables. This may require new UndecidableInstances declarations. But the fact that these definitions (like `instance (C a, C b) => C (a b)` for a polykinded C) were accepted previously could be called a bug. > > That's actually all I know of so far. > > You can take kind equalities for a spin at github.com/goldfirere/ghc, on the "nokinds" branch. Note that this hasn't been merged with `master` since December of last year, so expect a little strange behavior compared with 7.10. These wrinkles will get smoothed out, of course. > > Richard > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From acfoltzer at gmail.com Wed Oct 14 00:55:46 2015 From: acfoltzer at gmail.com (Adam Foltzer) Date: Tue, 13 Oct 2015 17:55:46 -0700 Subject: Request to reopen the issue of 7.8 on El Capitan In-Reply-To: References: Message-ID: 7.8.4 is was released only ten months ago; it surprises me that we'd consider it acceptable to have such a recent release fail to work on new machines when the fix is so small as to not even require a patch to the source tree. In particular, I remember hearing proponents of 7.10's changes reassure detractors that if they choose, they can continue to use 7.8.4, which is no longer an option. I'd ask that we (1) reconsider the decision to stop 7.8 releases, and (2) if we stand by the decision, document the mitigations for users who would like to build their own working version of the compiler. I just finished a build from a source dist with `unix-2.7.1.0` and it still triggers the El Capitan error, so I suspect it's not as simple as just dropping the new package into `/libraries/unix/`. On Tue, Oct 13, 2015 at 4:19 PM, Carter Schonwald < carter.schonwald at gmail.com> wrote: > There are no plans to do a new 7.8 release at this Time. Even doing a > point release for 7.10.3 is still speculative. > > We should reflect the capitan issue in the installation documentation. > And or remark that only 7.10 or newer is supported on El Capitan. > > If a user needs a 7.8 build that works on capitan, they will need to build > a source dist with an updated UNIX package. > > > On Tuesday, October 13, 2015, Adam Foltzer wrote: > >> Hello, >> >> The issue was brought up on this list [1] that the released versions of >> GHC 7.8 do not work on El Capitan due to an older `unix` package. In a >> subsequent GHC weekly news [2], it was announced that since El Capitan >> wasn't yet released, it wasn't worthwhile to put more developer time into >> 7.8. >> >> Now that El Capitan is out, and the existing 7.8 binaries continue to not >> work, I'd like to reopen this issue and request a point release with an >> updated `unix` package. >> >> Thank you, >> >> Adam Foltzer >> Research Engineer >> Galois, Inc. >> >> [1]: https://mail.haskell.org/pipermail/ghc-devs/2015-July/009403.html >> [2]: >> https://ghc.haskell.org/trac/ghc/blog/weekly20150721#MacOSXElCapitansupport >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From austin at well-typed.com Wed Oct 14 01:03:02 2015 From: austin at well-typed.com (Austin Seipp) Date: Tue, 13 Oct 2015 20:03:02 -0500 Subject: Request to reopen the issue of 7.8 on El Capitan In-Reply-To: References: Message-ID: I wasn't aware it completely broke on El Capitan, but I think that's a pretty extreme case (where a completely usable release simply breaks because a hugely popular OS changes) that would warrant a 7.8.5 release, to be honest. Presumably, this would really be the only change, so mostly OS X users would be affected by its availability. In general people like to use the last 3 GHC releases anyway, and we haven't even *released* 8.0 yet. And at that point, 7.8.x will be the last 'in the chain' - so I can assume people would _still_ want 7.8 on OS X presumably, even more than a year from today until 8.2! At that point (8.2-ish era) if Apple keeps breaking things, we may not do another release, but in this case I think the timescale for user/library support is probably worth it. Otherwise OS X users are going to have to fix it themselves, and it might be ugly (propagating random fixes around the internet isn't going to work well, and we'll just keep getting bug reports about this because of that - we've already done this dance with OS X.) I'll note this down and think about it more this week, since we'd like to get 7.10.3 out soon as well... On Tue, Oct 13, 2015 at 7:55 PM, Adam Foltzer wrote: > 7.8.4 is was released only ten months ago; it surprises me that we'd > consider it acceptable to have such a recent release fail to work on new > machines when the fix is so small as to not even require a patch to the > source tree. In particular, I remember hearing proponents of 7.10's changes > reassure detractors that if they choose, they can continue to use 7.8.4, > which is no longer an option. > > I'd ask that we (1) reconsider the decision to stop 7.8 releases, and (2) if > we stand by the decision, document the mitigations for users who would like > to build their own working version of the compiler. I just finished a build > from a source dist with `unix-2.7.1.0` and it still triggers the El Capitan > error, so I suspect it's not as simple as just dropping the new package into > `/libraries/unix/`. > > On Tue, Oct 13, 2015 at 4:19 PM, Carter Schonwald > wrote: >> >> There are no plans to do a new 7.8 release at this Time. Even doing a >> point release for 7.10.3 is still speculative. >> >> We should reflect the capitan issue in the installation documentation. >> And or remark that only 7.10 or newer is supported on El Capitan. >> >> If a user needs a 7.8 build that works on capitan, they will need to build >> a source dist with an updated UNIX package. >> >> >> On Tuesday, October 13, 2015, Adam Foltzer wrote: >>> >>> Hello, >>> >>> The issue was brought up on this list [1] that the released versions of >>> GHC 7.8 do not work on El Capitan due to an older `unix` package. In a >>> subsequent GHC weekly news [2], it was announced that since El Capitan >>> wasn't yet released, it wasn't worthwhile to put more developer time into >>> 7.8. >>> >>> Now that El Capitan is out, and the existing 7.8 binaries continue to not >>> work, I'd like to reopen this issue and request a point release with an >>> updated `unix` package. >>> >>> Thank you, >>> >>> Adam Foltzer >>> Research Engineer >>> Galois, Inc. >>> >>> [1]: https://mail.haskell.org/pipermail/ghc-devs/2015-July/009403.html >>> [2]: >>> https://ghc.haskell.org/trac/ghc/blog/weekly20150721#MacOSXElCapitansupport > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From cma at bitemyapp.com Wed Oct 14 01:09:07 2015 From: cma at bitemyapp.com (Christopher Allen) Date: Tue, 13 Oct 2015 20:09:07 -0500 Subject: Kind equalities update In-Reply-To: References: <590FE375-7B7A-486F-884B-789BC7F847D0@cis.upenn.edu> Message-ID: My opinion may not count for a lot from a compiler engineering perspective, but I can say with a fair bit of confidence that violating the "capitalized -> concrete constructor, lowercase -> variable" convention for types would be _very_ surprising to learners and users. I don't think it's a petty issue at all. This isn't a mistake we have to live with, even if it's regrettable that it's more work for Richard. >(Wadler's Law strikes again!) Apologies for my contributions on this front, didn't disagree with anything else and wanted to bolster Austin's concerns here. On Tue, Oct 13, 2015 at 7:37 PM, Austin Seipp wrote: > Hey Richard, > > Thanks a lot. I'm very eager to see this land ASAP! It's exciting. But... > > Looking at the page, I really, really am still not a fan of using > 'type' in place of *, and I still think (as I mentioned on Reddit I > believe) that 'Type' is the best choice for this. I mentioned this to > Simon earlier, and I kind of hate to make even more work for you, but > my basic reasoning is: > > - '*' is not a good choice because it's a lexical wart. But in terms > of 'theory', the statement '* :: *' is completely OK, or 'type :: > type' or or 'U :: U' or 'Type :: Type'. That is, the reason star is > bad is because it's a lexical problem that leads to weird ambiguous > parsing, not that it's necessarily confusing or using any particular > word I think. > > - 'type' is not a good choice, because while in theory any name is > kind of arbitrary, it's very confusing for Haskell IMO - we have > _chosen_ the distinction between type variables and type constructors > through the use of capitalization. I think it's a bit strange to say > '*' or what have you has type 'type' yet 'type' is not an actual > variable, nor a keyword in a meaningful sense, but an actual type on > its own. Yet 0-arity type constructors of all sorts (like Int or Bool) > have this lexical capitalization! That is, 'type' isn't confusing > because it's a lexical wart, or has bad parsing - but because it > violates how we syntactically distinguish type variables from > constructors of types. > > - (Correct if I'm wrong) As far as I understand, 'Type' doesn't need > to be reserved unless -XTypeInType is enabled, correct? I think it is > fairly reasonable to say that extensions may take up parts of your > namespace should you enable them - for example, -XStaticPointers > steals the term 'static' for itself, which I think is OK! > > - As far as code breakage goes, I think the prior point makes the > outright breakage minimal-to-none if true, which is great. Even GHC > uses the name `Type`, but we wouldn't even be able to use -XTypeInType > for another few years at best! So we have plenty of time to address > that when we want to use it... > > I suppose #2 is a little 'feels-y', since 'violating' how we expect to > read Haskell is maybe subjective. But I figure I might as well make a > last ditch effort at the cost of a little stirring. > > I think that mostly sums it up. I'm still reading over the full page, > I just got to this point and decided to shout. (Wadler's Law strikes > again!) > > > On Tue, Oct 13, 2015 at 12:32 PM, Richard Eisenberg > wrote: > > Hi devs, > > > > In a chat with Simon this morning about kind equalities, he expressed > that you all might want to know about the plans for kind equalities in 8.0. > > > > The wiki page both for user-facing changes and for implementation notes > is here: https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Phase1 > > It is my intent that all user-facing changes mentioned there will be > available in 8.0. I am hard at work getting my branch ready to merge, and > hope to do so mid-November. > > > > Note: this is almost fully backward-compatible. Here are some areas > where there are known incompatibilities: > > - Template Haskell will have to be updated. But there's a raft of > changes there, anyway. > > - GHC will do a more careful job of checking for termination of > instances regarding the use of kind variables. This may require new > UndecidableInstances declarations. But the fact that these definitions > (like `instance (C a, C b) => C (a b)` for a polykinded C) were accepted > previously could be called a bug. > > > > That's actually all I know of so far. > > > > You can take kind equalities for a spin at github.com/goldfirere/ghc, > on the "nokinds" branch. Note that this hasn't been merged with `master` > since December of last year, so expect a little strange behavior compared > with 7.10. These wrinkles will get smoothed out, of course. > > > > Richard > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > _______________________________________________ > 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 carter.schonwald at gmail.com Wed Oct 14 01:16:49 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 13 Oct 2015 21:16:49 -0400 Subject: Request to reopen the issue of 7.8 on El Capitan In-Reply-To: References: Message-ID: I'll see if I can bake a build from source myself and share it. On Tuesday, October 13, 2015, Austin Seipp wrote: > I wasn't aware it completely broke on El Capitan, but I think that's a > pretty extreme case (where a completely usable release simply breaks > because a hugely popular OS changes) that would warrant a 7.8.5 > release, to be honest. Presumably, this would really be the only > change, so mostly OS X users would be affected by its availability. > > In general people like to use the last 3 GHC releases anyway, and we > haven't even *released* 8.0 yet. And at that point, 7.8.x will be the > last 'in the chain' - so I can assume people would _still_ want 7.8 on > OS X presumably, even more than a year from today until 8.2! > > At that point (8.2-ish era) if Apple keeps breaking things, we may not > do another release, but in this case I think the timescale for > user/library support is probably worth it. Otherwise OS X users are > going to have to fix it themselves, and it might be ugly (propagating > random fixes around the internet isn't going to work well, and we'll > just keep getting bug reports about this because of that - we've > already done this dance with OS X.) > > I'll note this down and think about it more this week, since we'd like > to get 7.10.3 out soon as well... > > On Tue, Oct 13, 2015 at 7:55 PM, Adam Foltzer > wrote: > > 7.8.4 is was released only ten months ago; it surprises me that we'd > > consider it acceptable to have such a recent release fail to work on new > > machines when the fix is so small as to not even require a patch to the > > source tree. In particular, I remember hearing proponents of 7.10's > changes > > reassure detractors that if they choose, they can continue to use 7.8.4, > > which is no longer an option. > > > > I'd ask that we (1) reconsider the decision to stop 7.8 releases, and > (2) if > > we stand by the decision, document the mitigations for users who would > like > > to build their own working version of the compiler. I just finished a > build > > from a source dist with `unix-2.7.1.0` and it still triggers the El > Capitan > > error, so I suspect it's not as simple as just dropping the new package > into > > `/libraries/unix/`. > > > > On Tue, Oct 13, 2015 at 4:19 PM, Carter Schonwald > > > wrote: > >> > >> There are no plans to do a new 7.8 release at this Time. Even doing a > >> point release for 7.10.3 is still speculative. > >> > >> We should reflect the capitan issue in the installation documentation. > >> And or remark that only 7.10 or newer is supported on El Capitan. > >> > >> If a user needs a 7.8 build that works on capitan, they will need to > build > >> a source dist with an updated UNIX package. > >> > >> > >> On Tuesday, October 13, 2015, Adam Foltzer > wrote: > >>> > >>> Hello, > >>> > >>> The issue was brought up on this list [1] that the released versions of > >>> GHC 7.8 do not work on El Capitan due to an older `unix` package. In a > >>> subsequent GHC weekly news [2], it was announced that since El Capitan > >>> wasn't yet released, it wasn't worthwhile to put more developer time > into > >>> 7.8. > >>> > >>> Now that El Capitan is out, and the existing 7.8 binaries continue to > not > >>> work, I'd like to reopen this issue and request a point release with an > >>> updated `unix` package. > >>> > >>> Thank you, > >>> > >>> Adam Foltzer > >>> Research Engineer > >>> Galois, Inc. > >>> > >>> [1]: https://mail.haskell.org/pipermail/ghc-devs/2015-July/009403.html > >>> [2]: > >>> > https://ghc.haskell.org/trac/ghc/blog/weekly20150721#MacOSXElCapitansupport > > > > > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Wed Oct 14 02:27:02 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Tue, 13 Oct 2015 22:27:02 -0400 Subject: Kind equalities update In-Reply-To: References: <590FE375-7B7A-486F-884B-789BC7F847D0@cis.upenn.edu> Message-ID: This feedback is very helpful. And no direction here is more work than any other -- I haven't implemented this piece yet. I'm not tied, at all, to `type`. I just personally think it's the best option. But it's completely a stylistic choice, and I'm quite happy to go with the majority on this point. As a counter-argument to the "hard to parse for humans" point: any syntax-highlighter for Haskell will color `type` differently, significantly easing this problem. And I'll also say that * is very confusing to beginners, in my experience: lots of people (myself included at one point) think that * is somehow a wildcard. If we do adopt Type, there's no reason we have to reserve it. It could be exported from, say, Data.Kind (along with Constraint). Once (which may be never) we remove *, users who want kind annotations will just have to import a module. So, using Type would be just as backward-compatible as any other decision. Because we'll have kind synonyms, a large codebase could even type `type TYPE = Data.Kind.Type` or something to avoid name clashes. (This trick would work with any solution... even just leaving * alone!) To be very clear: I'm *not* proposing removing * anytime soon! Following the decision to aim for a 3-year window of warning-free code, we couldn't remove * until there have been 2 years of having an alternative. And even then, it's not clear to me that it's worth the trouble. Maybe we'll just deprecate it with no intent to remove. But we can wait to have that debate later. Again, thanks for the feedback! Richard On Oct 13, 2015, at 9:09 PM, Christopher Allen wrote: > My opinion may not count for a lot from a compiler engineering perspective, but I can say with a fair bit of confidence that violating the "capitalized -> concrete constructor, lowercase -> variable" convention for types would be _very_ surprising to learners and users. I don't think it's a petty issue at all. This isn't a mistake we have to live with, even if it's regrettable that it's more work for Richard. > > >(Wadler's Law strikes again!) > > Apologies for my contributions on this front, didn't disagree with anything else and wanted to bolster Austin's concerns here. > > On Tue, Oct 13, 2015 at 7:37 PM, Austin Seipp wrote: > Hey Richard, > > Thanks a lot. I'm very eager to see this land ASAP! It's exciting. But... > > Looking at the page, I really, really am still not a fan of using > 'type' in place of *, and I still think (as I mentioned on Reddit I > believe) that 'Type' is the best choice for this. I mentioned this to > Simon earlier, and I kind of hate to make even more work for you, but > my basic reasoning is: > > - '*' is not a good choice because it's a lexical wart. But in terms > of 'theory', the statement '* :: *' is completely OK, or 'type :: > type' or or 'U :: U' or 'Type :: Type'. That is, the reason star is > bad is because it's a lexical problem that leads to weird ambiguous > parsing, not that it's necessarily confusing or using any particular > word I think. > > - 'type' is not a good choice, because while in theory any name is > kind of arbitrary, it's very confusing for Haskell IMO - we have > _chosen_ the distinction between type variables and type constructors > through the use of capitalization. I think it's a bit strange to say > '*' or what have you has type 'type' yet 'type' is not an actual > variable, nor a keyword in a meaningful sense, but an actual type on > its own. Yet 0-arity type constructors of all sorts (like Int or Bool) > have this lexical capitalization! That is, 'type' isn't confusing > because it's a lexical wart, or has bad parsing - but because it > violates how we syntactically distinguish type variables from > constructors of types. > > - (Correct if I'm wrong) As far as I understand, 'Type' doesn't need > to be reserved unless -XTypeInType is enabled, correct? I think it is > fairly reasonable to say that extensions may take up parts of your > namespace should you enable them - for example, -XStaticPointers > steals the term 'static' for itself, which I think is OK! > > - As far as code breakage goes, I think the prior point makes the > outright breakage minimal-to-none if true, which is great. Even GHC > uses the name `Type`, but we wouldn't even be able to use -XTypeInType > for another few years at best! So we have plenty of time to address > that when we want to use it... > > I suppose #2 is a little 'feels-y', since 'violating' how we expect to > read Haskell is maybe subjective. But I figure I might as well make a > last ditch effort at the cost of a little stirring. > > I think that mostly sums it up. I'm still reading over the full page, > I just got to this point and decided to shout. (Wadler's Law strikes > again!) > > > On Tue, Oct 13, 2015 at 12:32 PM, Richard Eisenberg wrote: > > Hi devs, > > > > In a chat with Simon this morning about kind equalities, he expressed that you all might want to know about the plans for kind equalities in 8.0. > > > > The wiki page both for user-facing changes and for implementation notes is here: https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Phase1 > > It is my intent that all user-facing changes mentioned there will be available in 8.0. I am hard at work getting my branch ready to merge, and hope to do so mid-November. > > > > Note: this is almost fully backward-compatible. Here are some areas where there are known incompatibilities: > > - Template Haskell will have to be updated. But there's a raft of changes there, anyway. > > - GHC will do a more careful job of checking for termination of instances regarding the use of kind variables. This may require new UndecidableInstances declarations. But the fact that these definitions (like `instance (C a, C b) => C (a b)` for a polykinded C) were accepted previously could be called a bug. > > > > That's actually all I know of so far. > > > > You can take kind equalities for a spin at github.com/goldfirere/ghc, on the "nokinds" branch. Note that this hasn't been merged with `master` since December of last year, so expect a little strange behavior compared with 7.10. These wrinkles will get smoothed out, of course. > > > > Richard > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > _______________________________________________ > 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 mle+hs at mega-nerd.com Wed Oct 14 06:28:46 2015 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Wed, 14 Oct 2015 17:28:46 +1100 Subject: GHC and LLVM Message-ID: <20151014172846.9591aa22e257045d10690cea@mega-nerd.com> Hi all, As some of you may have noticed the LLVM requirements for GHC HEAD has just switched from version 3.6 to 3.7. This was mainly to support Arm64 (aka AArch64 aka Armv8-a), for which llvm-3.6 was badly broken. Since figuring out what needed to change from 3.6 to 3.7 was rather painful, I decided to set up a small project to help us GHC devs keep up with what happens in the LLVM dev world. http://github.com/erikd/ghc-llvm-next/ The project is a build script (actually a Makefile) and a set of patches) which does the followiing: * clones/updates LLVM from git, builds it and installs it locally * clones/updates GHC from git * applies patches git GHC so that GHC builds against the locally build LLVM tools. * builds GHC and then runs the testsuite I plan on running the above build on a daily basis in my own personal Jenkins instance in order to track changes in GHC and LLVM. Others are free to do the same and I'm happy to take pull requests. This project may also be interesting or useful for people testing out up-coming LLVM features with GHC. Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From simonpj at microsoft.com Wed Oct 14 08:31:48 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 14 Oct 2015 08:31:48 +0000 Subject: Kind equalities update In-Reply-To: References: <590FE375-7B7A-486F-884B-789BC7F847D0@cis.upenn.edu> Message-ID: <1cb8bb74044740828b2e478adf563cc9@DB4PR30MB030.064d.mgd.msft.net> FWIW I think I'm in favour of "Type" (over "type") too. Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Richard Eisenberg Sent: 14 October 2015 03:27 To: ghc-devs at haskell.org Devs Subject: Re: Kind equalities update This feedback is very helpful. And no direction here is more work than any other -- I haven't implemented this piece yet. I'm not tied, at all, to `type`. I just personally think it's the best option. But it's completely a stylistic choice, and I'm quite happy to go with the majority on this point. As a counter-argument to the "hard to parse for humans" point: any syntax-highlighter for Haskell will color `type` differently, significantly easing this problem. And I'll also say that * is very confusing to beginners, in my experience: lots of people (myself included at one point) think that * is somehow a wildcard. If we do adopt Type, there's no reason we have to reserve it. It could be exported from, say, Data.Kind (along with Constraint). Once (which may be never) we remove *, users who want kind annotations will just have to import a module. So, using Type would be just as backward-compatible as any other decision. Because we'll have kind synonyms, a large codebase could even type `type TYPE = Data.Kind.Type` or something to avoid name clashes. (This trick would work with any solution... even just leaving * alone!) To be very clear: I'm *not* proposing removing * anytime soon! Following the decision to aim for a 3-year window of warning-free code, we couldn't remove * until there have been 2 years of having an alternative. And even then, it's not clear to me that it's worth the trouble. Maybe we'll just deprecate it with no intent to remove. But we can wait to have that debate later. Again, thanks for the feedback! Richard On Oct 13, 2015, at 9:09 PM, Christopher Allen > wrote: My opinion may not count for a lot from a compiler engineering perspective, but I can say with a fair bit of confidence that violating the "capitalized -> concrete constructor, lowercase -> variable" convention for types would be _very_ surprising to learners and users. I don't think it's a petty issue at all. This isn't a mistake we have to live with, even if it's regrettable that it's more work for Richard. >(Wadler's Law strikes again!) Apologies for my contributions on this front, didn't disagree with anything else and wanted to bolster Austin's concerns here. On Tue, Oct 13, 2015 at 7:37 PM, Austin Seipp > wrote: Hey Richard, Thanks a lot. I'm very eager to see this land ASAP! It's exciting. But... Looking at the page, I really, really am still not a fan of using 'type' in place of *, and I still think (as I mentioned on Reddit I believe) that 'Type' is the best choice for this. I mentioned this to Simon earlier, and I kind of hate to make even more work for you, but my basic reasoning is: - '*' is not a good choice because it's a lexical wart. But in terms of 'theory', the statement '* :: *' is completely OK, or 'type :: type' or or 'U :: U' or 'Type :: Type'. That is, the reason star is bad is because it's a lexical problem that leads to weird ambiguous parsing, not that it's necessarily confusing or using any particular word I think. - 'type' is not a good choice, because while in theory any name is kind of arbitrary, it's very confusing for Haskell IMO - we have _chosen_ the distinction between type variables and type constructors through the use of capitalization. I think it's a bit strange to say '*' or what have you has type 'type' yet 'type' is not an actual variable, nor a keyword in a meaningful sense, but an actual type on its own. Yet 0-arity type constructors of all sorts (like Int or Bool) have this lexical capitalization! That is, 'type' isn't confusing because it's a lexical wart, or has bad parsing - but because it violates how we syntactically distinguish type variables from constructors of types. - (Correct if I'm wrong) As far as I understand, 'Type' doesn't need to be reserved unless -XTypeInType is enabled, correct? I think it is fairly reasonable to say that extensions may take up parts of your namespace should you enable them - for example, -XStaticPointers steals the term 'static' for itself, which I think is OK! - As far as code breakage goes, I think the prior point makes the outright breakage minimal-to-none if true, which is great. Even GHC uses the name `Type`, but we wouldn't even be able to use -XTypeInType for another few years at best! So we have plenty of time to address that when we want to use it... I suppose #2 is a little 'feels-y', since 'violating' how we expect to read Haskell is maybe subjective. But I figure I might as well make a last ditch effort at the cost of a little stirring. I think that mostly sums it up. I'm still reading over the full page, I just got to this point and decided to shout. (Wadler's Law strikes again!) On Tue, Oct 13, 2015 at 12:32 PM, Richard Eisenberg > wrote: > Hi devs, > > In a chat with Simon this morning about kind equalities, he expressed that you all might want to know about the plans for kind equalities in 8.0. > > The wiki page both for user-facing changes and for implementation notes is here: https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Phase1 > It is my intent that all user-facing changes mentioned there will be available in 8.0. I am hard at work getting my branch ready to merge, and hope to do so mid-November. > > Note: this is almost fully backward-compatible. Here are some areas where there are known incompatibilities: > - Template Haskell will have to be updated. But there's a raft of changes there, anyway. > - GHC will do a more careful job of checking for termination of instances regarding the use of kind variables. This may require new UndecidableInstances declarations. But the fact that these definitions (like `instance (C a, C b) => C (a b)` for a polykinded C) were accepted previously could be called a bug. > > That's actually all I know of so far. > > You can take kind equalities for a spin at github.com/goldfirere/ghc, on the "nokinds" branch. Note that this hasn't been merged with `master` since December of last year, so expect a little strange behavior compared with 7.10. These wrinkles will get smoothed out, of course. > > Richard > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ _______________________________________________ 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 alexander at plaimi.net Wed Oct 14 09:17:07 2015 From: alexander at plaimi.net (Alexander Berntsen) Date: Wed, 14 Oct 2015 11:17:07 +0200 Subject: Kind equalities update In-Reply-To: <1cb8bb74044740828b2e478adf563cc9@DB4PR30MB030.064d.mgd.msft.net> References: <590FE375-7B7A-486F-884B-789BC7F847D0@cis.upenn.edu> <1cb8bb74044740828b2e478adf563cc9@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <561E1D93.5040004@plaimi.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 14/10/15 10:31, Simon Peyton Jones wrote: > FWIW I think I'm in favour of "Type" (over "type") too. I am as well. In fact, Type > * > type > *, where the first * is the one we have today, and the second * is the wildcard. That should underline how much I dislike "type". ;) - -- Alexander alexander at plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJWHh2SAAoJENQqWdRUGk8BY9QQAK+Hf3MWYNi+4ujUV5aPe9FH uGp3OWBVmkRpy8Ry6fzUnypkpcZzCGwM+8SEB5g/nylXUPXDB0MC7wYgMv6zgml3 Eom0avIWx5EO1h5k/eJUp1MND/LKboVADYaOJdL35d32BkJViiLujhlZaNjBurnj guLSm5eFGHPf0zlovUDUzzBBpYTH9nxgT7K4DPH2pHu5a/gyr7GKP/aZa+1LoEm8 Zt31v7m6U3LocYt71ZxYHFrrIuzR8PPK2SmqEruNes2+UAvVuuqybp/caQOfJZ93 9iNqQueYRqG4eMXYQgbHza1GYI8N7I7IXjpg16xkrglyhYRH18eDrsTHesNzn2Ah BkLIIIbAja2R0FvhZ3dRxY3g8kavhmNQjAtWLUcumhmXYLDUnIFMCR5p/CqWMAR2 eNgtDUtDqwfBz6jx9B5WRz+YgtaY5uYPHBzlzVl8+VOKRwWyjdUBdTpHPb5EKIYU PhHqhymejnvwy9yCPsvOMBVgVNjuxVvntcnqI3ZhhlqOc2D6F63NQej3E5fJN9eg QTFD2cY8+7DQ1NbzRQP0IsEQ566r3KkPzaV8dJ76DTbBgjtZ6lBpSR7z1U3e+ySd FqmtDEuoVNb1iGvbLWdBgH0A6E2wXxV10zMsAax65I3Pkskmz1qBIPptgcRCvfin iEi1wmEk7/aPE9B6Cq3s =E+WD -----END PGP SIGNATURE----- From simonpj at microsoft.com Wed Oct 14 12:02:21 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 14 Oct 2015 12:02:21 +0000 Subject: Strictness/demand analysis without worker/wrapper, or, reviving -fmax-worker-args In-Reply-To: References: Message-ID: <89920fc16135409cb4c2f5363bf49de9@DB4PR30MB030.064d.mgd.msft.net> Some quick thoughts: * It would make perfect sense to run the demand analyser without the worker/wrapper transform, yes. By all means make a patch to make that easy to do. Do NOT do this by setting -fmax-worker-args=0; that would be a hack even if it worked; and as you say it probably doesn't. * The -fmax-worker-args flag is supposed to stop GHC unpacking a function with a zillion fields. E.g. suppose we have f :: (Int,Int,Int, ..., Int, Int) -> Int which, say, adds up all the field of a 200-tuple. It would probably gain little to worker/wrapper this, because the worker would get 200 arguments. Maybe that's ok, but the gain over allocating the arg tuple in the heap is proportionately less. But clearly some refactoring lost this ability. Maybe someone should put it back! I have no evidence, either way, to suggest that limiting the # of args to a worker would be beneficial. Just a kind of intuition. Simon | As a GHC API user, I would like to run GHC?s strictness and demand analysis | pass, but I don?t want any worker/wrappers. | My specific use-case is to generate digital circuits from Haskell code, | where I?ve yet to encounter any benefit from worker/wrappers: the generated | circuits do not get any smaller or faster. | They do however induce longer compilation times for my compiler. | I still want to have GHC?s strictness and demand analysis, because, if I | understand correctly, the demand and strictness annotations are needed by | GHC?s dead code analysis (and other optimisations) which is beneficial for | my use case. | | Looking through DynFlags, I encountered the ?maxWorkerArgs? field, which is | controlled by ?-fmax-worker-args?. | The user guide says the following: | "If a worker has that many arguments, none will be unpacked anymore | (default: 10)? | I don?t know exactly what this means, but I was hoping that if I would set | that number to 0 (zero), no worker/wrapper pairs would be created. | Is that correct? | | The reason that I?m asking is because -fmax-worker-args is basically dead | code. | The ?maxWorkerArgs? field of DynFlags is not used anywhere. | If setting ?-fmax-worker-args? to zero does indeed prevent any | worker/wrappers from being generated, should I reimplement the flag and | submit it as a patch? | Or, is it preferable to simply remove ?-fmax-worker-args? (given that it | doesn?t do anything right now), and create a new flag, ?-fno-worker- | wrapper?, that simply disables the creation of worker/wrapper pairs | everywhere? | | Regards, | | Christiaan | _______________________________________________ | 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%7c6c87f8a67afa4d8c78 | 8108d2d3238a16%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=vk8RNAbzZpj63RRu | SQV%2fPDS7trt6puHaEhXBSHbIZQ0%3d From eir at cis.upenn.edu Wed Oct 14 13:17:18 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Wed, 14 Oct 2015 09:17:18 -0400 Subject: Kind equalities update In-Reply-To: <561E1D93.5040004@plaimi.net> References: <590FE375-7B7A-486F-884B-789BC7F847D0@cis.upenn.edu> <1cb8bb74044740828b2e478adf563cc9@DB4PR30MB030.064d.mgd.msft.net> <561E1D93.5040004@plaimi.net> Message-ID: Bah. I give in. :) `Type` it shall be. (And * will stay. But please use `Type`!) On Oct 14, 2015, at 5:17 AM, Alexander Berntsen wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 14/10/15 10:31, Simon Peyton Jones wrote: >> FWIW I think I'm in favour of "Type" (over "type") too. > I am as well. > > In fact, Type > * > type > *, where the first * is the one we have > today, and the second * is the wildcard. That should underline how > much I dislike "type". ;) > - -- > Alexander > alexander at plaimi.net > https://secure.plaimi.net/~alexander > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQIcBAEBCgAGBQJWHh2SAAoJENQqWdRUGk8BY9QQAK+Hf3MWYNi+4ujUV5aPe9FH > uGp3OWBVmkRpy8Ry6fzUnypkpcZzCGwM+8SEB5g/nylXUPXDB0MC7wYgMv6zgml3 > Eom0avIWx5EO1h5k/eJUp1MND/LKboVADYaOJdL35d32BkJViiLujhlZaNjBurnj > guLSm5eFGHPf0zlovUDUzzBBpYTH9nxgT7K4DPH2pHu5a/gyr7GKP/aZa+1LoEm8 > Zt31v7m6U3LocYt71ZxYHFrrIuzR8PPK2SmqEruNes2+UAvVuuqybp/caQOfJZ93 > 9iNqQueYRqG4eMXYQgbHza1GYI8N7I7IXjpg16xkrglyhYRH18eDrsTHesNzn2Ah > BkLIIIbAja2R0FvhZ3dRxY3g8kavhmNQjAtWLUcumhmXYLDUnIFMCR5p/CqWMAR2 > eNgtDUtDqwfBz6jx9B5WRz+YgtaY5uYPHBzlzVl8+VOKRwWyjdUBdTpHPb5EKIYU > PhHqhymejnvwy9yCPsvOMBVgVNjuxVvntcnqI3ZhhlqOc2D6F63NQej3E5fJN9eg > QTFD2cY8+7DQ1NbzRQP0IsEQ566r3KkPzaV8dJ76DTbBgjtZ6lBpSR7z1U3e+ySd > FqmtDEuoVNb1iGvbLWdBgH0A6E2wXxV10zMsAax65I3Pkskmz1qBIPptgcRCvfin > iEi1wmEk7/aPE9B6Cq3s > =E+WD > -----END PGP SIGNATURE----- > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From chak at justtesting.org Thu Oct 15 01:53:22 2015 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Thu, 15 Oct 2015 12:53:22 +1100 Subject: GHC and LLVM In-Reply-To: <20151014172846.9591aa22e257045d10690cea@mega-nerd.com> References: <20151014172846.9591aa22e257045d10690cea@mega-nerd.com> Message-ID: <13FF39A2-B92B-47DA-BD55-C19C47F5AF16@justtesting.org> Hi Erik, That sounds great. Can your Jenkins instance maybe also push the reports to one of the GHC lists, so everybody can see what the state of play is? Thanks, Manuel > Erik de Castro Lopo : > > Hi all, > > As some of you may have noticed the LLVM requirements for GHC HEAD > has just switched from version 3.6 to 3.7. This was mainly to support > Arm64 (aka AArch64 aka Armv8-a), for which llvm-3.6 was badly broken. > > Since figuring out what needed to change from 3.6 to 3.7 was rather > painful, I decided to set up a small project to help us GHC devs > keep up with what happens in the LLVM dev world. > > http://github.com/erikd/ghc-llvm-next/ > > The project is a build script (actually a Makefile) and a set of > patches) which does the followiing: > > * clones/updates LLVM from git, builds it and installs it locally > * clones/updates GHC from git > * applies patches git GHC so that GHC builds against the locally > build LLVM tools. > * builds GHC and then runs the testsuite > > I plan on running the above build on a daily basis in my own > personal Jenkins instance in order to track changes in GHC and > LLVM. > > Others are free to do the same and I'm happy to take pull requests. > This project may also be interesting or useful for people testing > out up-coming LLVM features with GHC. > > Cheers, > Erik > -- > ---------------------------------------------------------------------- > Erik de Castro Lopo > http://www.mega-nerd.com/ > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From chak at justtesting.org Thu Oct 15 01:53:30 2015 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Thu, 15 Oct 2015 12:53:30 +1100 Subject: Applicative Comprehensions In-Reply-To: <1444640285.2250.9.camel@joachim-breitner.de> References: <1444640285.2250.9.camel@joachim-breitner.de> Message-ID: <53D9C422-EBCE-4447-BD1C-8C0372CF0760@justtesting.org> I certainly second that! Manuel > Joachim Breitner : > > Hi, > > Am Montag, den 12.10.2015, 08:09 +0000 schrieb David A Roberts: >> I understand that comprehensions tend not to be used much in >> idiomatic Haskell, > > quite contrary! I use them extensively in real-world-projects, and I > claim to write idomatic code :-) > > 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 mle+hs at mega-nerd.com Thu Oct 15 10:23:40 2015 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Thu, 15 Oct 2015 21:23:40 +1100 Subject: GHC and LLVM In-Reply-To: References: <20151014172846.9591aa22e257045d10690cea@mega-nerd.com> Message-ID: <20151015212340.587b30e9009eeaf3110479e5@mega-nerd.com> Manuel M T Chakravarty wrote: > That sounds great. Can your Jenkins instance maybe also push > the reports to one of the GHC lists, so everybody can see what > the state of play is? Well currently the report log is 7Meg and I'm sure everyone would appreciate it if I kept those to myself. Currently the state of play can be seen from the patches listed here: https://github.com/erikd/ghc-llvm-next/tree/master/patches These are the patches that currently need to be applied to GHC git HEAD to build it against LLVM git head. The first, 00-configure-3.8.patch switches GHC from using LLVM 3.7 to using 3.8. The second, 01-bitcast.patch is needed because the syntax of the bitcast operation has changed in some situations. The number of tests failing with this setup is the same as the number failing with GHC git head compiled against the 3.7 (and 3.6) release of LLVM. Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From marlowsd at gmail.com Thu Oct 15 10:59:32 2015 From: marlowsd at gmail.com (Simon Marlow) Date: Thu, 15 Oct 2015 11:59:32 +0100 Subject: Applicative Comprehensions In-Reply-To: References: Message-ID: <561F8714.9020102@gmail.com> On 12/10/2015 09:09, David A Roberts wrote: > Hi, > > I raised this question on #haskell, and was advised that this was > probably the best place to discuss. > > I see that Applicative Do is scheduled for GHC 8.0 [1], and was hoping > that this might also enable support for Applicative Comprehensions [2]. > Is this likely to be the case? If not, would it be difficult to extend > the support for Applicative Do to also handle comprehensions? I'm > willing to submit patches if necessary, but I'm not at all familiar with > GHC internals, so would need some guidance. > > I understand that comprehensions tend not to be used much in idiomatic > Haskell, but I find them to be useful for implementing DSLs, so would > really like to see this be supported. For example, a matrix could be > written in a familiar notation: > > > [ i + 2*j | i <- rows, j <- cols ] > > which is a little more readable (to those not familiar with Haskell) than > > > (\i j -> i + 2*j) <$> row <*> cols > > or > > > do { i <- rows; j <- cols; return (i + 2*j) } Good idea - it's not currently implemented, but it wouldn't be hard to do. Want to make a feature request and CC me on it? Sounds like something that might just fit into my train journey to work :) Cheers, Simon From ryan.gl.scott at gmail.com Thu Oct 15 12:16:10 2015 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Thu, 15 Oct 2015 08:16:10 -0400 Subject: Applicative Comprehensions Message-ID: There was a feature request made for this on Trac before ApplicativeDo was finished (https://ghc.haskell.org/trac/ghc/ticket/8914), so generalizing monad comprehensions would fix half of Trac #8914. (The other half, which proposes generalizing ParallelListComp, would require an API change, so it might be better to tackle that separately.) Regards, Ryan S. -------------- next part -------------- An HTML attachment was scrubbed... URL: From christiaan.baaij at gmail.com Thu Oct 15 16:03:07 2015 From: christiaan.baaij at gmail.com (Christiaan Baaij) Date: Thu, 15 Oct 2015 18:03:07 +0200 Subject: Fwd: Strictness/demand analysis without worker/wrapper, or, reviving -fmax-worker-args References: <27AD5094-5202-4197-BC62-DEED2E474581@gmail.com> Message-ID: Forgot to also send to the list > Begin forwarded message: > > From: Christiaan Baaij > Subject: Re: Strictness/demand analysis without worker/wrapper, or, reviving -fmax-worker-args > Date: 15 Oct 2015 17:27:21 CEST > To: Simon Peyton Jones > > Thanks for the comments, I will create a patch for a -fno-worker-wrapper flag somewhere next week then. > > I?ll also see about reviving -fmax-worker-args. > Although it?s not used by any package on Hackage, and it has been dead for over 2 years now I think. > > ? Christiaan > >> On 14 Oct 2015, at 14:02, Simon Peyton Jones wrote: >> >> Some quick thoughts: >> >> * It would make perfect sense to run the demand analyser without the worker/wrapper transform, yes. By all means make a patch to make that easy to do. Do NOT do this by setting -fmax-worker-args=0; that would be a hack even if it worked; and as you say it probably doesn't. >> >> * The -fmax-worker-args flag is supposed to stop GHC unpacking a function with a zillion fields. E.g. suppose we have >> f :: (Int,Int,Int, ..., Int, Int) -> Int >> which, say, adds up all the field of a 200-tuple. It would probably gain little to worker/wrapper this, because the worker would get 200 arguments. Maybe that's ok, but the gain over allocating the arg tuple in the heap is proportionately less. >> >> But clearly some refactoring lost this ability. Maybe someone should put it back! >> >> I have no evidence, either way, to suggest that limiting the # of args to a worker would be beneficial. Just a kind of intuition. >> >> >> Simon >> >> >> | As a GHC API user, I would like to run GHC?s strictness and demand analysis >> | pass, but I don?t want any worker/wrappers. >> | My specific use-case is to generate digital circuits from Haskell code, >> | where I?ve yet to encounter any benefit from worker/wrappers: the generated >> | circuits do not get any smaller or faster. >> | They do however induce longer compilation times for my compiler. >> | I still want to have GHC?s strictness and demand analysis, because, if I >> | understand correctly, the demand and strictness annotations are needed by >> | GHC?s dead code analysis (and other optimisations) which is beneficial for >> | my use case. >> | >> | Looking through DynFlags, I encountered the ?maxWorkerArgs? field, which is >> | controlled by ?-fmax-worker-args?. >> | The user guide says the following: >> | "If a worker has that many arguments, none will be unpacked anymore >> | (default: 10)? >> | I don?t know exactly what this means, but I was hoping that if I would set >> | that number to 0 (zero), no worker/wrapper pairs would be created. >> | Is that correct? >> | >> | The reason that I?m asking is because -fmax-worker-args is basically dead >> | code. >> | The ?maxWorkerArgs? field of DynFlags is not used anywhere. >> | If setting ?-fmax-worker-args? to zero does indeed prevent any >> | worker/wrappers from being generated, should I reimplement the flag and >> | submit it as a patch? >> | Or, is it preferable to simply remove ?-fmax-worker-args? (given that it >> | doesn?t do anything right now), and create a new flag, ?-fno-worker- >> | wrapper?, that simply disables the creation of worker/wrapper pairs >> | everywhere? >> | >> | Regards, >> | >> | Christiaan >> | _______________________________________________ >> | 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%7c6c87f8a67afa4d8c78 >> | 8108d2d3238a16%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=vk8RNAbzZpj63RRu >> | SQV%2fPDS7trt6puHaEhXBSHbIZQ0%3d > -------------- next part -------------- An HTML attachment was scrubbed... URL: From d at vidr.cc Fri Oct 16 05:24:35 2015 From: d at vidr.cc (David A Roberts) Date: Fri, 16 Oct 2015 05:24:35 +0000 Subject: Applicative Comprehensions In-Reply-To: References: Message-ID: Simon: Thanks, that would be great. I've opened #10976 < https://ghc.haskell.org/trac/ghc/ticket/10976> On Thu, 15 Oct 2015 at 22:16 Ryan Scott wrote: > There was a feature request made for this on Trac before ApplicativeDo was > finished (https://ghc.haskell.org/trac/ghc/ticket/8914), so generalizing > monad comprehensions would fix half of Trac #8914. (The other half, which > proposes generalizing ParallelListComp, would require an API change, so it > might be better to tackle that separately.) > > Regards, > Ryan S. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- David A Roberts https://davidar.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Fri Oct 16 05:33:23 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Thu, 15 Oct 2015 22:33:23 -0700 Subject: Request to reopen the issue of 7.8 on El Capitan In-Reply-To: References: Message-ID: I can build a 7.8.5 binary for release if someone can put the patch in the GHC tree. (Having a soft spot in my heart for the 7.8 line!) I'm leaving on a short trip, and will be back on Tuesday and build middle of next week. ? - Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Fri Oct 16 10:37:20 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 16 Oct 2015 10:37:20 +0000 Subject: [Differential] [Commented On] D761: Implement DuplicateRecordFields In-Reply-To: <20151016081229.75678.74156@phabricator.haskell.org> References: <20151016081229.75678.74156@phabricator.haskell.org> Message-ID: <02b5ca2ffbf94f9eaa4cb9374aee4bd4@AM3PR30MB019.064d.mgd.msft.net> Adam | Is it okay for me to go ahead and merge this? I'll resolve | whatever conflicts there are and do a final validate before merging.I think so, yes. You might want to talk to Matthew Pickering, who is scared about the rebase work he'll have to do on https://phabricator.haskell.org/D1152 Simon | -----Original Message----- | From: noreply at phabricator.haskell.org | [mailto:noreply at phabricator.haskell.org] | Sent: 16 October 2015 09:13 | To: Simon Peyton Jones | Subject: [Differential] [Commented On] D761: Implement DuplicateRecordFields | | adamgundry added a comment. | | This builds fine on Travis | but not on | Phab, I suspect because the diff needs to be updated to apply cleanly to the | latest HEAD. Is it okay for me to go ahead and merge this? I'll resolve | whatever conflicts there are and do a final validate before merging. | | | REPOSITORY | rGHC Glasgow Haskell Compiler | | REVISION DETAIL | https://phabricator.haskell.org/D761 | | EMAIL PREFERENCES | https://phabricator.haskell.org/settings/panel/emailpreferences/ | | To: adamgundry, goldfire, bgamari, simonpj, austin | Cc: sjcjoosten, haggholm, mpickering, bgamari, tibbe, thomie, goldfire From dluposchainsky at googlemail.com Fri Oct 16 16:09:37 2015 From: dluposchainsky at googlemail.com (David Luposchainsky) Date: Fri, 16 Oct 2015 18:09:37 +0200 Subject: MonadFail decisions In-Reply-To: References: Message-ID: <56212141.7050004@gmail.com> On 13.10.2015 16:29, Simon Peyton Jones wrote: > Also, David, did our conversation at HX help you get un-stuck? Hi Simon, yes, it was definitely a good pointer. On the other hand, I found the Haskell Exchange to be quite a frustrating event with respect to current events: there was a load of very loud, but in my opinion very wrong, categorical opposition to breaking changes in general. I spent quite a bit of time worrying about MonadFail in the past, but right now I'd like to wait for a "tentative yes" from the CLC before I keep going, because I'm really not sure the mob is going to make me throw away my patch. Granted, a lot of the discussion is about MRP, but many of the points brought up there are equally valid against the MFP. David From ekmett at gmail.com Fri Oct 16 16:22:47 2015 From: ekmett at gmail.com (Edward Kmett) Date: Fri, 16 Oct 2015 12:22:47 -0400 Subject: MonadFail decisions In-Reply-To: <56212141.7050004@gmail.com> References: <56212141.7050004@gmail.com> Message-ID: The current intention is to go ahead with MonadFail. It sounds like we'll need to delay the warnings themselves until around 8.4. We can add them, but not turn them on by default in the short term. This has the knock-on effect of delaying the whole plan a release or two, but otherwise the plan is very actionable. A lot of the opposition comes from fear that we 'might do anything at any time'. If we're up front about what is coming and give sufficient notice and the ability for folks to maintain a reasonably wide backwards compatibility window without needing to dip into CPP or suppress warnings them most of those fears go away. -Edward On Fri, Oct 16, 2015 at 12:09 PM, David Luposchainsky < dluposchainsky at googlemail.com> wrote: > On 13.10.2015 16:29, Simon Peyton Jones wrote: > > Also, David, did our conversation at HX help you get un-stuck? > > Hi Simon, > > yes, it was definitely a good pointer. On the other hand, I found the > Haskell > Exchange to be quite a frustrating event with respect to current events: > there > was a load of very loud, but in my opinion very wrong, categorical > opposition to > breaking changes in general. > I spent quite a bit of time worrying about MonadFail in the past, but > right now > I'd like to wait for a "tentative yes" from the CLC before I keep going, > because > I'm really not sure the mob is going to make me throw away my patch. > Granted, a > lot of the discussion is about MRP, but many of the points brought up > there are > equally valid against the MFP. > > David > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Fri Oct 16 16:41:19 2015 From: ekmett at gmail.com (Edward Kmett) Date: Fri, 16 Oct 2015 12:41:19 -0400 Subject: MonadFail decisions In-Reply-To: <56212141.7050004@gmail.com> References: <56212141.7050004@gmail.com> Message-ID: Hi David, I took the time to update the MonadFail wiki page to include both the timeline currently under consideration, lengthening the timeline to finish in 8.8 to comply with the "3 release policy" and to ensure that folks always have a notification of pending breaking changes. I included a couple of personal comments about the desugaring in 1.3 where we could do better. The improvements in 1.3 could be made any time over the 8.0 and 8.2 releases before we start expecting people to cut over in 8.4 without impact. As for the "mob", please keep in mind that the vast majority of feedback about the MonadFail proposal has been positive and draw heart from that. Many of the folks who were against the Foldable/Traversable generalizations (e.g. Lennart) are heavily in favor of MFP. -Edward On Fri, Oct 16, 2015 at 12:09 PM, David Luposchainsky < dluposchainsky at googlemail.com> wrote: > On 13.10.2015 16:29, Simon Peyton Jones wrote: > > Also, David, did our conversation at HX help you get un-stuck? > > Hi Simon, > > yes, it was definitely a good pointer. On the other hand, I found the > Haskell > Exchange to be quite a frustrating event with respect to current events: > there > was a load of very loud, but in my opinion very wrong, categorical > opposition to > breaking changes in general. > I spent quite a bit of time worrying about MonadFail in the past, but > right now > I'd like to wait for a "tentative yes" from the CLC before I keep going, > because > I'm really not sure the mob is going to make me throw away my patch. > Granted, a > lot of the discussion is about MRP, but many of the points brought up > there are > equally valid against the MFP. > > David > -------------- next part -------------- An HTML attachment was scrubbed... URL: From howard_b_golden at yahoo.com Fri Oct 16 17:06:37 2015 From: howard_b_golden at yahoo.com (Howard B. Golden) Date: Fri, 16 Oct 2015 17:06:37 +0000 (UTC) Subject: MonadFail decisions In-Reply-To: References: Message-ID: <882994362.1542481.1445015197423.JavaMail.yahoo@mail.yahoo.com> On Friday, October 16, 2015 9:22 AM, Edward Kmett wrote: > It sounds like we'll need to delay the warnings themselves until around 8.4. I propose an optional generic flag -fearly-warning (pun slightly intended) to get _all_ warnings of planned changes. Howard From ekmett at gmail.com Fri Oct 16 17:17:16 2015 From: ekmett at gmail.com (Edward Kmett) Date: Fri, 16 Oct 2015 13:17:16 -0400 Subject: MonadFail decisions In-Reply-To: <882994362.1542481.1445015197423.JavaMail.yahoo@mail.yahoo.com> References: <882994362.1542481.1445015197423.JavaMail.yahoo@mail.yahoo.com> Message-ID: Not a bad idea. I think Herbert was talking about calling it -Wcompat or something. On Fri, Oct 16, 2015 at 1:06 PM, Howard B. Golden wrote: > On Friday, October 16, 2015 9:22 AM, Edward Kmett wrote: > > > > It sounds like we'll need to delay the warnings themselves until around > 8.4. > > I propose an optional generic flag -fearly-warning (pun slightly intended) > to get _all_ warnings of planned changes. > > Howard > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dluposchainsky at googlemail.com Fri Oct 16 18:13:43 2015 From: dluposchainsky at googlemail.com (David Luposchainsky) Date: Fri, 16 Oct 2015 20:13:43 +0200 Subject: MonadFail decisions In-Reply-To: References: <56212141.7050004@gmail.com> Message-ID: <56213E57.9060805@gmail.com> On 16.10.2015 18:41, Edward Kmett wrote: > As for the "mob" I'd like to apologize for using that word. I think "crowd" would have been much closer to what I meant to say. There's no mob to be found here, since all the opinions - in favour or against - were stated in a very constructive way. So again, sorry about that. David From austin at well-typed.com Fri Oct 16 19:40:35 2015 From: austin at well-typed.com (Austin Seipp) Date: Fri, 16 Oct 2015 14:40:35 -0500 Subject: Request to reopen the issue of 7.8 on El Capitan In-Reply-To: References: Message-ID: Thank you Mark! I was going to ask you since I know you have like 6 OS X virtual machines, so you have much better coverage. :) I'm getting my hands on a mac now to test it, and I'll let everyone know when it's ready (I have to do the other annoying stuff of like making the proper bug and a milestone, etc.) On Fri, Oct 16, 2015 at 12:33 AM, Mark Lentczner wrote: > I can build a 7.8.5 binary for release if someone can put the patch in the > GHC tree. (Having a soft spot in my heart for the 7.8 line!) > I'm leaving on a short trip, and will be back on Tuesday and build middle of > next week. > - Mark -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From spam at scientician.net Fri Oct 16 19:45:37 2015 From: spam at scientician.net (Bardur Arantsson) Date: Fri, 16 Oct 2015 21:45:37 +0200 Subject: "Excuse me, I think this i my stop..." - Resigning from the Platform In-Reply-To: References: Message-ID: On 10/13/2015 05:08 AM, Mark Lentczner wrote: > I think this is the right time for me to exit: > I'm pretty sure that there are many things that we could agree or disagree on, but *THANK YOU* for your efforts on improving the Haskell ecosystem and your efforts to spread the word! Regards, From lsp at informatik.uni-kiel.de Sat Oct 17 00:05:27 2015 From: lsp at informatik.uni-kiel.de (lennart spitzner) Date: Sat, 17 Oct 2015 02:05:27 +0200 Subject: dns issues with ghc.haskell.org Message-ID: <562190C7.7060403@informatik.uni-kiel.de> hi, This mail is intended for the maintainers of ghc.haskell.org who i can hopefully reach on this list. Once more i run into the issue that firefox resolves ghc.haskell.org to the wrong (an outdated?) ip address (resulting in some 500 Internal Server Error page; i guess on some other server..). When switching to a different browser the address is resolved "correctly" and i reach the expected server. For me personally this is only slightly annoying, but another fellow on irc recently reported the same symptoms, so i am not the only one affected. Might be worth resolving. I have not observed a failure of this kind for any other server. I don't really know what could be the issue or how to diagnose this further. If it helps, in this case (have not checked when this occurred previously): "wrong" address 162.242.239.16 "correct" 104.25.122.13 Lennart From austin at well-typed.com Sat Oct 17 02:34:46 2015 From: austin at well-typed.com (Austin Seipp) Date: Fri, 16 Oct 2015 21:34:46 -0500 Subject: GHC Weekly News - 2015/10/16 Message-ID: (This post is available online at https://ghc.haskell.org/trac/ghc/blog/weekly20151016) Hi *, Welcome for the latest entry in the GHC Weekly News, which has been somewhat irregularly scheduled - but we're as busy as ever! == 8.0.1 release roadmap == We're still steaming ahead on GHC 8.0.1 - any interested participants are suggested to look at the wiki:Status/GHC-8.0.1 page, to see where we're currently at. These past few weeks have been good: we've gotten the first part of the overloaded record fields work in, and we have plans to land the kind equalities work in November. Furthermore, Simon Marlow, Peter Wortmann and Ben are working on reviewing all of the DWARF improvements, and hopefully the start of this work will land next week. But 8.0 isn't the only thing that'll be getting released... == And some other minor releases == In a total, unprecedented upset - we're aiming to do ''three'' GHC releases in a fairly short amount of time. === 7.10.3 === Ben Gamari has been working on steadily hacking away at GHC 7.10.3, and the hopes are that we'll be able to ship it soon. This will fix several dozen bugs, some of which are critical for our users. You can keep up to date by following the wiki:Status/GHC-7.10.3 page. === 7.8.5 === Simultaneously, your author will ''also'' be working on a GHC 7.8.5 release. While we were alerted a few months ago to this breakage, it seems rather unfortunate for the 7.8 series to remain broken on such a popular OS. Furthermore, the "Three GHC Release Policy" for many authors - to support the last three major versions of GHC - would mean that 7.8 would be broken for OS X developers for an ''entire year until GHC 8.2.1''. Which is a pretty unfortunate circumstance. It's not expected the 7.8.5 release will contain any other fixes, however. == List chatter == (Over the past two weeks) - Ben Gamari wrote in about '''switching the users guide to reStructuredText''', and the TL;DR is - it's done! We'll have a beautiful new users guide for GHC 8.0.1 https://mail.haskell.org/pipermail/ghc-devs/2015-October/010029.html - Matthew Pickering comments about the state of pattern synonym signatures, remarking that they're currently confusing, noting down some things we could possibly fix. https://mail.haskell.org/pipermail/ghc-devs/2015-October/010024.html - Ben Gamari talked about the status of the recent DWARF work, and so far it's looking good. The needed patches are still in the review pipeline, but the hope is that they'll all be done in time for 8.0.1. https://mail.haskell.org/pipermail/ghc-devs/2015-October/010039.html - David A Roberts wrote in to ask a question: now that we have `ApplicativeDo`, what about `Applicative` comprehensions? The responses indicate this seems like it would be a great addition. https://mail.haskell.org/pipermail/ghc-devs/2015-October/010062.html - Richard Eisenberg sent in a status update about his work on kind equalities, and the hope is it will land shortly in November! (Your editor then hassled him for a syntax change before landing.) https://mail.haskell.org/pipermail/ghc-devs/2015-October/010077.html - Adam Foltzer has requested another release of the GHC 7.8 series, due to it being completely broken on OS X El Capitan. Expect more news on this soon. https://mail.haskell.org/pipermail/ghc-devs/2015-October/010078.html - Erik de Castro Lopo has recently been working with LLVM, and decided to publish his automation so interested GHC hackers could keep up to date and try new LLVMs easily. https://mail.haskell.org/pipermail/ghc-devs/2015-October/010086.html == Noteworthy commits == (Over the past two weeks) - Commit 4fd6207ec6960c429e6a1bcbe0282f625010f52a - Move the users guide to reStructured Text. - Commit 6cde981a8788b225819be28659caddc35b77972d - Make `GHC.Generics` capable of handling unboxed tuples. - Commit 0eb8fcd94b29ee9997b386e64203037bdf2aaa04 - Enable `Enumeration is empty` warnings for `Integer` - Commit 620fc6f909cd6e51b5613454097ec1c9f323839a - Make Windows linker more robust to unknown sections - Commit 5d841108acef950fed6a5e608ac9b18e7431aa87 - Add short library names support to the Windows linker - Commit f8fbf385b879fe177409a25cc9499275ea3dc45d - Reinstate monomorphism-restriction warnings - Commit dcc342870b4d8a739ccbed3ae26e84dcc3579914 - Don't inline/apply other rules when simplifying a rule RHS. - Commit dec5cd4085488686b5ed50bb26ccbc0ba7b645ec - base: Add `forkOSWithUnmask` - Commit e8c8173923302268ef950c3b21e276779e45ac83 - Allow arr ? (first ? (***)) as minimal definition of Arrow instance - Commit 29310b622801733e1b29a9a61988406872db13ca - Switch to LLVM version 3.7 - Commit 04e8366608fee4f5e3358acc855bc6f556c3f508 - ELF/x86_64: map object file sections separately into the low 2GB - Commit b1884b0e62f62e3c0859515c4137124ab0c9560e - Implement `DuplicateRecordFields` - Commit 75492e7467ff962f2f2e29e5c8b2c588c94ae8a7 - Add typed holes support in Template Haskell. - Commit 6a8ca65032c6b3ed61b5378765e70120083cf5da - Allow left ? (+++) as minimal definition of ArrowChoice instance == Closed tickets == (Over the past two weeks) #10392, #7883, #10475, #10745, #10926, #9238, #10700, #10810, #10342, #365(!), #10361, #10929, #10563, #9907, #10513, #10868, #10932, #8920, #10516, #10416, #5966, #8335, #10520, #10687, #10571, #9058, #10939, #10938, #9590, #10949, #10153, #10947, #10948, #10936, #1883, #5289, #10733, #10950, #10611, #10959, #10960, #10831, #10796, #10890, #8010, #10216, #10965, #10953, #10964, #10931, #10714, #10888, #10633, #8652, #3971, #10882, #10977, #10267, and #10911. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From thomasmiedema at gmail.com Mon Oct 19 17:10:07 2015 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Mon, 19 Oct 2015 19:10:07 +0200 Subject: [Differential] [Closed] D975: ELF/x86_64: map object file sections separately into the low 2GB Message-ID: This commit is causing segmentation faults on Travis (DYNAMIC_GHC_PROGRAMS = NO): https://s3.amazonaws.com/archive.travis-ci.org/jobs/85552765/log.txt Unexpected failures: ghci.debugger/scripts break001 [bad exit code] (ghci) ghci.debugger/scripts break005 [bad exit code] (ghci) ghci.debugger/scripts break006 [bad exit code] (ghci) ghci.debugger/scripts break011 [bad exit code] (ghci) ghci.debugger/scripts break017 [bad exit code] (ghci) ghci.debugger/scripts dynbrk007 [bad exit code] (ghci) ghci.debugger/scripts hist001 [bad exit code] (ghci) ghci.debugger/scripts print001 [bad exit code] (ghci) ghci.debugger/scripts print002 [bad exit code] (ghci) ghci.debugger/scripts print003 [bad exit code] (ghci) ghci.debugger/scripts print004 [bad exit code] (ghci) ghci.debugger/scripts print005 [bad exit code] (ghci) ghci.debugger/scripts print006 [bad exit code] (ghci) ghci.debugger/scripts print008 [bad exit code] (ghci) ghci.debugger/scripts print010 [bad exit code] (ghci) ghci.debugger/scripts print011 [bad exit code] (ghci) ghci.debugger/scripts print012 [bad exit code] (ghci) ghci.debugger/scripts print013 [bad exit code] (ghci) ghci.debugger/scripts print016 [bad exit code] (ghci) ghci.debugger/scripts print017 [bad exit code] (ghci) ghci.debugger/scripts print019 [bad exit code] (ghci) ghci.debugger/scripts print020 [bad exit code] (ghci) ghci.debugger/scripts print023 [bad exit code] (ghci) ghci.debugger/scripts print024 [bad exit code] (ghci) ghci.debugger/scripts print026 [bad exit code] (ghci) ghci.debugger/scripts print028 [bad exit code] (ghci) ghci.debugger/scripts print031 [bad exit code] (ghci) ghci.debugger/scripts print032 [bad exit code] (ghci) ghci.debugger/scripts print034 [bad exit code] (ghci) ghci/scripts T2976 [bad exit code] (ghci) On Thu, Oct 15, 2015 at 5:20 PM, simonmar (Simon Marlow) < noreply at phabricator.haskell.org> wrote: > This revision was automatically updated to reflect the committed changes. > Closed by commit rGHC04e8366608fe: ELF/x86_64: map object file sections > separately into the low 2GB (authored by simonmar). > > *CHANGED PRIOR TO COMMIT* > https://phabricator.haskell.org/D975?vs=4501&id=4502#toc > > *REPOSITORY* > rGHC Glasgow Haskell Compiler > > *CHANGES SINCE LAST UPDATE* > https://phabricator.haskell.org/D975?vs=4501&id=4502 > > *REVISION DETAIL* > https://phabricator.haskell.org/D975 > > *AFFECTED FILES* > rts/CheckUnload.c > rts/Linker.c > rts/LinkerInternals.h > testsuite/tests/ghci/linking/all.T > testsuite/tests/rts/linker_error.c > > *EMAIL PREFERENCES* > https://phabricator.haskell.org/settings/panel/emailpreferences/ > > *To: *simonmar, Phyx, trommler, bgamari, austin > *Cc: *hsyl20, thomie, bgamari > -------------- next part -------------- An HTML attachment was scrubbed... URL: From omeragacan at gmail.com Mon Oct 19 20:38:18 2015 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Mon, 19 Oct 2015 16:38:18 -0400 Subject: is this change in TH error message intentional? Message-ID: Hi all, I realized this change in TH error messages: GHC 7.10.2: ? th-test ghc --make Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Main.hs:13:15: Not in scope: ?locaton? Perhaps you meant ?location? (imported from Language.Haskell.TH.Syntax) In the splice: $locaton Main.hs:13:15: GHC stage restriction: ?locaton? is used in a top-level splice or annotation, and must be imported, not defined locally In the expression: locaton In the splice: $locaton I think both error messages are quite useful in this context. I don't see second one as redundant. However, with HEAD: ? th-test ghc-stage2 --make Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Main.hs:13:15: error: Variable not in scope: locaton :: ExpQ Perhaps you meant ?location? (imported from Language.Haskell.TH.Syntax) I think this new message is quite worse than previous one. First, "In the splice ..." part is missing. Second, "It must be imported, not defined locally" message is not given at all. Was this change intentional? May I ask why it's changed? From omeragacan at gmail.com Mon Oct 19 20:47:18 2015 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Mon, 19 Oct 2015 16:47:18 -0400 Subject: Building stage1 only Message-ID: (I know I asked this many times in IRC channel but I don't remember getting any answers. I apologize if anyone had answered this on IRC channel and I missed) With current build system, even if I choose "devel1" it always builds stage2 compiler too. A comment in build.mk says that it's for working on stage1 compiler, so I'd expect it to build only stage1. The reason I want stage1-only builds is the time it takes to build both stages. It takes approximately 30 minutes and if I could reduce this down to half that would greatly improve my work flow. Most of the time I don't need a full build, but in my experience, it's very easy to end up in a state where `make` simply can't build, and only easy fix is a `make clean`, which costs 30 minutes because then I have to build from scratch. This happens way too often, and so I need a stage1-only build. Thanks.. From david.feuer at gmail.com Mon Oct 19 21:02:36 2015 From: david.feuer at gmail.com (David Feuer) Date: Mon, 19 Oct 2015 17:02:36 -0400 Subject: Moving forall with coerce Message-ID: It appears, as far as I can tell, that GHC can't move a forall past an -> with coerce. I was playing around with the MonadTrans instance for Codensity, wanting (essentially) to write lift = coerce (>>=) This is legal: instance MonadTrans Codensity where lift = frob frob :: forall m a . Monad m => m a -> Codensity m a frob = coerce (blah (Mag (>>=)) :: m a -> Mag2 m a) newtype Mag m a = Mag (forall b . m a -> (a -> m b) -> m b) newtype Mag2 m a = Mag2 (forall b . (a -> m b) -> m b) blah :: Mag m a -> m a -> Mag2 m a blah (Mag p) q = Mag2 (p q) The problem is that there doesn't *seem* to be a way to implement blah as a coercion. GHC doesn't recognize that Mag m a has the same representation as m a -> Mag2 m a The essential difference, as far as I can see, is that the `forall b` is shifted across `m a ->`. It seems that this really shouldn't be an issue, because 1. b is not free in `m a` 2. Type lambdas all compile away Would it be worth trying to extend the Coercible mechanism to deal with these kinds of situations? Or is there already some way to do it that I've missed? David From omeragacan at gmail.com Mon Oct 19 21:18:41 2015 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Mon, 19 Oct 2015 17:18:41 -0400 Subject: Show instances for GHC internals Message-ID: Currently the only way to debug and inspect GHC internals is by adding some carefully placed print statements. (I'd love to be proven wrong on this, cost of debugging this way is huge, given how long it's taking to rebuild GHC) We have Outputable instances for most data types, and `Outputable.pprTrace` etc. helps with debugging/inspecting pure functions this way. However, Outputable instances are hiding some details and they're sometimes not useful for debugging and inspecting internals. This is why I implemented CoreDump package(http://hackage.haskell.org/package/CoreDump), Outputable instance of CoreSyn is simply not useful for some things. Similarly, just today I had to add a show function for `HscTypes.TargetId` because `Outputable` instance was hiding `Maybe Phase` field. Since the only way to debug or inspect GHC internals(except maybe the RTS) is by printing things, I think we should provide Show instances for.. basically everything. Otherwise I just can't see a way of debugging things and inspecting internals, tracing code etc. for learning purposes. I was wondering what would be the cost of adding Show instances. Would that mean significantly increased compile times? Or significantly bigger GHC binaries? If that's the case, could we enable Show instances with some arguments so that we can enable/disable it by modifying mk/build.mk? From edzhavoronkov at gmail.com Mon Oct 19 21:22:15 2015 From: edzhavoronkov at gmail.com (=?UTF-8?B?0K3QtNCz0LDRgCDQltCw0LLQvtGA0L7QvdC60L7Qsg==?=) Date: Tue, 20 Oct 2015 00:22:15 +0300 Subject: Warning suppression pragmas Message-ID: Hi everyone! Do you know, if there is pragma for warning suppression? I want to implement something like warning suppression related to this ticket in GHC's Trac (https://ghc.haskell.org/trac/ghc/ticket/602). Or i need to implement that kind of pragma by myself? Thanks in advance! Edgar -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Mon Oct 19 21:26:12 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Mon, 19 Oct 2015 23:26:12 +0200 Subject: Show instances for GHC internals In-Reply-To: References: Message-ID: This is a utility I would love to see inside the ghc source tree for examining the AST https://github.com/edsko/ghc-dump-tree Alan On Mon, Oct 19, 2015 at 11:18 PM, ?mer Sinan A?acan wrote: > Currently the only way to debug and inspect GHC internals is by adding some > carefully placed print statements. (I'd love to be proven wrong on this, > cost > of debugging this way is huge, given how long it's taking to rebuild GHC) > > We have Outputable instances for most data types, and `Outputable.pprTrace` > etc. helps with debugging/inspecting pure functions this way. > > However, Outputable instances are hiding some details and they're > sometimes not > useful for debugging and inspecting internals. This is why I implemented > CoreDump package(http://hackage.haskell.org/package/CoreDump), Outputable > instance of CoreSyn is simply not useful for some things. Similarly, just > today > I had to add a show function for `HscTypes.TargetId` because `Outputable` > instance was hiding `Maybe Phase` field. > > Since the only way to debug or inspect GHC internals(except maybe the RTS) > is > by printing things, I think we should provide Show instances for.. > basically > everything. Otherwise I just can't see a way of debugging things and > inspecting > internals, tracing code etc. for learning purposes. > > I was wondering what would be the cost of adding Show instances. Would that > mean significantly increased compile times? Or significantly bigger GHC > binaries? If that's the case, could we enable Show instances with some > arguments so that we can enable/disable it by modifying mk/build.mk? > _______________________________________________ > 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 Oct 19 22:06:56 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 19 Oct 2015 18:06:56 -0400 Subject: Moving forall with coerce In-Reply-To: References: Message-ID: Just to be clear, the Codensity bit (which I don't know) is a red herring here. What you want is this: > newtype A m a = MkA (forall b. m a -> (a -> m b) -> m b) > newtype B (m :: * -> *) a = MkB (forall b. (a -> m b) -> m b) > > foo :: A m a -> (m a -> B m a) > foo = coerce On one level, this is perfectly reasonable. These two types do seem to have the same runtime representation. But in thinking about how the types work out, it's all less clear. In particular, this seems to require impredicativity, as we'll be solving a Coercible constraint over forall-types. I think we'll have to sort out impredicativity, in general, before we can start to tackle something like this. But I haven't thought very deeply about it, and perhaps there's a way forward I haven't seen. Interesting example! Richard On Oct 19, 2015, at 5:02 PM, David Feuer wrote: > It appears, as far as I can tell, that GHC can't move a forall past an > -> with coerce. I was playing around with the MonadTrans instance for > Codensity, wanting (essentially) to write > > lift = coerce (>>=) > > This is legal: > > instance MonadTrans Codensity where > lift = frob > frob :: forall m a . Monad m => m a -> Codensity m a > frob = coerce (blah (Mag (>>=)) :: m a -> Mag2 m a) > newtype Mag m a = Mag (forall b . m a -> (a -> m b) -> m b) > newtype Mag2 m a = Mag2 (forall b . (a -> m b) -> m b) > blah :: Mag m a -> m a -> Mag2 m a > blah (Mag p) q = Mag2 (p q) > > The problem is that there doesn't *seem* to be a way to implement blah > as a coercion. GHC doesn't recognize that > > Mag m a > > has the same representation as > > m a -> Mag2 m a > > The essential difference, as far as I can see, is that the `forall b` > is shifted across `m a ->`. It seems that this really shouldn't be an > issue, because > > 1. b is not free in `m a` > 2. Type lambdas all compile away > > Would it be worth trying to extend the Coercible mechanism to deal > with these kinds of situations? Or is there already some way to do it > that I've missed? > > David > _______________________________________________ > 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 Oct 19 22:10:12 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 19 Oct 2015 18:10:12 -0400 Subject: Warning suppression pragmas In-Reply-To: References: Message-ID: I just responded to #602, but perhaps you're just looking for the -fno-warn-XXX options listed here: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/flag-reference.html#idp14879296 Richard On Oct 19, 2015, at 5:22 PM, ????? ?????????? wrote: > Hi everyone! > > Do you know, if there is pragma for warning suppression? I want to implement something like warning suppression related to this ticket in GHC's Trac (https://ghc.haskell.org/trac/ghc/ticket/602). Or i need to implement that kind of pragma by myself? > > Thanks in advance! > Edgar > _______________________________________________ > 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 Oct 19 22:14:43 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 19 Oct 2015 18:14:43 -0400 Subject: Show instances for GHC internals In-Reply-To: References: Message-ID: <3A3E02FD-5B23-4D55-B6DC-C34209981963@cis.upenn.edu> On Oct 19, 2015, at 5:18 PM, ?mer Sinan A?acan wrote: > cost > of debugging this way is huge, given how long it's taking to rebuild GHC) There are more interesting parts of your post, but I can respond to this: It shouldn't take that much time. Once you have ghc-stage2 built, you should be able to say `make 2` in the ./ghc subdirectory and get a new binary in a few seconds. Using `make 1` in the ./compiler subdirectory works similarly for the stage1 compiler. But only once it's built the first time. Richard From edzhavoronkov at gmail.com Mon Oct 19 22:16:46 2015 From: edzhavoronkov at gmail.com (=?UTF-8?B?0K3QtNCz0LDRgCDQltCw0LLQvtGA0L7QvdC60L7Qsg==?=) Date: Tue, 20 Oct 2015 01:16:46 +0300 Subject: Warning suppression pragmas In-Reply-To: References: Message-ID: No, i mean exactly pragmas in source code, that i can particulary add to function or a part of the code for example. E.g: {-# BEGIN_SUPPRESS_WARNINGS #-} foo :: a -> b #do something that throws warnings {-# END_SUPPRESS_WARNINGS #-} 2015-10-20 1:10 GMT+03:00 Richard Eisenberg : > I just responded to #602, but perhaps you're just looking for the > -fno-warn-XXX options listed here: > https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/flag-reference.html#idp14879296 > > Richard > > On Oct 19, 2015, at 5:22 PM, ????? ?????????? > wrote: > > Hi everyone! > > Do you know, if there is pragma for warning suppression? I want to > implement something like warning suppression related to this ticket in > GHC's Trac (https://ghc.haskell.org/trac/ghc/ticket/602). Or i need to > implement that kind of pragma by myself? > > Thanks in advance! > Edgar > _______________________________________________ > 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 Oct 19 22:17:56 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 19 Oct 2015 18:17:56 -0400 Subject: Warning suppression pragmas In-Reply-To: References: Message-ID: Hi Edgar, No, that doesn't exist yet. Would surely be useful, though. Richard On Oct 19, 2015, at 6:16 PM, ????? ?????????? wrote: > No, i mean exactly pragmas in source code, that i can particulary add to function or a part of the code for example. > E.g: > > {-# BEGIN_SUPPRESS_WARNINGS #-} > > foo :: a -> b > #do something that throws warnings > > {-# END_SUPPRESS_WARNINGS #-} > > > > 2015-10-20 1:10 GMT+03:00 Richard Eisenberg : > I just responded to #602, but perhaps you're just looking for the -fno-warn-XXX options listed here: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/flag-reference.html#idp14879296 > > Richard > > On Oct 19, 2015, at 5:22 PM, ????? ?????????? wrote: > >> Hi everyone! >> >> Do you know, if there is pragma for warning suppression? I want to implement something like warning suppression related to this ticket in GHC's Trac (https://ghc.haskell.org/trac/ghc/ticket/602). Or i need to implement that kind of pragma by myself? >> >> Thanks in advance! >> Edgar >> _______________________________________________ >> 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 edzhavoronkov at gmail.com Mon Oct 19 22:21:02 2015 From: edzhavoronkov at gmail.com (=?UTF-8?B?0K3QtNCz0LDRgCDQltCw0LLQvtGA0L7QvdC60L7Qsg==?=) Date: Tue, 20 Oct 2015 01:21:02 +0300 Subject: Warning suppression pragmas In-Reply-To: References: Message-ID: Hello, Richard, Do you know something about defining own pragmas in GHC? --- ? ?????????, ?????????? ????? 2015-10-20 1:17 GMT+03:00 Richard Eisenberg : > Hi Edgar, > > No, that doesn't exist yet. Would surely be useful, though. > > Richard > > On Oct 19, 2015, at 6:16 PM, ????? ?????????? > wrote: > > No, i mean exactly pragmas in source code, that i can particulary add to > function or a part of the code for example. > E.g: > > {-# BEGIN_SUPPRESS_WARNINGS #-} > > foo :: a -> b > #do something that throws warnings > > {-# END_SUPPRESS_WARNINGS #-} > > > > 2015-10-20 1:10 GMT+03:00 Richard Eisenberg : > >> I just responded to #602, but perhaps you're just looking for the >> -fno-warn-XXX options listed here: >> https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/flag-reference.html#idp14879296 >> >> Richard >> >> On Oct 19, 2015, at 5:22 PM, ????? ?????????? >> wrote: >> >> Hi everyone! >> >> Do you know, if there is pragma for warning suppression? I want to >> implement something like warning suppression related to this ticket in >> GHC's Trac (https://ghc.haskell.org/trac/ghc/ticket/602). Or i need to >> implement that kind of pragma by myself? >> >> Thanks in advance! >> Edgar >> _______________________________________________ >> 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 Oct 19 22:35:03 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 19 Oct 2015 18:35:03 -0400 Subject: Building stage1 only In-Reply-To: References: Message-ID: <3FEBD254-53B2-447A-80E4-C4E6D2A41600@cis.upenn.edu> I haven't tested this, but I imagine putting `stage=1` in your build.mk or even on the command line should work. Richard On Oct 19, 2015, at 4:47 PM, ?mer Sinan A?acan wrote: > (I know I asked this many times in IRC channel but I don't remember getting any > answers. I apologize if anyone had answered this on IRC channel and I missed) > > With current build system, even if I choose "devel1" it always builds stage2 > compiler too. A comment in build.mk says that it's for working on stage1 > compiler, so I'd expect it to build only stage1. > > The reason I want stage1-only builds is the time it takes to build both stages. > It takes approximately 30 minutes and if I could reduce this down to half that > would greatly improve my work flow. > > Most of the time I don't need a full build, but in my experience, it's very > easy to end up in a state where `make` simply can't build, and only > easy fix is a > `make clean`, which costs 30 minutes because then I have to build from scratch. > This happens way too often, and so I need a stage1-only build. > > Thanks.. > _______________________________________________ > 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 Oct 19 22:37:19 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 19 Oct 2015 18:37:19 -0400 Subject: Warning suppression pragmas In-Reply-To: References: Message-ID: Sure. But before thinking about implementation, let's think about specification. Write a wiki page (perhaps https://ghc.haskell.org/trac/ghc/wiki/Design/LocalWarningPragmas ) with the design of how the feature should work, with several examples. Once we know what we're building, then we can talk about how to build it. Thanks! Richard On Oct 19, 2015, at 6:21 PM, ????? ?????????? wrote: > Hello, Richard, > > Do you know something about defining own pragmas in GHC? > > --- > > ? ?????????, > ?????????? ????? > > 2015-10-20 1:17 GMT+03:00 Richard Eisenberg : > Hi Edgar, > > No, that doesn't exist yet. Would surely be useful, though. > > Richard > > On Oct 19, 2015, at 6:16 PM, ????? ?????????? wrote: > >> No, i mean exactly pragmas in source code, that i can particulary add to function or a part of the code for example. >> E.g: >> >> {-# BEGIN_SUPPRESS_WARNINGS #-} >> >> foo :: a -> b >> #do something that throws warnings >> >> {-# END_SUPPRESS_WARNINGS #-} >> >> >> >> 2015-10-20 1:10 GMT+03:00 Richard Eisenberg : >> I just responded to #602, but perhaps you're just looking for the -fno-warn-XXX options listed here: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/flag-reference.html#idp14879296 >> >> Richard >> >> On Oct 19, 2015, at 5:22 PM, ????? ?????????? wrote: >> >>> Hi everyone! >>> >>> Do you know, if there is pragma for warning suppression? I want to implement something like warning suppression related to this ticket in GHC's Trac (https://ghc.haskell.org/trac/ghc/ticket/602). Or i need to implement that kind of pragma by myself? >>> >>> Thanks in advance! >>> Edgar >>> _______________________________________________ >>> 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 edzhavoronkov at gmail.com Mon Oct 19 22:44:35 2015 From: edzhavoronkov at gmail.com (=?UTF-8?B?0K3QtNCz0LDRgCDQltCw0LLQvtGA0L7QvdC60L7Qsg==?=) Date: Tue, 20 Oct 2015 01:44:35 +0300 Subject: Warning suppression pragmas In-Reply-To: References: Message-ID: Oh, okay, sure --- ? ?????????, ?????????? ????? Yours sincerely, Zhavornkov Edgar 2015-10-20 1:37 GMT+03:00 Richard Eisenberg : > Sure. But before thinking about implementation, let's think about > specification. Write a wiki page (perhaps > https://ghc.haskell.org/trac/ghc/wiki/Design/LocalWarningPragmas ) with > the design of how the feature should work, with several examples. Once we > know what we're building, then we can talk about how to build it. > > Thanks! > Richard > > On Oct 19, 2015, at 6:21 PM, ????? ?????????? > wrote: > > Hello, Richard, > > Do you know something about defining own pragmas in GHC? > > --- > > ? ?????????, > ?????????? ????? > > 2015-10-20 1:17 GMT+03:00 Richard Eisenberg : > >> Hi Edgar, >> >> No, that doesn't exist yet. Would surely be useful, though. >> >> Richard >> >> On Oct 19, 2015, at 6:16 PM, ????? ?????????? >> wrote: >> >> No, i mean exactly pragmas in source code, that i can particulary add to >> function or a part of the code for example. >> E.g: >> >> {-# BEGIN_SUPPRESS_WARNINGS #-} >> >> foo :: a -> b >> #do something that throws warnings >> >> {-# END_SUPPRESS_WARNINGS #-} >> >> >> >> 2015-10-20 1:10 GMT+03:00 Richard Eisenberg : >> >>> I just responded to #602, but perhaps you're just looking for the >>> -fno-warn-XXX options listed here: >>> https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/flag-reference.html#idp14879296 >>> >>> Richard >>> >>> On Oct 19, 2015, at 5:22 PM, ????? ?????????? >>> wrote: >>> >>> Hi everyone! >>> >>> Do you know, if there is pragma for warning suppression? I want to >>> implement something like warning suppression related to this ticket in >>> GHC's Trac (https://ghc.haskell.org/trac/ghc/ticket/602). Or i need to >>> implement that kind of pragma by myself? >>> >>> Thanks in advance! >>> Edgar >>> _______________________________________________ >>> 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 ezyang at mit.edu Tue Oct 20 01:59:19 2015 From: ezyang at mit.edu (Edward Z. Yang) Date: Mon, 19 Oct 2015 18:59:19 -0700 Subject: Show instances for GHC internals In-Reply-To: References: Message-ID: <1445306224-sup-7133@sabre> Excerpts from ?mer Sinan A?acan's message of 2015-10-19 14:18:41 -0700: > I was wondering what would be the cost of adding Show instances. Would that > mean significantly increased compile times? Or significantly bigger GHC > binaries? If that's the case, could we enable Show instances with some > arguments so that we can enable/disable it by modifying mk/build.mk? One difficulty is that many of the core type data types, e.g. TyThing, are (1) a large mutually recursive graph, and (2) have unsafeInterleaveIO thunks which would induce IO action. So a naive Show instance would give infinite output and have lots of side effects. There are many data types which could usefully have Show added but also many which would be very difficult to. Edward From jan.stolarek at p.lodz.pl Tue Oct 20 06:04:29 2015 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Tue, 20 Oct 2015 08:04:29 +0200 Subject: is this change in TH error message intentional? In-Reply-To: References: Message-ID: <201510200804.29213.jan.stolarek@p.lodz.pl> ?mer, can you show us the source of Main.hs? Janek Dnia poniedzia?ek, 19 pa?dziernika 2015, ?mer Sinan A?acan napisa?: > Hi all, > > I realized this change in TH error messages: > > GHC 7.10.2: > > ? th-test ghc --make Main.hs > [1 of 1] Compiling Main ( Main.hs, Main.o ) > > Main.hs:13:15: > Not in scope: ?locaton? > Perhaps you meant ?location? (imported from > Language.Haskell.TH.Syntax) In the splice: $locaton > > Main.hs:13:15: > GHC stage restriction: > ?locaton? is used in a top-level splice or annotation, > and must be imported, not defined locally > In the expression: locaton > In the splice: $locaton > > I think both error messages are quite useful in this context. I don't see > second one as redundant. > > However, with HEAD: > > ? th-test ghc-stage2 --make Main.hs > [1 of 1] Compiling Main ( Main.hs, Main.o ) > > Main.hs:13:15: error: > Variable not in scope: locaton :: ExpQ > Perhaps you meant ?location? (imported from > Language.Haskell.TH.Syntax) > > I think this new message is quite worse than previous one. First, "In the > splice ..." part is missing. Second, "It must be imported, not defined > locally" message is not given at all. > > Was this change intentional? May I ask why it's changed? > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs --- Politechnika ??dzka Lodz University of Technology Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system. From jan.stolarek at p.lodz.pl Tue Oct 20 07:12:02 2015 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Tue, 20 Oct 2015 09:12:02 +0200 Subject: Building stage1 only In-Reply-To: References: Message-ID: <201510200912.02681.jan.stolarek@p.lodz.pl> > it's very easy to end up in a state where `make` simply can't build, and only > easy fix is a `make clean` Out of sheer curiosity: in what situations does that happen for you? *If* you are working on a single branch, ie. you're not switching back and forth between master and your feature branches, this should not happen (and even if you switch between branches it should still be safe for most of the time). Richard already gave you a trick (cd ghc/ && make 2) that allows to build only stage 2 compiler without rebuilding stage 1 or any of the libraries. One situation that comes to my mind that can really require a full rebuild is changing format of interface files. But other than that you shouldn't have to do a full rebuild too often. I know how you feel. When I started working on GHC I had to do a full rebuild very often. But now I improved my workflow and only do a full build after a major rebase of my branch against master. 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 Oct 20 08:30:36 2015 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Tue, 20 Oct 2015 10:30:36 +0200 Subject: Building stage1 only In-Reply-To: <3FEBD254-53B2-447A-80E4-C4E6D2A41600@cis.upenn.edu> References: <3FEBD254-53B2-447A-80E4-C4E6D2A41600@cis.upenn.edu> Message-ID: Hi ?mer, in mk/build.mk, set: * Stage1Only=YES * stage=1 * BuildFlavour=devel1 Then 'cd ghc && make'. Don't run make in the toplevel directory. After building the stage1 compiler, it does still start the process of configuring the libraries for the stage2 compiler, but it shouldn't build them. Last time I checked, I didn't find an easy way to fix this. Maybe the shake rewrite of the build system will have a better solution. See Note [Stage1Only vs stage=1] in mk/config.mk.in for an explanation. Thomas On Tue, Oct 20, 2015 at 12:35 AM, Richard Eisenberg wrote: > I haven't tested this, but I imagine putting `stage=1` in your build.mk > or even on the command line should work. > > Richard > > On Oct 19, 2015, at 4:47 PM, ?mer Sinan A?acan > wrote: > > > (I know I asked this many times in IRC channel but I don't remember > getting any > > answers. I apologize if anyone had answered this on IRC channel and I > missed) > > > > With current build system, even if I choose "devel1" it always builds > stage2 > > compiler too. A comment in build.mk says that it's for working on stage1 > > compiler, so I'd expect it to build only stage1. > > > > The reason I want stage1-only builds is the time it takes to build both > stages. > > It takes approximately 30 minutes and if I could reduce this down to > half that > > would greatly improve my work flow. > > > > Most of the time I don't need a full build, but in my experience, it's > very > > easy to end up in a state where `make` simply can't build, and only > > easy fix is a > > `make clean`, which costs 30 minutes because then I have to build from > scratch. > > This happens way too often, and so I need a stage1-only build. > > > > Thanks.. > > _______________________________________________ > > 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 mail at joachim-breitner.de Tue Oct 20 11:09:24 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 20 Oct 2015 13:09:24 +0200 Subject: Moving forall with coerce In-Reply-To: References: Message-ID: <1445339364.3798.14.camel@joachim-breitner.de> Hi David, Am Montag, den 19.10.2015, 18:06 -0400 schrieb Richard Eisenberg: > Just to be clear, the Codensity bit (which I don't know) is a red > herring here. What you want is this: > > > newtype A m a = MkA (forall b. m a -> (a -> m b) -> m b) > > newtype B (m :: * -> *) a = MkB (forall b. (a -> m b) -> m b) > > > > foo :: A m a -> (m a -> B m a) > > foo = coerce > > On one level, this is perfectly reasonable. These two types do seem > to have the same runtime representation. But in thinking about how > the types work out, it's all less clear. In particular, this seems to > require impredicativity, as we'll be solving a Coercible constraint > over forall-types. I think we'll have to sort out impredicativity, in > general, before we can start to tackle something like this. > > But I haven't thought very deeply about it, and perhaps there's a way > forward I haven't seen. > > Interesting example! JFTR, note that the solver can handle forall?s in a very limited way, namely coercing between two forall?ed types works: instance (forall a. Coercible t1 t2) => Coercible (forall a. t1) (forall a. t2) but you need something more powerful. Also note that once class join the party, things become less coercible. This might work: > newtype A = A (forall x. Int -> [x] -> x) > newtype B = B (Int -> forall x. [x] -> x) > :t coerce :: A -> B (although it currently does not), but this will not > newtype A = A (forall x. Show x => Int -> [x] -> x) > newtype B = B (Int -> forall x. Show x => [x] -> x) > coerce :: A -> B as the order of the Int and the show instance would be different in the representation. Not sure how much that implementation detail should pervade the user space. OTOH, coercible is already quite implementation-specific, and of course we want to be able to coerce as much as possible. 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 alexander at plaimi.net Tue Oct 20 11:10:44 2015 From: alexander at plaimi.net (Alexander Berntsen) Date: Tue, 20 Oct 2015 13:10:44 +0200 Subject: Confusing error message when universally quantifying unused type variables Message-ID: <56262134.4050605@plaimi.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 In Set theory sentence construction, if the letter is not used then no foul. In Haskell, it is not always so. The following is well-typed and works happily: f :: Eq a => b -> b f b = b However, this does not work: f :: ? a. Eq a => b -> b f b = b It will result in the error "Not in scope: type variable ?b?" being spat out twice. Is this error message really desirable? If there is no principled reason for this result, may I suggest improving it? I can conceivably see some codebase using RankNTypes exclusively having a typo like f :: ? a. b -> b f b = b Consequently the error message should be more precise. Furthermore the first code snippet I gave also strikes me as nonsensical; if someone has code like that, it is probably the result of a typo. Should we really permit it? Is there a motivating reason for permitting it? If no, I suggest it be an error. (My understanding of the 2010 report was that it *isn't* permitted, but perhaps I read it wrong.) - -- Alexander alexander at plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJWJiE0AAoJENQqWdRUGk8BVmYP/0yhrfFs8LHLUAhGnza3f6Xx uFJQdvMmZcSLQQZxFyBvVcNwAK0x1ntnT+jeG/Q0j1oQns6EoWkJ9WzBQIxVQ2+O 9bm45N+gX1K1W1Z0WEX+LCPszntLMvBdp6C3Wp4ff+XvS9e0uHTqftDdD3iUexPA K5wTB5qs+3IWVFEyyPIuJpOqOLhTy9FMct9Ls4m72Uu3FIWPEgjANuT/WkkLASXP Av+qn0hTUzmoNf2nWcjvJQIZvgM6xfpJleWlO2CinOuPunZiackja/qTGlvx7Pu6 Yo5Fs2WdfCB1yx3iPnDcSrJ3pQcZkLqVsGRNdEXdQEHMH1icLR15Z7ynpKkI6uBb JI+vAyq//NbdbRUOPzwN/PA+kGczUTBhTeAnwB5194fdzlfmH9vDsdN8p4CPtsTG 3T3u5EEyn8a/v0nQPssDEfli8Mx4uOswQmTsLgJCJ1H94FbNdGS3R98NmM63A9II rN53o16m6z4C27YQL4q84LwbnWvOEyE9s3xBZMd8hsbTdb7F2syVoSYZazgP5PGc uv/pAwKqwkGU53yBBhj+RqfPXk3qf0bOHtsercIAhnmkIAjI5l7bdxmDyhW4aj49 pWRJgOPAAlQ+VriFoodMZ9PD42pvxUlzicDfvpELVpviHdlTrovky9UC+buCFrtG 7k9GmyHqe/B3LyDjxbh+ =jerq -----END PGP SIGNATURE----- From mail at joachim-breitner.de Tue Oct 20 11:23:03 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 20 Oct 2015 13:23:03 +0200 Subject: Confusing error message when universally quantifying unused type variables In-Reply-To: <56262134.4050605@plaimi.net> References: <56262134.4050605@plaimi.net> Message-ID: <1445340183.3798.20.camel@joachim-breitner.de> Hi, Am Dienstag, den 20.10.2015, 13:10 +0200 schrieb Alexander Berntsen: > In Set theory sentence construction, if the letter is not used then > no foul. In Haskell, it is not always so. > > The following is well-typed and works happily: > f :: Eq a => b -> b > f b = b > > However, this does not work: > f :: ? a. Eq a => b -> b > f b = b > > It will result in the error "Not in scope: type variable ?b?" being > spat out twice. This is expected. If there is any ? in the type, then GHC wants all variables to be properly bound. This is not related to whether a is used or not: Prelude> let f :: a -> b ; f = undefined Prelude> let f :: forall a. a -> b ; f = undefined :5:25: Not in scope: type variable ?b? Prelude> let f :: forall a b. a -> b ; f = undefined > Furthermore the first code snippet I gave also strikes me as > nonsensical; if someone has code like that, it is probably the result > of a typo. Should we really permit it? Is there a motivating reason > for permitting it? If no, I suggest it be an error. (My understanding > of the 2010 report was that it *isn't* permitted, but perhaps I read > it wrong.) You mean type constraints involving an otherwise unused type variable? This seems to be unrelated to the question of foralls. But indeed the 2010 report writes ?The context cx must only contain type variables referenced in t.? https://www.haskell.org/report/node/2010/haskellch4.html#x10-660004.1.3 and even with -XHaskell2010, this is accepted. Might be worth a ticket, although I would not be surprised if some of the type class hackers around here finds a use case for this :-) 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 alexander at plaimi.net Tue Oct 20 11:27:27 2015 From: alexander at plaimi.net (Alexander Berntsen) Date: Tue, 20 Oct 2015 13:27:27 +0200 Subject: Confusing error message when universally quantifying unused type variables In-Reply-To: <1445340183.3798.20.camel@joachim-breitner.de> References: <56262134.4050605@plaimi.net> <1445340183.3798.20.camel@joachim-breitner.de> Message-ID: <5626251F.20201@plaimi.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 20/10/15 13:23, Joachim Breitner wrote: > This is expected. If there is any ? in the type, then GHC wants > all variables to be properly bound. This is not related to whether > a is used or not: I see. I still think the error message could be more specific though... >> Furthermore the first code snippet I gave also strikes me as >> nonsensical; if someone has code like that, it is probably the >> result of a typo. Should we really permit it? Is there a >> motivating reason for permitting it? If no, I suggest it be an >> error. (My understanding of the 2010 report was that it *isn't* >> permitted, but perhaps I read it wrong.) > You mean type constraints involving an otherwise unused type > variable? This seems to be unrelated to the question of foralls. It is. It just hit me while reading through my email before sending it. > But indeed the 2010 report writes ?The context cx must only contain > type variables referenced in t.? > https://www.haskell.org/report/node/2010/haskellch4.html#x10-660004.1.3 > > and even with -XHaskell2010, this is accepted. Then I understood it correctly. I think we should fix this. > Might be worth a ticket, although I would not be surprised if some > of the type class hackers around here finds a use case for this > :-) If there is a usecase for this, it could be a pragma. GHC should not accept it by default though. - -- Alexander alexander at plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJWJiUfAAoJENQqWdRUGk8BwE8QALSsg6Tn0Xet7v4uJ6xRj2Hi Ai2D70snCRi3kVrIbtwN3ZiOQfmLPTqQbohfICMac1AwWA8P9QQ+FKvii5UNh9SG 0YdAOp6SFyIrKU9SobfEiDSM4D2KZJ/6JsJFh4nmmDQWneA7YgGM1Gk2zFlMiW1e oYyERM3qTcMKo1g/qwQOEIvGiWhdbxBQ04NbuOf+cSLAb/rKeBEylzG7dbmtCJeN LFUZPwMOUNFSSXvaM5xGzeSppd+dxEd1zk9JR2lm0Q4J8gRfz3Upibi7tWDtJnia IW0znMAPRXdcjxaonXsmUC1rK+Ub9Ey3Bt0lR37BzCUaAmvYgVfvzhRyDSLUrpFA ym2sBGn75dfWJuor9kbeoQ1kRg1wPrZy9B6/4u7DBFWU2HnSreH6x/Izu741QSdZ 9xXT5caU1H/W76CybbBvnH8IUjv76SP9b83rYBFc0r/JhK3+r/nODckTrif1zAh9 2WOq6q1lo30/bURcNcx0qLZoCoOFmQtOpFTOOD84yCWAfrZ2Ybnnh8Eh/7cd5JQo 8/dIW9wFJCSBL9rX9PbuYygTEPaUHNR099QRZ5LBRp39NjFR/t+Z/gnHpnivxsz0 p12aOPbTNxCbctoeLNE2S/sw9ZDEWnTupUqhF8QLvZieVaznnqwNcsGXUd/qYPP8 Y2l0+sojeWyk8XNKNz+m =nxvb -----END PGP SIGNATURE----- From alexander at plaimi.net Tue Oct 20 11:46:26 2015 From: alexander at plaimi.net (Alexander Berntsen) Date: Tue, 20 Oct 2015 13:46:26 +0200 Subject: Confusing error message when universally quantifying unused type variables In-Reply-To: <5626251F.20201@plaimi.net> References: <56262134.4050605@plaimi.net> <1445340183.3798.20.camel@joachim-breitner.de> <5626251F.20201@plaimi.net> Message-ID: <56262992.7080406@plaimi.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I opened a ticket[0] for the "accepting tv in ctx not mentioned in t"-bug. [0] - -- Alexander alexander at plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJWJimRAAoJENQqWdRUGk8BrxMQALYy+5lMQyyjXC9NOikvsu/1 fMuIPdFcG8pCPuUVcTwSQ3WiqcHf7sfkTMXcFAhDwaEdxBsoOCuMmnLQVD+1lP8I lC6Qht/Ykw1n+Ifdv/F6AEPYsKuZk7DWW1LMAVDimDK+gyDrUmopCwyU/qMNOuwl KvquTHC2MOuIe/RWP6fssF2aeFbY4rnVIOuJezQbGqohgwCsbSLLU5raZCpuiL/R mCvarhl6csZ/uQmY8p/WWosX9r3IXH/z9OF9txAEQLQ//SvHjOVg3KzErKJQcYu8 K8dqmYItbbU5u28yOg7fP+N1fn55WBbA6Z9IaNyJl+WX9wy9lxloS2Sqxor12Nr/ KeWIWncelQ18o5ZX6nccGij/EPIsOidx7Fd92nw+WF07bZBhk8PXZw7F+daNCJKB woTlb1s6bLTsyl8wdheaVajNXMtAsVjQr9fEoB0yxLFpkj8xlh/9JWJ4pjlJonr7 zBGz95myygTQ+y47rRnxwV279v2FommnIF0pzjCuYfuIGaaCshe6pvIJOLdiVh0Y eCRPVUcXGCCg81CQP3vHAiNm2ocpIYT+P6n9wihvjgh5zpcxjkkJO+aYNIRfHbEo CQ8zch+UoF6fcMriJU/B0xrJ+ZZYyFuU/9YgOLJf0uBWUVMvKk/pjrLPRlB8OLWE 8PEOUf+OxyAWcGRwapND =ICmd -----END PGP SIGNATURE----- From omeragacan at gmail.com Tue Oct 20 13:10:09 2015 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Tue, 20 Oct 2015 09:10:09 -0400 Subject: is this change in TH error message intentional? In-Reply-To: <201510200804.29213.jan.stolarek@p.lodz.pl> References: <201510200804.29213.jan.stolarek@p.lodz.pl> Message-ID: Originally I had this file: {-# LANGUAGE TemplateHaskell #-} module Main where import Language.Haskell.TH import Language.Haskell.TH.Syntax -- import LiftLoc main :: IO () main = do let loc :: Loc loc = $(locaton) -- loc = $(locaton >>= lift) print loc But any code with a undefined name inside TH splice would work, I think: {-# LANGUAGE TemplateHaskell #-} module Main where import Language.Haskell.TH main = print $(blah) ? th-test ghc --make Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Main.hs:10:16: Not in scope: ?blah? In the splice: $blah Main.hs:10:16: GHC stage restriction: ?blah? is used in a top-level splice or annotation, and must be imported, not defined locally In the expression: blah In the splice: $blah ? th-test ghc-stage2 --make Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Main.hs:10:16: error: Variable not in scope: blah :: ExpQ 2015-10-20 2:04 GMT-04:00 Jan Stolarek : > ?mer, can you show us the source of Main.hs? > > Janek > > Dnia poniedzia?ek, 19 pa?dziernika 2015, ?mer Sinan A?acan napisa?: >> Hi all, >> >> I realized this change in TH error messages: >> >> GHC 7.10.2: >> >> ? th-test ghc --make Main.hs >> [1 of 1] Compiling Main ( Main.hs, Main.o ) >> >> Main.hs:13:15: >> Not in scope: ?locaton? >> Perhaps you meant ?location? (imported from >> Language.Haskell.TH.Syntax) In the splice: $locaton >> >> Main.hs:13:15: >> GHC stage restriction: >> ?locaton? is used in a top-level splice or annotation, >> and must be imported, not defined locally >> In the expression: locaton >> In the splice: $locaton >> >> I think both error messages are quite useful in this context. I don't see >> second one as redundant. >> >> However, with HEAD: >> >> ? th-test ghc-stage2 --make Main.hs >> [1 of 1] Compiling Main ( Main.hs, Main.o ) >> >> Main.hs:13:15: error: >> Variable not in scope: locaton :: ExpQ >> Perhaps you meant ?location? (imported from >> Language.Haskell.TH.Syntax) >> >> I think this new message is quite worse than previous one. First, "In the >> splice ..." part is missing. Second, "It must be imported, not defined >> locally" message is not given at all. >> >> Was this change intentional? May I ask why it's changed? >> _______________________________________________ >> 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 omeragacan at gmail.com Tue Oct 20 13:19:02 2015 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Tue, 20 Oct 2015 09:19:02 -0400 Subject: Building stage1 only In-Reply-To: <201510200912.02681.jan.stolarek@p.lodz.pl> References: <201510200912.02681.jan.stolarek@p.lodz.pl> Message-ID: > Out of sheer curiosity: in what situations does that happen for you? *If* you > are working on a single branch, ie. you're not switching back and forth > between master and your feature branches, this should not happen (and even if > you switch between branches it should still be safe for most of the time). I'm actually swtiching branches quite a lot, because most of the time I have multiple tasks at hand, working on multiple tickets etc. But I think there's another way to introduce this kind of failures. Since compilation take very long, I never start the build process and wait until it's done, I keep coding in the meantime. Maybe I should rsync changes manually to another directory and run build there while I keep working on current tree etc. I just tried `make 1` in ghc directory and I think it worked(I'll try on a clean tree once I have to `make clean` and see if it's really building only stage-1). But my next question is why marking it as such in build.mk doesn't work.. I'd expect `devel1` to build stage1 only. 2015-10-20 3:12 GMT-04:00 Jan Stolarek : >> it's very easy to end up in a state where `make` simply can't build, and only >> easy fix is a `make clean` > Out of sheer curiosity: in what situations does that happen for you? *If* you are working on a > single branch, ie. you're not switching back and forth between master and your feature branches, > this should not happen (and even if you switch between branches it should still be safe for most > of the time). Richard already gave you a trick (cd ghc/ && make 2) that allows to build only > stage 2 compiler without rebuilding stage 1 or any of the libraries. One situation that comes to > my mind that can really require a full rebuild is changing format of interface files. But other > than that you shouldn't have to do a full rebuild too often. > > I know how you feel. When I started working on GHC I had to do a full rebuild very often. But now > I improved my workflow and only do a full build after a major rebase of my branch against master. > > 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 omeragacan at gmail.com Tue Oct 20 13:22:45 2015 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Tue, 20 Oct 2015 09:22:45 -0400 Subject: Show instances for GHC internals In-Reply-To: <1445306224-sup-7133@sabre> References: <1445306224-sup-7133@sabre> Message-ID: > One difficulty is that many of the core type data types, e.g. TyThing, > are (1) a large mutually recursive graph, and (2) have > unsafeInterleaveIO thunks which would induce IO action. So a naive > Show instance would give infinite output and have lots of side effects. > There are many data types which could usefully have Show added but > also many which would be very difficult to. Ah, yes, this is a very annoying problem. I discovered that when I first wrote CoreDump: https://github.com/osa1/CoreDump/issues/2 I don't have solution to this yet. 2015-10-19 21:59 GMT-04:00 Edward Z. Yang : > Excerpts from ?mer Sinan A?acan's message of 2015-10-19 14:18:41 -0700: >> I was wondering what would be the cost of adding Show instances. Would that >> mean significantly increased compile times? Or significantly bigger GHC >> binaries? If that's the case, could we enable Show instances with some >> arguments so that we can enable/disable it by modifying mk/build.mk? > > One difficulty is that many of the core type data types, e.g. TyThing, > are (1) a large mutually recursive graph, and (2) have > unsafeInterleaveIO thunks which would induce IO action. So a naive > Show instance would give infinite output and have lots of side effects. > There are many data types which could usefully have Show added but > also many which would be very difficult to. > > Edward From omeragacan at gmail.com Tue Oct 20 13:37:44 2015 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Tue, 20 Oct 2015 09:37:44 -0400 Subject: Show instances for GHC internals In-Reply-To: References: <1445306224-sup-7133@sabre> Message-ID: > There are more interesting parts of your post, but I can respond to this: It > shouldn't take that much time. Once you have ghc-stage2 built, you should be > able to say `make 2` in the ./ghc subdirectory and get a new binary in a few > seconds. > > Using `make 1` in the ./compiler subdirectory works similarly for the stage1 > compiler. But only once it's built the first time. I replied this in other thread, I think it works but I'll make sure next time I do a `make clean`. Thanks. Another problem is this: Hiding fields of types is great for safety reasons, but not so great for debugging. In CoreDump I'm having this problems: - Sometimes GHC can't derive Show instance because record fields are hidden. But every field is actually exposed in a read-only way with some manually defined functions. This is super annoying. It'd be really awesome if we could export record fields as "read-only". (very half-baked idea) - Sometimes fields are hidden, and no accessors are provided. This is even worse because now there's really no way to derive Show, using `deriving` or manually. > (2) have unsafeInterleaveIO thunks which would induce IO action Edward, do you remember any examples of such code? 2015-10-20 9:22 GMT-04:00 ?mer Sinan A?acan : >> One difficulty is that many of the core type data types, e.g. TyThing, >> are (1) a large mutually recursive graph, and (2) have >> unsafeInterleaveIO thunks which would induce IO action. So a naive >> Show instance would give infinite output and have lots of side effects. >> There are many data types which could usefully have Show added but >> also many which would be very difficult to. > > Ah, yes, this is a very annoying problem. I discovered that when I first wrote > CoreDump: https://github.com/osa1/CoreDump/issues/2 > > I don't have solution to this yet. > > 2015-10-19 21:59 GMT-04:00 Edward Z. Yang : >> Excerpts from ?mer Sinan A?acan's message of 2015-10-19 14:18:41 -0700: >>> I was wondering what would be the cost of adding Show instances. Would that >>> mean significantly increased compile times? Or significantly bigger GHC >>> binaries? If that's the case, could we enable Show instances with some >>> arguments so that we can enable/disable it by modifying mk/build.mk? >> >> One difficulty is that many of the core type data types, e.g. TyThing, >> are (1) a large mutually recursive graph, and (2) have >> unsafeInterleaveIO thunks which would induce IO action. So a naive >> Show instance would give infinite output and have lots of side effects. >> There are many data types which could usefully have Show added but >> also many which would be very difficult to. >> >> Edward From johan.tibell at gmail.com Tue Oct 20 13:59:29 2015 From: johan.tibell at gmail.com (Johan Tibell) Date: Tue, 20 Oct 2015 15:59:29 +0200 Subject: Taking a step back Message-ID: Friends, I'm taking a step back from day-to-day library work. There are two main reasons I use Haskell: on one hand I find writing Haskell educational and fun. On the other I hope to make it a viable alternative to existing mainstream languages. With recent changes to our core libraries, and the general direction these are moving in, I believe we're moving away from becoming a viable alternative to those mainstream languages. This has some practical implications for how I spend my Haskell hacking time. Much of what I do is maintaining and working on libraries that are needed for real world usage, but that aren't that interesting to work on. I've lost the motivation to work on these. I've decided to take a step back from the core maintenance work on cabal, network, containers, and a few others* starting now. I've already found replacement maintainers for these. I still plan to hack on random side projects, including GHC, and to continue coming to Haskell events and conference, just with a shorter bug backlog to worry about. :) -- Johan Tibell * For now I will still hack on unordered-containers and ekg, as there are some things I'd like to experiment with there. -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Tue Oct 20 14:32:55 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 20 Oct 2015 10:32:55 -0400 Subject: Taking a step back In-Reply-To: References: Message-ID: I look forward to seeing yah around at events, as always! On Tuesday, October 20, 2015, Johan Tibell wrote: > Friends, > > I'm taking a step back from day-to-day library work. > > There are two main reasons I use Haskell: on one hand I find writing > Haskell educational and fun. On the other I hope to make it a viable > alternative to existing mainstream languages. With recent changes to our > core libraries, and the general direction these are moving in, I believe > we're moving away from becoming a viable alternative to those mainstream > languages. > > This has some practical implications for how I spend my Haskell hacking > time. Much of what I do is maintaining and working on libraries that are > needed for real world usage, but that aren't that interesting to work on. > I've lost the motivation to work on these. > > I've decided to take a step back from the core maintenance work on cabal, > network, containers, and a few others* starting now. I've already found > replacement maintainers for these. > > I still plan to hack on random side projects, including GHC, and to > continue coming to Haskell events and conference, just with a shorter bug > backlog to worry about. :) > > -- Johan Tibell > > * For now I will still hack on unordered-containers and ekg, as there are > some things I'd like to experiment with there. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Tue Oct 20 15:06:41 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Tue, 20 Oct 2015 11:06:41 -0400 Subject: Building stage1 only In-Reply-To: References: <201510200912.02681.jan.stolarek@p.lodz.pl> Message-ID: <0CB56A6E-AAA2-45CC-A678-6BDA610056BD@cis.upenn.edu> Hi ?mer, I'll offer my own tips & tricks below. Adopt which ones you like! On Oct 20, 2015, at 9:19 AM, ?mer Sinan A?acan wrote: > > I'm actually swtiching branches quite a lot, because most of the time I have > multiple tasks at hand, working on multiple tickets etc. Yes, switching branches causes lots of problems. To avoid this, I maintain many (13, today) different ghc repos, each in different states/branches. Then I don't have to recompile. Since starting doing this, I haven't looked back -- much better than just one repo with many branches. And git makes it easy enough to move changes back and forth when necessary. (Some repos are actually on the same branch as others but just with different build settings.) > > But I think there's another way to introduce this kind of failures. Since > compilation take very long, I never start the build process and wait until it's > done, I keep coding in the meantime. Maybe I should rsync changes manually to > another directory and run build there while I keep working on current tree etc. I do this also and have not run into trouble with editing while compiling. I don't think this is the issue. > > > I just tried `make 1` in ghc directory and I think it worked(I'll try on a > clean tree once I have to `make clean` and see if it's really building only > stage-1). But my next question is why marking it as such in build.mk doesn't > work.. I'd expect `devel1` to build stage1 only. devel1 means that you're debugging the stage1 compiler, so that compiler is built without optimizations and with DEBUG set. But a great test case for debugging the compiler is building GHC itself. So I wouldn't want devel1 to stop building stage2. Richard > > 2015-10-20 3:12 GMT-04:00 Jan Stolarek : >>> it's very easy to end up in a state where `make` simply can't build, and only >>> easy fix is a `make clean` >> Out of sheer curiosity: in what situations does that happen for you? *If* you are working on a >> single branch, ie. you're not switching back and forth between master and your feature branches, >> this should not happen (and even if you switch between branches it should still be safe for most >> of the time). Richard already gave you a trick (cd ghc/ && make 2) that allows to build only >> stage 2 compiler without rebuilding stage 1 or any of the libraries. One situation that comes to >> my mind that can really require a full rebuild is changing format of interface files. But other >> than that you shouldn't have to do a full rebuild too often. >> >> I know how you feel. When I started working on GHC I had to do a full rebuild very often. But now >> I improved my workflow and only do a full build after a major rebase of my branch against master. >> >> 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 eir at cis.upenn.edu Tue Oct 20 15:44:07 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Tue, 20 Oct 2015 11:44:07 -0400 Subject: is this change in TH error message intentional? In-Reply-To: References: Message-ID: <516F8B87-C8B3-4E11-BE26-823D8DB4F2E4@cis.upenn.edu> I didn't make the change, but I like it (with the exception of loss of context in the first error). I think you should post a bug report about that loss of context. But I, personally, always have found the second one redundant. Richard On Oct 19, 2015, at 4:38 PM, ?mer Sinan A?acan wrote: > Hi all, > > I realized this change in TH error messages: > > GHC 7.10.2: > > ? th-test ghc --make Main.hs > [1 of 1] Compiling Main ( Main.hs, Main.o ) > > Main.hs:13:15: > Not in scope: ?locaton? > Perhaps you meant ?location? (imported from Language.Haskell.TH.Syntax) > In the splice: $locaton > > Main.hs:13:15: > GHC stage restriction: > ?locaton? is used in a top-level splice or annotation, > and must be imported, not defined locally > In the expression: locaton > In the splice: $locaton > > I think both error messages are quite useful in this context. I don't see > second one as redundant. > > However, with HEAD: > > ? th-test ghc-stage2 --make Main.hs > [1 of 1] Compiling Main ( Main.hs, Main.o ) > > Main.hs:13:15: error: > Variable not in scope: locaton :: ExpQ > Perhaps you meant ?location? (imported from Language.Haskell.TH.Syntax) > > I think this new message is quite worse than previous one. First, "In the > splice ..." part is missing. Second, "It must be imported, not defined locally" > message is not given at all. > > Was this change intentional? May I ask why it's changed? > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From cma at bitemyapp.com Tue Oct 20 16:26:04 2015 From: cma at bitemyapp.com (Christopher Allen) Date: Tue, 20 Oct 2015 11:26:04 -0500 Subject: Taking a step back In-Reply-To: References: Message-ID: Thank you for your contributions to the Haskell community. Your work has done a lot, especially for working Haskell programmers like myself and my coworkers. I'm also grateful that you're willing to continue moving the ball forward with unordered-containers and ekg. You didn't mention it explicitly, but what about maintainership of Cassava? I have a soft-spot for that library which I've explained in this Github issue[1] and I'd like the library to get the love & attention I think it deserves. Hoping you'll reconsider your appraisal of Haskell in the future, but if you're not having fun, no reason to suffer. Cheers, [1]: https://github.com/tibbe/cassava/issues/101 On Tue, Oct 20, 2015 at 8:59 AM, Johan Tibell wrote: > Friends, > > I'm taking a step back from day-to-day library work. > > There are two main reasons I use Haskell: on one hand I find writing > Haskell educational and fun. On the other I hope to make it a viable > alternative to existing mainstream languages. With recent changes to our > core libraries, and the general direction these are moving in, I believe > we're moving away from becoming a viable alternative to those mainstream > languages. > > This has some practical implications for how I spend my Haskell hacking > time. Much of what I do is maintaining and working on libraries that are > needed for real world usage, but that aren't that interesting to work on. > I've lost the motivation to work on these. > > I've decided to take a step back from the core maintenance work on cabal, > network, containers, and a few others* starting now. I've already found > replacement maintainers for these. > > I still plan to hack on random side projects, including GHC, and to > continue coming to Haskell events and conference, just with a shorter bug > backlog to worry about. :) > > -- Johan Tibell > > * For now I will still hack on unordered-containers and ekg, as there are > some things I'd like to experiment with there. > > _______________________________________________ > 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 ekmett at gmail.com Tue Oct 20 16:44:56 2015 From: ekmett at gmail.com (Edward Kmett) Date: Tue, 20 Oct 2015 12:44:56 -0400 Subject: Taking a step back In-Reply-To: References: Message-ID: Johan, Thank you so much for all of your contributions to the community. I confess, there are days when I find myself lost in maintenance hell that I feel a desire to throw in the towel as well. (If Eric Mertens and others hadn't picked up so much of the slack on my own projects I'm afraid I likely would have reached the point of gravitational collapse long ago.) I'm terribly sorry to hear that recent attempts to mitigate the impact of changes, the three release policy which as inspired by comments you made, haven't been enough to assuage your fears and discontent about the current direction things are heading. We are all poorer for the loss of your guidance. -Edward On Tue, Oct 20, 2015 at 9:59 AM, Johan Tibell wrote: > Friends, > > I'm taking a step back from day-to-day library work. > > There are two main reasons I use Haskell: on one hand I find writing > Haskell educational and fun. On the other I hope to make it a viable > alternative to existing mainstream languages. With recent changes to our > core libraries, and the general direction these are moving in, I believe > we're moving away from becoming a viable alternative to those mainstream > languages. > > This has some practical implications for how I spend my Haskell hacking > time. Much of what I do is maintaining and working on libraries that are > needed for real world usage, but that aren't that interesting to work on. > I've lost the motivation to work on these. > > I've decided to take a step back from the core maintenance work on cabal, > network, containers, and a few others* starting now. I've already found > replacement maintainers for these. > > I still plan to hack on random side projects, including GHC, and to > continue coming to Haskell events and conference, just with a shorter bug > backlog to worry about. :) > > -- Johan Tibell > > * For now I will still hack on unordered-containers and ekg, as there are > some things I'd like to experiment with there. > > _______________________________________________ > 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 ezyang at mit.edu Tue Oct 20 17:47:20 2015 From: ezyang at mit.edu (Edward Z. Yang) Date: Tue, 20 Oct 2015 10:47:20 -0700 Subject: Show instances for GHC internals In-Reply-To: References: <1445306224-sup-7133@sabre> Message-ID: <1445363172-sup-567@sabre> Excerpts from ?mer Sinan A?acan's message of 2015-10-20 06:37:44 -0700: > Edward, do you remember any examples of such code? The big kahuna is interface loading. Everything TyThing from loadDecls is done (unsafely) lazily. In fact, must be, because TyThings are a mutually recursive structure. Edward From mle+hs at mega-nerd.com Wed Oct 21 06:55:39 2015 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Wed, 21 Oct 2015 17:55:39 +1100 Subject: [Differential] [Closed] D975: ELF/x86_64: map object file sections separately into the low 2GB In-Reply-To: References: Message-ID: <20151021175539.e888c5e0239226bd8938ea02@mega-nerd.com> Thomas Miedema wrote: > This commit is causing segmentation faults on Travis (DYNAMIC_GHC_PROGRAMS > = NO): > https://s3.amazonaws.com/archive.travis-ci.org/jobs/85552765/log.txt This is now trac ticket #10994. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From ggreif at gmail.com Wed Oct 21 10:51:02 2015 From: ggreif at gmail.com (Gabor Greif) Date: Wed, 21 Oct 2015 12:51:02 +0200 Subject: Building HEAD with HEAD fails Message-ID: Hi devs, just a heads-up (pun intended...) (After updating to TOT, boot and configure with a freshly installed TOT ghc as bootstrap compiler. Then 'make clean'.) Running 'make' gives: ... Creating includes/ghcplatform.h... Done. "rm" -f utils/hsc2hs/dist/build/.depend.haskell.tmp "/home/ggreif/bin/ghc" -M -static -H64m -O0 -fasm -package-db libraries/bootstrapping.conf -hide-all-packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist/build -iutils/hsc2hs/dist/build/autogen -Iutils/hsc2hs/dist/build -Iutils/hsc2hs/dist/build/autogen -optP-include -optPutils/hsc2hs/dist/build/autogen/cabal_macros.h -package-id base-4.8.2.0 -package-id containers-0.5.6.2 -package-id directory-1.2.2.0 -package-id filepath-1.4.0.0 -package-id process-1.2.3.0 -XHaskell2010 -no-user-package-db -rtsopts -odir utils/hsc2hs/dist/build -hidir utils/hsc2hs/dist/build -stubdir utils/hsc2hs/dist/build -dep-makefile utils/hsc2hs/dist/build/.depend.haskell.tmp -dep-suffix "" -include-pkg-deps utils/hsc2hs/./Main.hs utils/hsc2hs/./C.hs utils/hsc2hs/./Common.hs utils/hsc2hs/./CrossCodegen.hs utils/hsc2hs/./DirectCodegen.hs utils/hsc2hs/./Flags.hs utils/hsc2hs/./HSCParser.hs utils/hsc2hs/./UtilsCodegen.hs : package db: duplicate packages with incompatible ABIs: binary-0.7.5.0 has ABIs: , c28f822c21e75eb270eca0870e42aaac Cabal-1.23.0.0 has ABIs: , a0a6af8f1dd909f2ee719ddb2cd65779 hpc-0.6.0.2 has ABIs: , 3434375974d4bc6d14952a90ec97d0c4 ghc-boot-0.0.0.0 has ABIs: , f422fc19421064f81c42815f25a11e6e hoopl-3.10.0.2 has ABIs: , 8968e2731ff8d529c37c048d65e94bf2 transformers-0.4.3.0 has ABIs: , 812457c97c58693d7f8a813b1ba19a33 template-haskell-2.11.0.0 has ABIs: , 0ef51476100e9bdf96d1bf59696b98a1 terminfo-0.4.0.1 has ABIs: , aa24f544c0e3614d419e63fa170ac467 The only solution I could come up for now is cd libraries ln -s /home/ggreif/lib/ghc-7.11.20151020/package.conf.d bootstrapping.conf then resuming 'make' leads to success. What could this be? Has somebody seen such an error? Cheers and thanks, Gabor From ggreif at gmail.com Wed Oct 21 11:08:13 2015 From: ggreif at gmail.com (Gabor Greif) Date: Wed, 21 Oct 2015 13:08:13 +0200 Subject: Duplicated typedef trips my gcc over Message-ID: Hi all, look: $ git grep "typedef struct LibDwSession_ " rts/Libdw.c:typedef struct LibDwSession_ LibDwSession; rts/Libdw.h:typedef struct LibDwSession_ LibDwSession; $ which gcc /usr/bin/gcc $ gcc --version gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4) Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Any reason why we need the typedef in rts/Libdw.c ?? My gcc complains about it... Cheers, Gabor From nair.sreenidhi at gmail.com Wed Oct 21 11:49:05 2015 From: nair.sreenidhi at gmail.com (Sreenidhi Nair) Date: Wed, 21 Oct 2015 17:19:05 +0530 Subject: pattern synonym with required ctx having polykinded constraint fails Message-ID: Hello, We have a pattern synonym as follows type family Showable (a :: k) :: Constraint where Showable (a :: *) = (Show a) Showable a = () pattern Just' :: () => (Showable a) => a -> (Maybe a) pattern Just' a <- (extractJust -> (True, a)) where Just' a = Just a When we try to use the pattern in a different package, the error was [1 of 1] Compiling Bar ( Bar.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Bar.o ) /tmp/test/p2/.stack-work/install/x86_64-linux/lts-3.5/7.10.2/lib/x86_64-linux-ghc-7.10.2/p1-0.1.0.0-I5t4il6dN7vIqsT1XgYsM3/Foo.hi Declaration for Just' Pattern synonym Just': Iface type variable out of scope: k Cannot continue after interface file error The error only occurred when Showable was polykinded and we used synonym in a different package . Using the synonym in the same package works fine. This problem did not happen with the following definition of (non polykinded ) Showable type family Showable a :: Constraint where Showable a = (Show a) We have attached the sample packages which simulate the exact scenario described above. -- Yours truly, Sreenidhi Nair -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bug.tar.gz Type: application/x-gzip Size: 2154 bytes Desc: not available URL: From matthewtpickering at gmail.com Wed Oct 21 11:55:02 2015 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Wed, 21 Oct 2015 12:55:02 +0100 Subject: pattern synonym with required ctx having polykinded constraint fails In-Reply-To: References: Message-ID: Looks like a definite bug. Filed as #10977 https://ghc.haskell.org/trac/ghc/ticket/10997 Matt On Wed, Oct 21, 2015 at 12:49 PM, Sreenidhi Nair wrote: > Hello, > > We have a pattern synonym as follows > > type family Showable (a :: k) :: Constraint where > Showable (a :: *) = (Show a) > Showable a = () > > pattern Just' :: () => (Showable a) => a -> (Maybe a) > pattern Just' a <- (extractJust -> (True, a)) where > Just' a = Just a > > When we try to use the pattern in a different package, the error was > > [1 of 1] Compiling Bar ( Bar.hs, > .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Bar.o ) > > /tmp/test/p2/.stack-work/install/x86_64-linux/lts-3.5/7.10.2/lib/x86_64-linux-ghc-7.10.2/p1-0.1.0.0-I5t4il6dN7vIqsT1XgYsM3/Foo.hi > Declaration for Just' > Pattern synonym Just': > Iface type variable out of scope: k > Cannot continue after interface file error > > The error only occurred when Showable was polykinded and we used synonym in > a different package . Using the synonym in the same package works fine. > > This problem did not happen with the following definition of (non polykinded > ) Showable > > type family Showable a :: Constraint where > Showable a = (Show a) > > We have attached the sample packages which simulate the exact scenario > described above. > > -- > Yours truly, > Sreenidhi Nair > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From mike at barrucadu.co.uk Wed Oct 21 12:01:05 2015 From: mike at barrucadu.co.uk (Michael Walker) Date: Wed, 21 Oct 2015 13:01:05 +0100 Subject: Memory fence around stg_atomicModifyMutVarzh Message-ID: <20151021120105.GG25614@localhost.localdomain> Hello, I've been trying to figure out where exactly the synchronisation guarantee of `atomicModifyIORef` comes from, I've gone down a bit of a rabbit-hole of function calls and macro expansions, and wanted to check I'd got the right idea. **Assumption:** `stg_atomicModifyMutVarzh` imposes a barrier to reordering, as described in the Data.IORef documentation. Call tree: stg_atomicModifyMutVarzh dirty_MUT_VAR recordClosureMutated recordMutableCap allocBlock_lock ACQUIRE_SM_LOCK -> ACQUIRE_LOCK -> pthread_mutex_lock **Conclusion:** `pthread_mutex_lock` imposes a memory barrier, and it is through this rather indirect chain of function calls that `stg_atomicModifyMutVarzh` gets its barrier property. Is this correct? Or is there a more direct barrier invocation that I have missed? Thanks. -- Michael Walker (http://www.barrucadu.co.uk) From nair.sreenidhi at gmail.com Wed Oct 21 12:17:19 2015 From: nair.sreenidhi at gmail.com (Sreenidhi Nair) Date: Wed, 21 Oct 2015 17:47:19 +0530 Subject: pattern synonym with required ctx having polykinded constraint fails In-Reply-To: References: Message-ID: Thanks Matthew, Do you think there is any workaround to this issue that we could try? On Wed, Oct 21, 2015 at 5:25 PM, Matthew Pickering < matthewtpickering at gmail.com> wrote: > Looks like a definite bug. Filed as #10977 > > https://ghc.haskell.org/trac/ghc/ticket/10997 > > Matt > > On Wed, Oct 21, 2015 at 12:49 PM, Sreenidhi Nair > wrote: > > Hello, > > > > We have a pattern synonym as follows > > > > type family Showable (a :: k) :: Constraint where > > Showable (a :: *) = (Show a) > > Showable a = () > > > > pattern Just' :: () => (Showable a) => a -> (Maybe a) > > pattern Just' a <- (extractJust -> (True, a)) where > > Just' a = Just a > > > > When we try to use the pattern in a different package, the error was > > > > [1 of 1] Compiling Bar ( Bar.hs, > > .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Bar.o ) > > > > > /tmp/test/p2/.stack-work/install/x86_64-linux/lts-3.5/7.10.2/lib/x86_64-linux-ghc-7.10.2/p1-0.1.0.0-I5t4il6dN7vIqsT1XgYsM3/Foo.hi > > Declaration for Just' > > Pattern synonym Just': > > Iface type variable out of scope: k > > Cannot continue after interface file error > > > > The error only occurred when Showable was polykinded and we used synonym > in > > a different package . Using the synonym in the same package works fine. > > > > This problem did not happen with the following definition of (non > polykinded > > ) Showable > > > > type family Showable a :: Constraint where > > Showable a = (Show a) > > > > We have attached the sample packages which simulate the exact scenario > > described above. > > > > -- > > Yours truly, > > Sreenidhi Nair > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > -- Yours truly, Sreenidhi Nair -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Wed Oct 21 12:17:59 2015 From: ben at well-typed.com (Ben Gamari) Date: Wed, 21 Oct 2015 14:17:59 +0200 Subject: Memory fence around stg_atomicModifyMutVarzh In-Reply-To: <20151021120105.GG25614@localhost.localdomain> References: <20151021120105.GG25614@localhost.localdomain> Message-ID: <87y4ew5saw.fsf@smart-cactus.org> Michael Walker writes: > Hello, > > I've been trying to figure out where exactly the synchronisation guarantee of > `atomicModifyIORef` comes from, I've gone down a bit of a rabbit-hole of function > calls and macro expansions, and wanted to check I'd got the right idea. > > **Assumption:** `stg_atomicModifyMutVarzh` imposes a barrier to reordering, as > described in the Data.IORef documentation. > > Call tree: > > stg_atomicModifyMutVarzh > dirty_MUT_VAR > recordClosureMutated > recordMutableCap > allocBlock_lock > ACQUIRE_SM_LOCK -> ACQUIRE_LOCK -> pthread_mutex_lock > > **Conclusion:** `pthread_mutex_lock` imposes a memory barrier, and it is through > this rather indirect chain of function calls that `stg_atomicModifyMutVarzh` > gets its barrier property. > > Is this correct? Or is there a more direct barrier invocation that I have > missed? > I'm afraid I don't know off the top of my head but hopefully Simon Marlow will be able to shed some more light here. When he does it would be great if you could write a nice comment explaining this logic and either open a Phabricator Diff or send the text to me so I can merge 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 marlowsd at gmail.com Wed Oct 21 13:00:32 2015 From: marlowsd at gmail.com (Simon Marlow) Date: Wed, 21 Oct 2015 14:00:32 +0100 Subject: Memory fence around stg_atomicModifyMutVarzh In-Reply-To: <87y4ew5saw.fsf@smart-cactus.org> References: <20151021120105.GG25614@localhost.localdomain> <87y4ew5saw.fsf@smart-cactus.org> Message-ID: <56278C70.5070703@gmail.com> On 21/10/2015 13:17, Ben Gamari wrote: > Michael Walker writes: > >> Hello, >> >> I've been trying to figure out where exactly the synchronisation guarantee of >> `atomicModifyIORef` comes from, I've gone down a bit of a rabbit-hole of function >> calls and macro expansions, and wanted to check I'd got the right idea. >> >> **Assumption:** `stg_atomicModifyMutVarzh` imposes a barrier to reordering, as >> described in the Data.IORef documentation. >> >> Call tree: >> >> stg_atomicModifyMutVarzh >> dirty_MUT_VAR >> recordClosureMutated >> recordMutableCap >> allocBlock_lock >> ACQUIRE_SM_LOCK -> ACQUIRE_LOCK -> pthread_mutex_lock >> >> **Conclusion:** `pthread_mutex_lock` imposes a memory barrier, and it is through >> this rather indirect chain of function calls that `stg_atomicModifyMutVarzh` >> gets its barrier property. >> >> Is this correct? Or is there a more direct barrier invocation that I have >> missed? >> > I'm afraid I don't know off the top of my head but hopefully Simon > Marlow will be able to shed some more light here. > > When he does it would be great if you could write a nice comment > explaining this logic and either open a Phabricator Diff or send the > text to me so I can merge it. Here is the barrier: (h) = ccall cas(mv + SIZEOF_StgHeader + OFFSET_StgMutVar_var, x, y); cas() is an external C function defined in includes/stg/SMP.h using inline assembly. Cheers Simon From mike at barrucadu.co.uk Wed Oct 21 17:58:50 2015 From: mike at barrucadu.co.uk (Michael Walker) Date: Wed, 21 Oct 2015 18:58:50 +0100 Subject: Memory fence around stg_atomicModifyMutVarzh In-Reply-To: <56278C70.5070703@gmail.com> References: <20151021120105.GG25614@localhost.localdomain> <87y4ew5saw.fsf@smart-cactus.org> <56278C70.5070703@gmail.com> Message-ID: <20151021175850.GB30186@localhost.localdomain> > >I'm afraid I don't know off the top of my head but hopefully Simon > >Marlow will be able to shed some more light here. > > > >When he does it would be great if you could write a nice comment > >explaining this logic and either open a Phabricator Diff or send the > >text to me so I can merge it. > > Here is the barrier: > > (h) = ccall cas(mv + SIZEOF_StgHeader + OFFSET_StgMutVar_var, x, y); > > cas() is an external C function defined in includes/stg/SMP.h using inline > assembly. Wow, I really did miss it. Thanks for pointing it out. I also have a question about the sort of relaxed behaviours permitted. The Data.IORef docs say: > The implementation is required to ensure that reordering of memory operations > cannot cause type-correct code to go wrong. In particular, when inspecting the > value read from an IORef, the memory writes that created that value must have > occurred from the point of view of the current thread. but I'm not sure that's enough. This also seems clearly wrong, but is permitted by that restriction: ?> newIORef False >>= \ref -> writeIORef ref True >> readIORef ref False Is there a write-up anywhere of the memory model the GHC primitives give rise to? Or is it just one of those cases where the code is the specification? Thanks -- Michael Walker (http://www.barrucadu.co.uk) From fryguybob at gmail.com Wed Oct 21 18:26:41 2015 From: fryguybob at gmail.com (Ryan Yates) Date: Wed, 21 Oct 2015 14:26:41 -0400 Subject: Memory fence around stg_atomicModifyMutVarzh In-Reply-To: <20151021175850.GB30186@localhost.localdomain> References: <20151021120105.GG25614@localhost.localdomain> <87y4ew5saw.fsf@smart-cactus.org> <56278C70.5070703@gmail.com> <20151021175850.GB30186@localhost.localdomain> Message-ID: Hi Michael, I don't think you can take that paragraph as an exhaustive description of what orderings are allowed. Edward Yang has a post about the current state of GHC and memory models that I think is still how things are: http://blog.ezyang.com/2014/01/so-you-want-to-add-a-new-concurrency-primitive-to-ghc/ Ryan On Wed, Oct 21, 2015 at 1:58 PM, Michael Walker wrote: > > >I'm afraid I don't know off the top of my head but hopefully Simon > > >Marlow will be able to shed some more light here. > > > > > >When he does it would be great if you could write a nice comment > > >explaining this logic and either open a Phabricator Diff or send the > > >text to me so I can merge it. > > > > Here is the barrier: > > > > (h) = ccall cas(mv + SIZEOF_StgHeader + OFFSET_StgMutVar_var, x, y); > > > > cas() is an external C function defined in includes/stg/SMP.h using > inline > > assembly. > > Wow, I really did miss it. Thanks for pointing it out. > > I also have a question about the sort of relaxed behaviours permitted. The > Data.IORef docs say: > > > The implementation is required to ensure that reordering of memory > operations > > cannot cause type-correct code to go wrong. In particular, when > inspecting the > > value read from an IORef, the memory writes that created that value must > have > > occurred from the point of view of the current thread. > > but I'm not sure that's enough. This also seems clearly wrong, but is > permitted > by that restriction: > > ?> newIORef False >>= \ref -> writeIORef ref True >> readIORef ref > False > > Is there a write-up anywhere of the memory model the GHC primitives give > rise > to? Or is it just one of those cases where the code is the specification? > > Thanks > > -- > Michael Walker (http://www.barrucadu.co.uk) > _______________________________________________ > 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 ezyang at mit.edu Wed Oct 21 18:44:26 2015 From: ezyang at mit.edu (Edward Z. Yang) Date: Wed, 21 Oct 2015 11:44:26 -0700 Subject: Building HEAD with HEAD fails In-Reply-To: References: Message-ID: <1445453019-sup-6313@sabre> This is likely my fault, w.r.t. to the recent Cabal submodule update. I'm a bit confused why there are things in the DB that don't have ABI hashes though... Edward Excerpts from Gabor Greif's message of 2015-10-21 03:51:02 -0700: > Hi devs, > > just a heads-up (pun intended...) > > (After updating to TOT, boot and configure with a freshly installed > TOT ghc as bootstrap compiler. Then 'make clean'.) > > Running 'make' gives: > > ... > Creating includes/ghcplatform.h... > Done. > "rm" -f utils/hsc2hs/dist/build/.depend.haskell.tmp > "/home/ggreif/bin/ghc" -M -static -H64m -O0 -fasm -package-db > libraries/bootstrapping.conf -hide-all-packages -i -iutils/hsc2hs/. > -iutils/hsc2hs/dist/build -iutils/hsc2hs/dist/build/autogen > -Iutils/hsc2hs/dist/build -Iutils/hsc2hs/dist/build/autogen > -optP-include -optPutils/hsc2hs/dist/build/autogen/cabal_macros.h > -package-id base-4.8.2.0 -package-id containers-0.5.6.2 -package-id > directory-1.2.2.0 -package-id filepath-1.4.0.0 -package-id > process-1.2.3.0 -XHaskell2010 -no-user-package-db -rtsopts -odir > utils/hsc2hs/dist/build -hidir utils/hsc2hs/dist/build -stubdir > utils/hsc2hs/dist/build -dep-makefile > utils/hsc2hs/dist/build/.depend.haskell.tmp -dep-suffix "" > -include-pkg-deps utils/hsc2hs/./Main.hs utils/hsc2hs/./C.hs > utils/hsc2hs/./Common.hs utils/hsc2hs/./CrossCodegen.hs > utils/hsc2hs/./DirectCodegen.hs utils/hsc2hs/./Flags.hs > utils/hsc2hs/./HSCParser.hs utils/hsc2hs/./UtilsCodegen.hs > : package db: duplicate packages with incompatible ABIs: > binary-0.7.5.0 has ABIs: , c28f822c21e75eb270eca0870e42aaac > Cabal-1.23.0.0 has ABIs: , a0a6af8f1dd909f2ee719ddb2cd65779 > hpc-0.6.0.2 has ABIs: , 3434375974d4bc6d14952a90ec97d0c4 > ghc-boot-0.0.0.0 has ABIs: , f422fc19421064f81c42815f25a11e6e > hoopl-3.10.0.2 has ABIs: , 8968e2731ff8d529c37c048d65e94bf2 > transformers-0.4.3.0 has ABIs: , 812457c97c58693d7f8a813b1ba19a33 > template-haskell-2.11.0.0 has ABIs: , 0ef51476100e9bdf96d1bf59696b98a1 > terminfo-0.4.0.1 has ABIs: , aa24f544c0e3614d419e63fa170ac467 > > > The only solution I could come up for now is > > cd libraries > ln -s /home/ggreif/lib/ghc-7.11.20151020/package.conf.d bootstrapping.conf > > then resuming 'make' leads to success. > > What could this be? Has somebody seen such an error? > > Cheers and thanks, > > Gabor From ezyang at mit.edu Thu Oct 22 04:57:05 2015 From: ezyang at mit.edu (Edward Z. Yang) Date: Wed, 21 Oct 2015 21:57:05 -0700 Subject: MIN_VERSION macros In-Reply-To: References: <1443197911.1703862.393595953.081AB0FF@webmail.messagingengine.com> <1443211530-sup-302@sabre> Message-ID: <1445489815-sup-9767@sabre> Hi all, I've implemented this: https://phabricator.haskell.org/D1349 Cheers, Edward Excerpts from Reid Barton's message of 2015-09-25 15:15:09 -0700: > On Fri, Sep 25, 2015 at 4:09 PM, Edward Z. Yang wrote: > > > Excerpts from Reid Barton's message of 2015-09-25 12:36:48 -0700: > > > GHC could provide MIN_VERSION_* macros for packages that have had their > > > versions specified with -package or similar flags (which is how Cabal > > > invokes GHC). That would go only a small way towards the original goals > > > though. > > > > This is exactly what the MIN_VERSION_* macros should do, and you can > > generalize it to work even without -package: you get macros for EXPOSED > > packages which are available for import. This says *nothing* about > > the transitive dependencies of the packages you're depending on, but > > it's more reasonable to have "one package, one version" invariant, > > because having multiple versions of the package exposed would cause > > a module name to be ambiguous (and unusable.) > > > Oh, I see. I had always assumed that GHC had some kind of solver to try to > pick compatible versions of packages, but having done some experiments, I > see that it always picks the newest exposed version of each direct > dependency. So we can indeed define MIN_VERSION_* macros in accordance with > the newest exposed version of each package. > > There are still some edge cases, notably: if package foo reexports the > contents of some modules from package bar, and the API of these modules > changes between two versions of package bar, then you cannot reliably use > MIN_VERSION_bar to detect these API changes in a module that imports the > reexports from package foo (since the newest installed foo might not be > built against the newest installed bar). In the more restrictive Cabal > model, you can reliably do this of course. So it could break in an existing > project. However this kind of situation (where the API of a package depends > on the version of its dependencies) should hopefully be fairly rare in > practice. > > Regards, > Reid Barton From ezyang at mit.edu Thu Oct 22 05:58:08 2015 From: ezyang at mit.edu (Edward Z. Yang) Date: Wed, 21 Oct 2015 22:58:08 -0700 Subject: Building HEAD with HEAD fails In-Reply-To: <1445453019-sup-6313@sabre> References: <1445453019-sup-6313@sabre> Message-ID: <1445493115-sup-7306@sabre> So... I can't reproduce this. I validated a copy of GHC HEAD, and then used the inplace ghc-stage2 to build another using ./configure --with-ghc=... and it built fine. Maybe, do you have some more details? Edward Excerpts from Edward Z. Yang's message of 2015-10-21 11:44:26 -0700: > This is likely my fault, w.r.t. to the recent Cabal submodule update. > I'm a bit confused why there are things in the DB that don't have ABI > hashes though... > > Edward > > Excerpts from Gabor Greif's message of 2015-10-21 03:51:02 -0700: > > Hi devs, > > > > just a heads-up (pun intended...) > > > > (After updating to TOT, boot and configure with a freshly installed > > TOT ghc as bootstrap compiler. Then 'make clean'.) > > > > Running 'make' gives: > > > > ... > > Creating includes/ghcplatform.h... > > Done. > > "rm" -f utils/hsc2hs/dist/build/.depend.haskell.tmp > > "/home/ggreif/bin/ghc" -M -static -H64m -O0 -fasm -package-db > > libraries/bootstrapping.conf -hide-all-packages -i -iutils/hsc2hs/. > > -iutils/hsc2hs/dist/build -iutils/hsc2hs/dist/build/autogen > > -Iutils/hsc2hs/dist/build -Iutils/hsc2hs/dist/build/autogen > > -optP-include -optPutils/hsc2hs/dist/build/autogen/cabal_macros.h > > -package-id base-4.8.2.0 -package-id containers-0.5.6.2 -package-id > > directory-1.2.2.0 -package-id filepath-1.4.0.0 -package-id > > process-1.2.3.0 -XHaskell2010 -no-user-package-db -rtsopts -odir > > utils/hsc2hs/dist/build -hidir utils/hsc2hs/dist/build -stubdir > > utils/hsc2hs/dist/build -dep-makefile > > utils/hsc2hs/dist/build/.depend.haskell.tmp -dep-suffix "" > > -include-pkg-deps utils/hsc2hs/./Main.hs utils/hsc2hs/./C.hs > > utils/hsc2hs/./Common.hs utils/hsc2hs/./CrossCodegen.hs > > utils/hsc2hs/./DirectCodegen.hs utils/hsc2hs/./Flags.hs > > utils/hsc2hs/./HSCParser.hs utils/hsc2hs/./UtilsCodegen.hs > > : package db: duplicate packages with incompatible ABIs: > > binary-0.7.5.0 has ABIs: , c28f822c21e75eb270eca0870e42aaac > > Cabal-1.23.0.0 has ABIs: , a0a6af8f1dd909f2ee719ddb2cd65779 > > hpc-0.6.0.2 has ABIs: , 3434375974d4bc6d14952a90ec97d0c4 > > ghc-boot-0.0.0.0 has ABIs: , f422fc19421064f81c42815f25a11e6e > > hoopl-3.10.0.2 has ABIs: , 8968e2731ff8d529c37c048d65e94bf2 > > transformers-0.4.3.0 has ABIs: , 812457c97c58693d7f8a813b1ba19a33 > > template-haskell-2.11.0.0 has ABIs: , 0ef51476100e9bdf96d1bf59696b98a1 > > terminfo-0.4.0.1 has ABIs: , aa24f544c0e3614d419e63fa170ac467 > > > > > > The only solution I could come up for now is > > > > cd libraries > > ln -s /home/ggreif/lib/ghc-7.11.20151020/package.conf.d bootstrapping.conf > > > > then resuming 'make' leads to success. > > > > What could this be? Has somebody seen such an error? > > > > Cheers and thanks, > > > > Gabor From ggreif at gmail.com Thu Oct 22 06:47:37 2015 From: ggreif at gmail.com (Gabor Greif) Date: Thu, 22 Oct 2015 08:47:37 +0200 Subject: Building HEAD with HEAD fails In-Reply-To: <1445493115-sup-7306@sabre> References: <1445453019-sup-6313@sabre> <1445493115-sup-7306@sabre> Message-ID: I did not use an inplace-stage2 but had a 'make install' before and did a boot/reconfigure. Not sure whether this detail is relevant. How can I debug this problem? What does the error message say precisely? Cheers, Gabor On 10/22/15, Edward Z. Yang wrote: > So... I can't reproduce this. I validated a copy of GHC HEAD, > and then used the inplace ghc-stage2 to build another using > ./configure --with-ghc=... and it built fine. > > Maybe, do you have some more details? > > Edward > > Excerpts from Edward Z. Yang's message of 2015-10-21 11:44:26 -0700: >> This is likely my fault, w.r.t. to the recent Cabal submodule update. >> I'm a bit confused why there are things in the DB that don't have ABI >> hashes though... >> >> Edward >> >> Excerpts from Gabor Greif's message of 2015-10-21 03:51:02 -0700: >> > Hi devs, >> > >> > just a heads-up (pun intended...) >> > >> > (After updating to TOT, boot and configure with a freshly installed >> > TOT ghc as bootstrap compiler. Then 'make clean'.) >> > >> > Running 'make' gives: >> > >> > ... >> > Creating includes/ghcplatform.h... >> > Done. >> > "rm" -f utils/hsc2hs/dist/build/.depend.haskell.tmp >> > "/home/ggreif/bin/ghc" -M -static -H64m -O0 -fasm -package-db >> > libraries/bootstrapping.conf -hide-all-packages -i -iutils/hsc2hs/. >> > -iutils/hsc2hs/dist/build -iutils/hsc2hs/dist/build/autogen >> > -Iutils/hsc2hs/dist/build -Iutils/hsc2hs/dist/build/autogen >> > -optP-include -optPutils/hsc2hs/dist/build/autogen/cabal_macros.h >> > -package-id base-4.8.2.0 -package-id containers-0.5.6.2 -package-id >> > directory-1.2.2.0 -package-id filepath-1.4.0.0 -package-id >> > process-1.2.3.0 -XHaskell2010 -no-user-package-db -rtsopts -odir >> > utils/hsc2hs/dist/build -hidir utils/hsc2hs/dist/build -stubdir >> > utils/hsc2hs/dist/build -dep-makefile >> > utils/hsc2hs/dist/build/.depend.haskell.tmp -dep-suffix "" >> > -include-pkg-deps utils/hsc2hs/./Main.hs utils/hsc2hs/./C.hs >> > utils/hsc2hs/./Common.hs utils/hsc2hs/./CrossCodegen.hs >> > utils/hsc2hs/./DirectCodegen.hs utils/hsc2hs/./Flags.hs >> > utils/hsc2hs/./HSCParser.hs utils/hsc2hs/./UtilsCodegen.hs >> > : package db: duplicate packages with incompatible ABIs: >> > binary-0.7.5.0 has ABIs: , c28f822c21e75eb270eca0870e42aaac >> > Cabal-1.23.0.0 has ABIs: , a0a6af8f1dd909f2ee719ddb2cd65779 >> > hpc-0.6.0.2 has ABIs: , 3434375974d4bc6d14952a90ec97d0c4 >> > ghc-boot-0.0.0.0 has ABIs: , f422fc19421064f81c42815f25a11e6e >> > hoopl-3.10.0.2 has ABIs: , 8968e2731ff8d529c37c048d65e94bf2 >> > transformers-0.4.3.0 has ABIs: , 812457c97c58693d7f8a813b1ba19a33 >> > template-haskell-2.11.0.0 has ABIs: , >> > 0ef51476100e9bdf96d1bf59696b98a1 >> > terminfo-0.4.0.1 has ABIs: , aa24f544c0e3614d419e63fa170ac467 >> > >> > >> > The only solution I could come up for now is >> > >> > cd libraries >> > ln -s /home/ggreif/lib/ghc-7.11.20151020/package.conf.d >> > bootstrapping.conf >> > >> > then resuming 'make' leads to success. >> > >> > What could this be? Has somebody seen such an error? >> > >> > Cheers and thanks, >> > >> > Gabor > From george.colpitts at gmail.com Thu Oct 22 13:06:38 2015 From: george.colpitts at gmail.com (George Colpitts) Date: Thu, 22 Oct 2015 10:06:38 -0300 Subject: [GHC] #10053: Regression on MacOS platform, error in ghci calling main after loading compiled code: "Too late for parseStaticFlags..." In-Reply-To: <060.fce1a269154a69645d593c20a652b407@haskell.org> References: <045.7defde488a4af19895968f8c8b9b5f95@haskell.org> <060.fce1a269154a69645d593c20a652b407@haskell.org> Message-ID: Right, as it says in title "error in ghci calling main after loading compiled code" On Thursday, October 22, 2015, GHC wrote: > #10053: Regression on MacOS platform, error in ghci calling main after > loading > compiled code: "Too late for parseStaticFlags..." > -------------------------------------+------------------------------------- > Reporter: George | Owner: > Type: bug | Status: new > Priority: normal | Milestone: 8.0.1 > Component: GHCi | Version: 7.10.1-rc2 > Resolution: | Keywords: > Operating System: MacOS X | Architecture: x86_64 > Type of failure: Incorrect result | (amd64) > at runtime | Test Case: > Blocked By: | Blocking: > Related Tickets: | Differential Rev(s): > Wiki Page: | > -------------------------------------+------------------------------------- > Changes (by bgamari): > > * milestone: 7.10.3 => 8.0.1 > > > Old description: > > > ghci > > GHCi, version 7.10.0.20150123: http://www.haskell.org/ghc/ :? for help > > Prelude> :load rsa > > Ok, modules loaded: Main. > > Prelude Main> :show modules > > Main ( rsa.hs, rsa.o ) > > Prelude Main> main > > Too late for parseStaticFlags: call it before runGhc or runGhcT > > Exception: ExitFailure 1 > > Prelude Main> > > > > note, there is no failure if I load interpreted code > > New description: > > {{{ > $ ghci > GHCi, version 7.10.0.20150123: http://www.haskell.org/ghc/ :? for help > Prelude> :load rsa > Ok, modules loaded: Main. > Prelude Main> :show modules > Main ( rsa.hs, rsa.o ) > Prelude Main> main > Too late for parseStaticFlags: call it before runGhc or runGhcT > Exception: ExitFailure 1 > Prelude Main> > }}} > > note, there is no failure if I load interpreted code > > -- > > Comment: > > This isn't going to be fixed for 7.10.3. > > -- > Ticket URL: > GHC > The Glasgow Haskell Compiler > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Thu Oct 22 13:56:00 2015 From: david.feuer at gmail.com (David Feuer) Date: Thu, 22 Oct 2015 09:56:00 -0400 Subject: Coercion logic Message-ID: At present, any time we write a function with a `Coercible` constraint, we must take great care to choose `Coercible a b` or `Coercible b a` depending on which will ultimately lead to fewer silly conversions. This is particularly sad because the whole Coercible mechanism guarantees that these have exactly the same run-time representation, and because People Wiser Than Me believe Coercible should *always* remain symmetric. My (admittedly reptilian) brain wonders what it would take to tell the type checker that forall a b . Coercible a b ~ Coercible b a and have it over with. David Feuer From eir at cis.upenn.edu Thu Oct 22 13:57:56 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Thu, 22 Oct 2015 09:57:56 -0400 Subject: Coercion logic In-Reply-To: References: Message-ID: <790651CB-2A8D-45B8-AF6E-37BCD5605647@cis.upenn.edu> The Coercible solver has evolved steadily. It should know that (Coercible a b <=> Coercible b a). Do you have a concrete example of where it's not doing this? Have you tested against HEAD? Thanks, Richard On Oct 22, 2015, at 9:56 AM, David Feuer wrote: > At present, any time we write a function with a `Coercible` > constraint, we must take great care to choose `Coercible a b` or > `Coercible b a` depending on which will ultimately lead to fewer silly > conversions. This is particularly sad because the whole Coercible > mechanism guarantees that these have exactly the same run-time > representation, and because People Wiser Than Me believe Coercible > should *always* remain symmetric. My (admittedly reptilian) brain > wonders what it would take to tell the type checker that > > forall a b . Coercible a b ~ Coercible b a > > and have it over with. > > David Feuer > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From david.feuer at gmail.com Thu Oct 22 14:06:23 2015 From: david.feuer at gmail.com (David Feuer) Date: Thu, 22 Oct 2015 10:06:23 -0400 Subject: Coercion logic In-Reply-To: <790651CB-2A8D-45B8-AF6E-37BCD5605647@cis.upenn.edu> References: <790651CB-2A8D-45B8-AF6E-37BCD5605647@cis.upenn.edu> Message-ID: No, I've not tested against head. I'd not heard anything new about that! That sounds exciting. Sorry about the noise if it's all finished already. David On Thu, Oct 22, 2015 at 9:57 AM, Richard Eisenberg wrote: > The Coercible solver has evolved steadily. It should know that (Coercible a b <=> Coercible b a). Do you have a concrete example of where it's not doing this? Have you tested against HEAD? > > Thanks, > Richard > > On Oct 22, 2015, at 9:56 AM, David Feuer wrote: > >> At present, any time we write a function with a `Coercible` >> constraint, we must take great care to choose `Coercible a b` or >> `Coercible b a` depending on which will ultimately lead to fewer silly >> conversions. This is particularly sad because the whole Coercible >> mechanism guarantees that these have exactly the same run-time >> representation, and because People Wiser Than Me believe Coercible >> should *always* remain symmetric. My (admittedly reptilian) brain >> wonders what it would take to tell the type checker that >> >> forall a b . Coercible a b ~ Coercible b a >> >> and have it over with. >> >> David Feuer >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From simonpj at microsoft.com Thu Oct 22 16:47:52 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 22 Oct 2015 16:47:52 +0000 Subject: Type-level error messages In-Reply-To: References: <156b77b4a1a444c7a8d4465d4d941c9d@AM3PR30MB019.064d.mgd.msft.net> Message-ID: <8dd0d26809c543e88c9e2da6f91a8f2d@DB4PR30MB030.064d.mgd.msft.net> I?ve forgotten the state of your type-level error messages work. How?s it going? I think we should try to add it to 8.0.1. The current status is that the idea is implemented on a branch. Then, there were some comments and suggestions that maybe we should do things in a different way, implementation wise. I haven't had a chance to look into these in detail, or implement them, and as far as I know nobody else has stepped up to make the changes. So we could simply go with the current version, and if for some reason we want to change the implementation we could do it later, as I don't think the API will be affected in any way. When do the changes need to happen by, so that it makes it in 8.0? I have been a bit busy, but I could probably find some time to make whatever changes are required for this to be merged. OK good! In that case ? Add it to the hoped-for features in the GHC 8.01. status page ? Write a wiki page with a specification ? Announce the proposal and seek feedback ? Meanwhile make sure the branch reflects what you want to be in it If you don?t have time, well, no harm done? any progress you make on the above will still be useful. Simon From: Iavor Diatchki [mailto:iavor.diatchki at gmail.com] Sent: 22 October 2015 17:42 To: Simon Peyton Jones Cc: Augustsson, Lennart Subject: Re: Type-level error messages Hello, I think we should try to add it to 8.0.1. The current status is that the idea is implemented on a branch. Then, there were some comments and suggestions that maybe we should do things in a different way, implementation wise. I haven't had a chance to look into these in detail, or implement them, and as far as I know nobody else has stepped up to make the changes. So we could simply go with the current version, and if for some reason we want to change the implementation we could do it later, as I don't think the API will be affected in any way. When do the changes need to happen by, so that it makes it in 8.0? I have been a bit busy, but I could probably find some time to make whatever changes are required for this to be merged. -Iavor On Thu, Oct 22, 2015 at 3:47 AM, Simon Peyton Jones > wrote: Iavor I?ve forgotten the state of your type-level error messages work. How?s it going? It?s not mentioned on https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1: shouldn?t it be? Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Thu Oct 22 20:09:25 2015 From: ezyang at mit.edu (Edward Z. Yang) Date: Thu, 22 Oct 2015 13:09:25 -0700 Subject: Building HEAD with HEAD fails In-Reply-To: References: <1445453019-sup-6313@sabre> <1445493115-sup-7306@sabre> Message-ID: <1445544161-sup-2885@sabre> Scratch that, I managed to reproduced. (As you said, it occurs only when you do the bindist.) I'll debug. Edward Excerpts from Gabor Greif's message of 2015-10-21 23:47:37 -0700: > I did not use an inplace-stage2 but had a 'make install' before and > did a boot/reconfigure. > > Not sure whether this detail is relevant. > > How can I debug this problem? What does the error message say precisely? > > Cheers, > > Gabor > > On 10/22/15, Edward Z. Yang wrote: > > So... I can't reproduce this. I validated a copy of GHC HEAD, > > and then used the inplace ghc-stage2 to build another using > > ./configure --with-ghc=... and it built fine. > > > > Maybe, do you have some more details? > > > > Edward > > > > Excerpts from Edward Z. Yang's message of 2015-10-21 11:44:26 -0700: > >> This is likely my fault, w.r.t. to the recent Cabal submodule update. > >> I'm a bit confused why there are things in the DB that don't have ABI > >> hashes though... > >> > >> Edward > >> > >> Excerpts from Gabor Greif's message of 2015-10-21 03:51:02 -0700: > >> > Hi devs, > >> > > >> > just a heads-up (pun intended...) > >> > > >> > (After updating to TOT, boot and configure with a freshly installed > >> > TOT ghc as bootstrap compiler. Then 'make clean'.) > >> > > >> > Running 'make' gives: > >> > > >> > ... > >> > Creating includes/ghcplatform.h... > >> > Done. > >> > "rm" -f utils/hsc2hs/dist/build/.depend.haskell.tmp > >> > "/home/ggreif/bin/ghc" -M -static -H64m -O0 -fasm -package-db > >> > libraries/bootstrapping.conf -hide-all-packages -i -iutils/hsc2hs/. > >> > -iutils/hsc2hs/dist/build -iutils/hsc2hs/dist/build/autogen > >> > -Iutils/hsc2hs/dist/build -Iutils/hsc2hs/dist/build/autogen > >> > -optP-include -optPutils/hsc2hs/dist/build/autogen/cabal_macros.h > >> > -package-id base-4.8.2.0 -package-id containers-0.5.6.2 -package-id > >> > directory-1.2.2.0 -package-id filepath-1.4.0.0 -package-id > >> > process-1.2.3.0 -XHaskell2010 -no-user-package-db -rtsopts -odir > >> > utils/hsc2hs/dist/build -hidir utils/hsc2hs/dist/build -stubdir > >> > utils/hsc2hs/dist/build -dep-makefile > >> > utils/hsc2hs/dist/build/.depend.haskell.tmp -dep-suffix "" > >> > -include-pkg-deps utils/hsc2hs/./Main.hs utils/hsc2hs/./C.hs > >> > utils/hsc2hs/./Common.hs utils/hsc2hs/./CrossCodegen.hs > >> > utils/hsc2hs/./DirectCodegen.hs utils/hsc2hs/./Flags.hs > >> > utils/hsc2hs/./HSCParser.hs utils/hsc2hs/./UtilsCodegen.hs > >> > : package db: duplicate packages with incompatible ABIs: > >> > binary-0.7.5.0 has ABIs: , c28f822c21e75eb270eca0870e42aaac > >> > Cabal-1.23.0.0 has ABIs: , a0a6af8f1dd909f2ee719ddb2cd65779 > >> > hpc-0.6.0.2 has ABIs: , 3434375974d4bc6d14952a90ec97d0c4 > >> > ghc-boot-0.0.0.0 has ABIs: , f422fc19421064f81c42815f25a11e6e > >> > hoopl-3.10.0.2 has ABIs: , 8968e2731ff8d529c37c048d65e94bf2 > >> > transformers-0.4.3.0 has ABIs: , 812457c97c58693d7f8a813b1ba19a33 > >> > template-haskell-2.11.0.0 has ABIs: , > >> > 0ef51476100e9bdf96d1bf59696b98a1 > >> > terminfo-0.4.0.1 has ABIs: , aa24f544c0e3614d419e63fa170ac467 > >> > > >> > > >> > The only solution I could come up for now is > >> > > >> > cd libraries > >> > ln -s /home/ggreif/lib/ghc-7.11.20151020/package.conf.d > >> > bootstrapping.conf > >> > > >> > then resuming 'make' leads to success. > >> > > >> > What could this be? Has somebody seen such an error? > >> > > >> > Cheers and thanks, > >> > > >> > Gabor > > From ezyang at mit.edu Thu Oct 22 20:53:00 2015 From: ezyang at mit.edu (Edward Z. Yang) Date: Thu, 22 Oct 2015 13:53:00 -0700 Subject: Building HEAD with HEAD fails In-Reply-To: <1445544161-sup-2885@sabre> References: <1445453019-sup-6313@sabre> <1445493115-sup-7306@sabre> <1445544161-sup-2885@sabre> Message-ID: <1445547170-sup-8026@sabre> Phab here: https://phabricator.haskell.org/D1355 Excerpts from Edward Z. Yang's message of 2015-10-22 13:09:25 -0700: > Scratch that, I managed to reproduced. (As you said, it occurs only when > you do the bindist.) I'll debug. > > Edward > > Excerpts from Gabor Greif's message of 2015-10-21 23:47:37 -0700: > > I did not use an inplace-stage2 but had a 'make install' before and > > did a boot/reconfigure. > > > > Not sure whether this detail is relevant. > > > > How can I debug this problem? What does the error message say precisely? > > > > Cheers, > > > > Gabor > > > > On 10/22/15, Edward Z. Yang wrote: > > > So... I can't reproduce this. I validated a copy of GHC HEAD, > > > and then used the inplace ghc-stage2 to build another using > > > ./configure --with-ghc=... and it built fine. > > > > > > Maybe, do you have some more details? > > > > > > Edward > > > > > > Excerpts from Edward Z. Yang's message of 2015-10-21 11:44:26 -0700: > > >> This is likely my fault, w.r.t. to the recent Cabal submodule update. > > >> I'm a bit confused why there are things in the DB that don't have ABI > > >> hashes though... > > >> > > >> Edward > > >> > > >> Excerpts from Gabor Greif's message of 2015-10-21 03:51:02 -0700: > > >> > Hi devs, > > >> > > > >> > just a heads-up (pun intended...) > > >> > > > >> > (After updating to TOT, boot and configure with a freshly installed > > >> > TOT ghc as bootstrap compiler. Then 'make clean'.) > > >> > > > >> > Running 'make' gives: > > >> > > > >> > ... > > >> > Creating includes/ghcplatform.h... > > >> > Done. > > >> > "rm" -f utils/hsc2hs/dist/build/.depend.haskell.tmp > > >> > "/home/ggreif/bin/ghc" -M -static -H64m -O0 -fasm -package-db > > >> > libraries/bootstrapping.conf -hide-all-packages -i -iutils/hsc2hs/. > > >> > -iutils/hsc2hs/dist/build -iutils/hsc2hs/dist/build/autogen > > >> > -Iutils/hsc2hs/dist/build -Iutils/hsc2hs/dist/build/autogen > > >> > -optP-include -optPutils/hsc2hs/dist/build/autogen/cabal_macros.h > > >> > -package-id base-4.8.2.0 -package-id containers-0.5.6.2 -package-id > > >> > directory-1.2.2.0 -package-id filepath-1.4.0.0 -package-id > > >> > process-1.2.3.0 -XHaskell2010 -no-user-package-db -rtsopts -odir > > >> > utils/hsc2hs/dist/build -hidir utils/hsc2hs/dist/build -stubdir > > >> > utils/hsc2hs/dist/build -dep-makefile > > >> > utils/hsc2hs/dist/build/.depend.haskell.tmp -dep-suffix "" > > >> > -include-pkg-deps utils/hsc2hs/./Main.hs utils/hsc2hs/./C.hs > > >> > utils/hsc2hs/./Common.hs utils/hsc2hs/./CrossCodegen.hs > > >> > utils/hsc2hs/./DirectCodegen.hs utils/hsc2hs/./Flags.hs > > >> > utils/hsc2hs/./HSCParser.hs utils/hsc2hs/./UtilsCodegen.hs > > >> > : package db: duplicate packages with incompatible ABIs: > > >> > binary-0.7.5.0 has ABIs: , c28f822c21e75eb270eca0870e42aaac > > >> > Cabal-1.23.0.0 has ABIs: , a0a6af8f1dd909f2ee719ddb2cd65779 > > >> > hpc-0.6.0.2 has ABIs: , 3434375974d4bc6d14952a90ec97d0c4 > > >> > ghc-boot-0.0.0.0 has ABIs: , f422fc19421064f81c42815f25a11e6e > > >> > hoopl-3.10.0.2 has ABIs: , 8968e2731ff8d529c37c048d65e94bf2 > > >> > transformers-0.4.3.0 has ABIs: , 812457c97c58693d7f8a813b1ba19a33 > > >> > template-haskell-2.11.0.0 has ABIs: , > > >> > 0ef51476100e9bdf96d1bf59696b98a1 > > >> > terminfo-0.4.0.1 has ABIs: , aa24f544c0e3614d419e63fa170ac467 > > >> > > > >> > > > >> > The only solution I could come up for now is > > >> > > > >> > cd libraries > > >> > ln -s /home/ggreif/lib/ghc-7.11.20151020/package.conf.d > > >> > bootstrapping.conf > > >> > > > >> > then resuming 'make' leads to success. > > >> > > > >> > What could this be? Has somebody seen such an error? > > >> > > > >> > Cheers and thanks, > > >> > > > >> > Gabor > > > From chak at justtesting.org Thu Oct 22 23:15:45 2015 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Fri, 23 Oct 2015 10:15:45 +1100 Subject: Context for typed holes In-Reply-To: References: Message-ID: <9A0593E6-37D4-45B5-BCD5-4B350AA1729C@justtesting.org> I think, this is a good point. Maybe you should make a ticket for it. Manuel > David Feuer : > > Unless something has changed really recently that I've missed, the typed holes messages are missing some really important information: instance information for types in scope. When I am trying to fill in a hole, I look to the "relevant bindings" to show me what pieces I have available to use. Those pieces don't include contexts! Is there something fundamentally hard about adding this information? I'd only want instance information for type variables--providing it for concrete types would make too much noise. I'd also want information on equality constraints, of course. > > _______________________________________________ > 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 andres.loeh at gmail.com Fri Oct 23 05:28:46 2015 From: andres.loeh at gmail.com (=?UTF-8?Q?Andres_L=C3=B6h?=) Date: Fri, 23 Oct 2015 07:28:46 +0200 Subject: Context for typed holes In-Reply-To: <9A0593E6-37D4-45B5-BCD5-4B350AA1729C@justtesting.org> References: <9A0593E6-37D4-45B5-BCD5-4B350AA1729C@justtesting.org> Message-ID: Hi. On Oct 23, 2015 01:15, "Manuel M T Chakravarty" wrote: > > I think, this is a good point. Maybe you should make a ticket for it. #9479, I think. Cheers, Andres >> David Feuer : >> >> Unless something has changed really recently that I've missed, the typed holes messages are missing some really important information: instance information for types in scope. When I am trying to fill in a hole, I look to the "relevant bindings" to show me what pieces I have available to use. Those pieces don't include contexts! Is there something fundamentally hard about adding this information? I'd only want instance information for type variables--providing it for concrete types would make too much noise. I'd also want information on equality constraints, of course. >> >> _______________________________________________ >> 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 cma at bitemyapp.com Fri Oct 23 05:35:30 2015 From: cma at bitemyapp.com (Christopher Allen) Date: Fri, 23 Oct 2015 00:35:30 -0500 Subject: Context for typed holes In-Reply-To: References: Message-ID: It's not just you. That's why I didn't mention holes in the book as people suggested. It's not just confusing for new people - it drives me nuts every time I use a hole in non-trivial code at work. On Thu, Oct 8, 2015 at 6:25 PM, David Feuer wrote: > Unless something has changed really recently that I've missed, the typed > holes messages are missing some really important information: instance > information for types in scope. When I am trying to fill in a hole, I look > to the "relevant bindings" to show me what pieces I have available to use. > Those pieces don't include contexts! Is there something fundamentally hard > about adding this information? I'd only want instance information for type > variables--providing it for concrete types would make too much noise. I'd > also want information on equality constraints, of course. > > _______________________________________________ > 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 david.feuer at gmail.com Fri Oct 23 05:48:49 2015 From: david.feuer at gmail.com (David Feuer) Date: Fri, 23 Oct 2015 01:48:49 -0400 Subject: Context for typed holes In-Reply-To: References: <9A0593E6-37D4-45B5-BCD5-4B350AA1729C@justtesting.org> Message-ID: I opened https://ghc.haskell.org/trac/ghc/ticket/10954 for this. #9479, by Dominique Devriese, is complementary--she wants instance information for a *hole* with an ambiguous type. On Oct 23, 2015 1:28 AM, "Andres L?h" wrote: > Hi. > > On Oct 23, 2015 01:15, "Manuel M T Chakravarty" > wrote: > > > > I think, this is a good point. Maybe you should make a ticket for it. > > #9479, I think. > > Cheers, > Andres > > >> David Feuer : > >> > >> Unless something has changed really recently that I've missed, the > typed holes messages are missing some really important information: > instance information for types in scope. When I am trying to fill in a > hole, I look to the "relevant bindings" to show me what pieces I have > available to use. Those pieces don't include contexts! Is there something > fundamentally hard about adding this information? I'd only want instance > information for type variables--providing it for concrete types would make > too much noise. I'd also want information on equality constraints, of > course. > >> > >> _______________________________________________ > >> 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 andres.loeh at gmail.com Fri Oct 23 05:55:05 2015 From: andres.loeh at gmail.com (=?UTF-8?Q?Andres_L=C3=B6h?=) Date: Fri, 23 Oct 2015 07:55:05 +0200 Subject: Context for typed holes In-Reply-To: References: <9A0593E6-37D4-45B5-BCD5-4B350AA1729C@justtesting.org> Message-ID: Actually, #9091 was the one I was really looking for ... reported by me. See also the discussion about "given" vs. "wanted" constraints. Cheers, Andres On Fri, Oct 23, 2015 at 7:48 AM, David Feuer wrote: > I opened https://ghc.haskell.org/trac/ghc/ticket/10954 for this. #9479, by > Dominique Devriese, is complementary--she wants instance information for a > *hole* with an ambiguous type. > > On Oct 23, 2015 1:28 AM, "Andres L?h" wrote: >> >> Hi. >> >> On Oct 23, 2015 01:15, "Manuel M T Chakravarty" >> wrote: >> > >> > I think, this is a good point. Maybe you should make a ticket for it. >> >> #9479, I think. >> >> Cheers, >> Andres >> >> >> David Feuer : >> >> >> >> Unless something has changed really recently that I've missed, the >> >> typed holes messages are missing some really important information: instance >> >> information for types in scope. When I am trying to fill in a hole, I look >> >> to the "relevant bindings" to show me what pieces I have available to use. >> >> Those pieces don't include contexts! Is there something fundamentally hard >> >> about adding this information? I'd only want instance information for type >> >> variables--providing it for concrete types would make too much noise. I'd >> >> also want information on equality constraints, of course. >> >> >> >> _______________________________________________ >> >> 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 david.feuer at gmail.com Fri Oct 23 05:59:56 2015 From: david.feuer at gmail.com (David Feuer) Date: Fri, 23 Oct 2015 01:59:56 -0400 Subject: Context for typed holes In-Reply-To: References: <9A0593E6-37D4-45B5-BCD5-4B350AA1729C@justtesting.org> Message-ID: I just closed mine as a duplicate of yours. On Oct 23, 2015 1:55 AM, "Andres L?h" wrote: > Actually, #9091 was the one I was really looking for ... reported by > me. See also the discussion about "given" vs. "wanted" constraints. > > Cheers, > Andres > > On Fri, Oct 23, 2015 at 7:48 AM, David Feuer > wrote: > > I opened https://ghc.haskell.org/trac/ghc/ticket/10954 for this. #9479, > by > > Dominique Devriese, is complementary--she wants instance information for > a > > *hole* with an ambiguous type. > > > > On Oct 23, 2015 1:28 AM, "Andres L?h" wrote: > >> > >> Hi. > >> > >> On Oct 23, 2015 01:15, "Manuel M T Chakravarty" > >> wrote: > >> > > >> > I think, this is a good point. Maybe you should make a ticket for it. > >> > >> #9479, I think. > >> > >> Cheers, > >> Andres > >> > >> >> David Feuer : > >> >> > >> >> Unless something has changed really recently that I've missed, the > >> >> typed holes messages are missing some really important information: > instance > >> >> information for types in scope. When I am trying to fill in a hole, > I look > >> >> to the "relevant bindings" to show me what pieces I have available > to use. > >> >> Those pieces don't include contexts! Is there something > fundamentally hard > >> >> about adding this information? I'd only want instance information > for type > >> >> variables--providing it for concrete types would make too much > noise. I'd > >> >> also want information on equality constraints, of course. > >> >> > >> >> _______________________________________________ > >> >> 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 Fri Oct 23 07:22:23 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 23 Oct 2015 07:22:23 +0000 Subject: Context for typed holes In-Reply-To: <9A0593E6-37D4-45B5-BCD5-4B350AA1729C@justtesting.org> References: <9A0593E6-37D4-45B5-BCD5-4B350AA1729C@justtesting.org> Message-ID: Indeed. Please also do give concrete examples, so that we all talk about the same proposal. Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Manuel M T Chakravarty Sent: 23 October 2015 00:16 To: David Feuer Cc: ghc-devs Subject: Re: Context for typed holes I think, this is a good point. Maybe you should make a ticket for it. Manuel David Feuer >: Unless something has changed really recently that I've missed, the typed holes messages are missing some really important information: instance information for types in scope. When I am trying to fill in a hole, I look to the "relevant bindings" to show me what pieces I have available to use. Those pieces don't include contexts! Is there something fundamentally hard about adding this information? I'd only want instance information for type variables--providing it for concrete types would make too much noise. I'd also want information on equality constraints, of course. _______________________________________________ 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 rrnewton at gmail.com Fri Oct 23 13:53:44 2015 From: rrnewton at gmail.com (Ryan Newton) Date: Fri, 23 Oct 2015 09:53:44 -0400 Subject: Better calling conventions for strict functions (bang patterns)? Message-ID: Hi all, With module-level Strict and StrictData pragmas coming soon, one obvious question is what kind of the code quality GHC can achieve for strict programs. When it came up in discussion in our research group we realized we didn't actually know whether the bang patterns, `f !x`, on function arguments were enforced by caller or callee. Here's a Gist that shows the compilation of a trivial function: foo :: Maybe Int -> Intfoo !x = case x of Just y -> y https://gist.github.com/rrnewton/1ac722189c65f26fe9ac If that function is compiled to *assume* its input is in WHNF, it should be just as efficient as the isomorphic MLton/OCaml code, right? It only needs to branch on the tag, do a field dereference, and return. But as you can see from the STG and CMM generated, foo *does indeed* enter the thunk, adding an extra indirect jump. Here's the body: c3aY: if ((Sp + -8) < SpLim) goto c3aZ; else goto c3b0; c3aZ: // nop R1 = PicBaseReg + foo_closure; call (I64[BaseReg - 8])(R2, R1) args: 8, res: 0, upd: 8; c3b0: I64[Sp - 8] = PicBaseReg + block_c3aO_info; R1 = R2; Sp = Sp - 8; if (R1 & 7 != 0) goto c3aO; else goto c3aP; c3aP: call (I64[R1])(R1) returns to c3aO, args: 8, res: 8, upd: 8; c3aO: if (R1 & 7 >= 2) goto c3aW; else goto c3aX; c3aW: R1 = P64[R1 + 6] & (-8); Sp = Sp + 8; call (I64[R1])(R1) args: 8, res: 0, upd: 8; c3aX: R1 = PicBaseReg + lvl_r39S_closure; Sp = Sp + 8; call (I64[R1])(R1) args: 8, res: 0, upd: 8; The call inside c3aP is entering "x" as a thunk, which also incurs all of the stack limit check code. I believe that IF the input could be assumed to be in WHNF, everything above the label "c3aO" could be omitted. So... if GHC is going to be a fabulous pure *and* imperative language, and a fabulous lazy *and* strict compiler/runtime.. is there some work we can do here to improve this situation? Would the following make sense: - Put together a benchmark suite of all-strict programs with Strict/StrictData (compare a few benchmark's generated code to MLton, if time allows) - Modify GHC to change calling conventions for bang patterns -- caller enforces WHNF rather than callee. Existing strictness/demand/cardinality analysis would stay the same. Unless there's something I'm really missing here, the result should be that you can have a whole chain of strict function calls, each of which knows its arguments and the arguments it passes to its callees are all in WHNF, without ever generating thunk-entry sequences. Thanks for your time, -Ryan -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Fri Oct 23 14:11:12 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 23 Oct 2015 14:11:12 +0000 Subject: Better calling conventions for strict functions (bang patterns)? In-Reply-To: References: Message-ID: It?s absolutely the case that bang patterns etc tell the caller what to do, but the function CANNOT ASSUME that its argument is evaluated. Reason: higher order functions. I think that the way to allow functions that can assume their arg is evaluated is through types: see Type are calling conventions. But it?d be a fairly big deal to implement. Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Ryan Newton Sent: 23 October 2015 14:54 To: ghc-devs at haskell.org; ?mer Sinan A?acan; Ryan Scott; Chao-Hong Chen; Johan Tibell Subject: Better calling conventions for strict functions (bang patterns)? Hi all, With module-level Strict and StrictData pragmas coming soon, one obvious question is what kind of the code quality GHC can achieve for strict programs. When it came up in discussion in our research group we realized we didn't actually know whether the bang patterns, `f !x`, on function arguments were enforced by caller or callee. Here's a Gist that shows the compilation of a trivial function: foo :: Maybe Int -> Int foo !x = case x of Just y -> y https://gist.github.com/rrnewton/1ac722189c65f26fe9ac If that function is compiled to *assume* its input is in WHNF, it should be just as efficient as the isomorphic MLton/OCaml code, right? It only needs to branch on the tag, do a field dereference, and return. But as you can see from the STG and CMM generated, foo does indeed enter the thunk, adding an extra indirect jump. Here's the body: c3aY: if ((Sp + -8) < SpLim) goto c3aZ; else goto c3b0; c3aZ: // nop R1 = PicBaseReg + foo_closure; call (I64[BaseReg - 8])(R2, R1) args: 8, res: 0, upd: 8; c3b0: I64[Sp - 8] = PicBaseReg + block_c3aO_info; R1 = R2; Sp = Sp - 8; if (R1 & 7 != 0) goto c3aO; else goto c3aP; c3aP: call (I64[R1])(R1) returns to c3aO, args: 8, res: 8, upd: 8; c3aO: if (R1 & 7 >= 2) goto c3aW; else goto c3aX; c3aW: R1 = P64[R1 + 6] & (-8); Sp = Sp + 8; call (I64[R1])(R1) args: 8, res: 0, upd: 8; c3aX: R1 = PicBaseReg + lvl_r39S_closure; Sp = Sp + 8; call (I64[R1])(R1) args: 8, res: 0, upd: 8; The call inside c3aP is entering "x" as a thunk, which also incurs all of the stack limit check code. I believe that IF the input could be assumed to be in WHNF, everything above the label "c3aO" could be omitted. So... if GHC is going to be a fabulous pure and imperative language, and a fabulous lazy and strict compiler/runtime.. is there some work we can do here to improve this situation? Would the following make sense: * Put together a benchmark suite of all-strict programs with Strict/StrictData (compare a few benchmark's generated code to MLton, if time allows) * Modify GHC to change calling conventions for bang patterns -- caller enforces WHNF rather than callee. Existing strictness/demand/cardinality analysis would stay the same. Unless there's something I'm really missing here, the result should be that you can have a whole chain of strict function calls, each of which knows its arguments and the arguments it passes to its callees are all in WHNF, without ever generating thunk-entry sequences. Thanks for your time, -Ryan -------------- next part -------------- An HTML attachment was scrubbed... URL: From rrnewton at gmail.com Fri Oct 23 18:31:03 2015 From: rrnewton at gmail.com (Ryan Newton) Date: Fri, 23 Oct 2015 14:31:03 -0400 Subject: Better calling conventions for strict functions (bang patterns)? In-Reply-To: References: Message-ID: Ah, yes, so just to give a concrete example in this thread, if we take the `foo` function above and say `map foo ls`, we may well get unevaluated arguments to foo. (And this is almost precisely the same as the first example that Strict-Core paper!) Thanks for the paper reference. I read it and it's great -- just what I was looking for. An approach that eliminates any jealousy of ML/Scheme compiler techniques vis a vis calling conventions ;-). I'm also wondering if there are some incremental steps that can be taken, short of what is proposed in the paper. 1. Small tweaks: The CMM code above seems to be *betting* than the thunk is unevaluated, because it does the stack check and stack write *before* the predicate test that checks if the thunk is evaluated (if (R1 & 7 != 0) goto c3aO; else goto c3aP;). With a bang-pattern function, couldn't it make the opposite bet? That is, branch on whether the thunk is evaluated first, and then the wasted computation is only a single correctly predicted branch (and a read of a tag that we need to read anyway). 2. The option of multiple entrypoints which is considered and discarded as fragile in the beginning of the paper (for direct call vs indirect / 1st order vs higher order). That fragile option is along the lines of what I wanted to discuss on this thread. It does seem like a tricky phase ordering concern, but how bad is it exactly? The conflict with the a case-expr rewrite is illustrated clearly in the paper, but that just means that such optimizations must happen *before *the final choice of which function entrypoint to call, doesn't it? I'm not 100% sure where it could go in the current compiler pipeline, but couldn't the adjustment of call target from "foo" to "foo_with_known_whnf_args" happen quite late? Cheers, -Ryan P.S. One of the students CC'd, Ryan Scott, is currently on internship at Intel labs and is working to (hopefully) liberate the Intell Haskell Research Compiler as open source. Like the 2009 paper, it also uses a strict IR, and I think it will be interesting to see exactly how it handles the conversion from Core to its IR. (Probably the same as Fig 10 in the paper.) On Fri, Oct 23, 2015 at 10:11 AM, Simon Peyton Jones wrote: > It?s absolutely the case that bang patterns etc tell the caller what to > do, but the function CANNOT ASSUME that its argument is evaluated. Reason: > higher order functions. > > > > I think that the way to allow functions that can assume their arg is > evaluated is through types: see Type are calling conventions > . > But it?d be a fairly big deal to implement. > > > > Simon > > > > > > *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Ryan > Newton > *Sent:* 23 October 2015 14:54 > *To:* ghc-devs at haskell.org; ?mer Sinan A?acan; Ryan Scott; Chao-Hong > Chen; Johan Tibell > *Subject:* Better calling conventions for strict functions (bang > patterns)? > > > > Hi all, > > > > With module-level Strict and StrictData pragmas coming soon, one obvious > question is what kind of the code quality GHC can achieve for strict > programs. > > > > When it came up in discussion in our research group we realized we didn't > actually know whether the bang patterns, `f !x`, on function arguments were > enforced by caller or callee. > > > > Here's a Gist that shows the compilation of a trivial function: > > foo :: Maybe Int -> Int > > foo !x = > > case x of > > Just y -> y > > > > https://gist.github.com/rrnewton/1ac722189c65f26fe9ac > > > > > If that function is compiled to *assume* its input is in WHNF, it should > be just as efficient as the isomorphic MLton/OCaml code, right? It only > needs to branch on the tag, do a field dereference, and return. > > > > But as you can see from the STG and CMM generated, foo *does indeed* > enter the thunk, adding an extra indirect jump. Here's the body: > > c3aY: > > if ((Sp + -8) < SpLim) goto c3aZ; else goto c3b0; > > c3aZ: > > // nop > > R1 = PicBaseReg + foo_closure; > > call (I64[BaseReg - 8])(R2, R1) args: 8, res: 0, upd: 8; > > c3b0: > > I64[Sp - 8] = PicBaseReg + block_c3aO_info; > > R1 = R2; > > Sp = Sp - 8; > > if (R1 & 7 != 0) goto c3aO; else goto c3aP; > > c3aP: > > call (I64[R1])(R1) returns to c3aO, args: 8, res: 8, upd: 8; > > c3aO: > > if (R1 & 7 >= 2) goto c3aW; else goto c3aX; > > c3aW: > > R1 = P64[R1 + 6] & (-8); > > Sp = Sp + 8; > > call (I64[R1])(R1) args: 8, res: 0, upd: 8; > > c3aX: > > R1 = PicBaseReg + lvl_r39S_closure; > > Sp = Sp + 8; > > call (I64[R1])(R1) args: 8, res: 0, upd: 8; > > > > > > The call inside c3aP is entering "x" as a thunk, which also incurs all of > the stack limit check code. I believe that IF the input could be assumed > to be in WHNF, everything above the label "c3aO" could be omitted. > > > > So... if GHC is going to be a fabulous pure *and* imperative language, > and a fabulous lazy *and* strict compiler/runtime.. is there some work we > can do here to improve this situation? Would the following make sense: > > - Put together a benchmark suite of all-strict programs with > Strict/StrictData (compare a few benchmark's generated code to MLton, if > time allows) > - Modify GHC to change calling conventions for bang patterns -- caller > enforces WHNF rather than callee. Existing strictness/demand/cardinality > analysis would stay the same. > > Unless there's something I'm really missing here, the result should be > that you can have a whole chain of strict function calls, each of which > knows its arguments and the arguments it passes to its callees are all in > WHNF, without ever generating thunk-entry sequences. > > > > Thanks for your time, > > -Ryan > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rrnewton at gmail.com Sat Oct 24 02:00:44 2015 From: rrnewton at gmail.com (Ryan Newton) Date: Fri, 23 Oct 2015 22:00:44 -0400 Subject: Better calling conventions for strict functions (bang patterns)? In-Reply-To: References: Message-ID: > > > 1. Small tweaks: The CMM code above seems to be *betting* than the > thunk is unevaluated, because it does the stack check and stack write > *before* the predicate test that checks if the thunk is evaluated (if > (R1 & 7 != 0) goto c3aO; else goto c3aP;). With a bang-pattern > function, couldn't it make the opposite bet? That is, branch on whether > the thunk is evaluated first, and then the wasted computation is only a > single correctly predicted branch (and a read of a tag that we need to read > anyway). > > Oh, a small further addition would be needed for this tweak. In the generated code above "Sp = Sp + 8;" happens *late*, but I think it could happen right after the call to the thunk. In general, does it seem feasible to separate the slowpath from fastpath as in the following tweak of the example CMM? * // Skip to the chase if it's already evaluated:* * start:* * if (R2 & 7 != 0) goto fastpath; else goto slowpath;* * slowpath: // Formerly c3aY* * if ((Sp + -8) < SpLim) goto c3aZ; else goto c3b0;* * c3aZ:* * // nop* * R1 = PicBaseReg + foo_closure;* * call (I64[BaseReg - 8])(R2, R1) args: 8, res: 0, upd: 8;* * c3b0:* * I64[Sp - 8] = PicBaseReg + block_c3aO_info;* * R1 = R2;* * Sp = Sp - 8;* * call (I64[R1])(R1) returns to fastpath, args: 8, res: 8, upd: 8;* * // Sp bump moved to here so it's separate from "fastpath"* * Sp = Sp + 8;* * fastpath: // Formerly c3aO* * if (R1 & 7 >= 2) goto c3aW; else goto c3aX;* * c3aW:* * R1 = P64[R1 + 6] & (-8);* * call (I64[R1])(R1) args: 8, res: 0, upd: 8;* * c3aX:* * R1 = PicBaseReg + lvl_r39S_closure;* * call (I64[R1])(R1) args: 8, res: 0, upd: 8;* -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggreif at gmail.com Sat Oct 24 14:28:49 2015 From: ggreif at gmail.com (Gabor Greif) Date: Sat, 24 Oct 2015 16:28:49 +0200 Subject: Building HEAD with HEAD fails In-Reply-To: <1445547170-sup-8026@sabre> References: <1445453019-sup-6313@sabre> <1445493115-sup-7306@sabre> <1445544161-sup-2885@sabre> <1445547170-sup-8026@sabre> Message-ID: Hi Edward, I commented in the phab. Btw., this looks like a copy-paste error: git show 6338a1cc commit 6338a1cc6df2c7fd8a62eeb4c5240dd90ee74a6c Author: Edward Z. Yang Date: Sun Oct 11 13:41:20 2015 -0700 Rename PACKAGE_KEY and LIB_NAME in build system. Signed-off-by: Edward Z. Yang diff --git a/compiler/ghc.mk b/compiler/ghc.mk index 8172ca6..fc9e891 100644 --- a/compiler/ghc.mk +++ b/compiler/ghc.mk @@ -441,11 +441,11 @@ ifeq "$(compiler_stage1_VERSION_MUNGED)" "YES" compiler_stage1_MUNGED_VERSION = $(subst .$(ProjectPatchLevel),,$(ProjectVersion)) define compiler_PACKAGE_MAGIC compiler_stage1_VERSION = $(compiler_stage1_MUNGED_VERSION) -compiler_stage1_PACKAGE_KEY = $(subst .$(ProjectPatchLevel),,$(compiler_stage1_PACKAGE_KEY)) -compiler_stage1_LIB_NAME = $(subst .$(ProjectPatchLevel),,$(compiler_stage1_LIB_NAME)) +compiler_stage1_COMPONENT_ID = $(subst .$(ProjectPatchLevel),,$(compiler_stage1_COMPONENT_ID)) +compiler_stage1_COMPONENT_ID = $(subst .$(ProjectPatchLevel),,$(compiler_stage1_COMPONENT_ID)) endef Cheers, Gabor On 10/22/15, Edward Z. Yang wrote: > Phab here: https://phabricator.haskell.org/D1355 > > Excerpts from Edward Z. Yang's message of 2015-10-22 13:09:25 -0700: >> Scratch that, I managed to reproduced. (As you said, it occurs only when >> you do the bindist.) I'll debug. >> >> Edward >> >> Excerpts from Gabor Greif's message of 2015-10-21 23:47:37 -0700: >> > I did not use an inplace-stage2 but had a 'make install' before and >> > did a boot/reconfigure. >> > >> > Not sure whether this detail is relevant. >> > >> > How can I debug this problem? What does the error message say >> > precisely? >> > >> > Cheers, >> > >> > Gabor >> > >> > On 10/22/15, Edward Z. Yang wrote: >> > > So... I can't reproduce this. I validated a copy of GHC HEAD, >> > > and then used the inplace ghc-stage2 to build another using >> > > ./configure --with-ghc=... and it built fine. >> > > >> > > Maybe, do you have some more details? >> > > >> > > Edward >> > > >> > > Excerpts from Edward Z. Yang's message of 2015-10-21 11:44:26 -0700: >> > >> This is likely my fault, w.r.t. to the recent Cabal submodule >> > >> update. >> > >> I'm a bit confused why there are things in the DB that don't have >> > >> ABI >> > >> hashes though... >> > >> >> > >> Edward >> > >> >> > >> Excerpts from Gabor Greif's message of 2015-10-21 03:51:02 -0700: >> > >> > Hi devs, >> > >> > >> > >> > just a heads-up (pun intended...) >> > >> > >> > >> > (After updating to TOT, boot and configure with a freshly >> > >> > installed >> > >> > TOT ghc as bootstrap compiler. Then 'make clean'.) >> > >> > >> > >> > Running 'make' gives: >> > >> > >> > >> > ... >> > >> > Creating includes/ghcplatform.h... >> > >> > Done. >> > >> > "rm" -f utils/hsc2hs/dist/build/.depend.haskell.tmp >> > >> > "/home/ggreif/bin/ghc" -M -static -H64m -O0 -fasm -package-db >> > >> > libraries/bootstrapping.conf -hide-all-packages -i >> > >> > -iutils/hsc2hs/. >> > >> > -iutils/hsc2hs/dist/build -iutils/hsc2hs/dist/build/autogen >> > >> > -Iutils/hsc2hs/dist/build -Iutils/hsc2hs/dist/build/autogen >> > >> > -optP-include -optPutils/hsc2hs/dist/build/autogen/cabal_macros.h >> > >> > -package-id base-4.8.2.0 -package-id containers-0.5.6.2 >> > >> > -package-id >> > >> > directory-1.2.2.0 -package-id filepath-1.4.0.0 -package-id >> > >> > process-1.2.3.0 -XHaskell2010 -no-user-package-db -rtsopts >> > >> > -odir >> > >> > utils/hsc2hs/dist/build -hidir utils/hsc2hs/dist/build -stubdir >> > >> > utils/hsc2hs/dist/build -dep-makefile >> > >> > utils/hsc2hs/dist/build/.depend.haskell.tmp -dep-suffix "" >> > >> > -include-pkg-deps utils/hsc2hs/./Main.hs utils/hsc2hs/./C.hs >> > >> > utils/hsc2hs/./Common.hs utils/hsc2hs/./CrossCodegen.hs >> > >> > utils/hsc2hs/./DirectCodegen.hs utils/hsc2hs/./Flags.hs >> > >> > utils/hsc2hs/./HSCParser.hs utils/hsc2hs/./UtilsCodegen.hs >> > >> > : package db: duplicate packages with incompatible >> > >> > ABIs: >> > >> > binary-0.7.5.0 has ABIs: , c28f822c21e75eb270eca0870e42aaac >> > >> > Cabal-1.23.0.0 has ABIs: , a0a6af8f1dd909f2ee719ddb2cd65779 >> > >> > hpc-0.6.0.2 has ABIs: , 3434375974d4bc6d14952a90ec97d0c4 >> > >> > ghc-boot-0.0.0.0 has ABIs: , f422fc19421064f81c42815f25a11e6e >> > >> > hoopl-3.10.0.2 has ABIs: , 8968e2731ff8d529c37c048d65e94bf2 >> > >> > transformers-0.4.3.0 has ABIs: , >> > >> > 812457c97c58693d7f8a813b1ba19a33 >> > >> > template-haskell-2.11.0.0 has ABIs: , >> > >> > 0ef51476100e9bdf96d1bf59696b98a1 >> > >> > terminfo-0.4.0.1 has ABIs: , aa24f544c0e3614d419e63fa170ac467 >> > >> > >> > >> > >> > >> > The only solution I could come up for now is >> > >> > >> > >> > cd libraries >> > >> > ln -s /home/ggreif/lib/ghc-7.11.20151020/package.conf.d >> > >> > bootstrapping.conf >> > >> > >> > >> > then resuming 'make' leads to success. >> > >> > >> > >> > What could this be? Has somebody seen such an error? >> > >> > >> > >> > Cheers and thanks, >> > >> > >> > >> > Gabor >> > > > From carter.schonwald at gmail.com Sat Oct 24 20:53:38 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sat, 24 Oct 2015 16:53:38 -0400 Subject: Better calling conventions for strict functions (bang patterns)? In-Reply-To: References: Message-ID: Doesn't modern hardware have pretty good branch prediction? In which case the order of the branches may not matter unless it's a long chain of calls? Vs say an inner loop that hasn't been inlined? Either way, I'd love be stay in the loop on this topic, for work I'm building a strongly normalizing language that supports both strict and call by need evaluation strategies. On Friday, October 23, 2015, Ryan Newton wrote: > >> 1. Small tweaks: The CMM code above seems to be *betting* than the >> thunk is unevaluated, because it does the stack check and stack write >> *before* the predicate test that checks if the thunk is evaluated (if >> (R1 & 7 != 0) goto c3aO; else goto c3aP;). With a bang-pattern >> function, couldn't it make the opposite bet? That is, branch on whether >> the thunk is evaluated first, and then the wasted computation is only a >> single correctly predicted branch (and a read of a tag that we need to read >> anyway). >> >> Oh, a small further addition would be needed for this tweak. In the > generated code above "Sp = Sp + 8;" happens *late*, but I think it could > happen right after the call to the thunk. In general, does it seem > feasible to separate the slowpath from fastpath as in the following tweak > of the example CMM? > > > * // Skip to the chase if it's already evaluated:* > * start:* > * if (R2 & 7 != 0) goto fastpath; else goto slowpath;* > > * slowpath: // Formerly c3aY* > * if ((Sp + -8) < SpLim) goto c3aZ; else goto c3b0;* > * c3aZ:* > * // nop* > * R1 = PicBaseReg + foo_closure;* > * call (I64[BaseReg - 8])(R2, R1) args: 8, res: 0, upd: 8;* > * c3b0:* > * I64[Sp - 8] = PicBaseReg + block_c3aO_info;* > * R1 = R2;* > * Sp = Sp - 8;* > > * call (I64[R1])(R1) returns to fastpath, args: 8, res: 8, upd: 8;* > * // Sp bump moved to here so it's separate from "fastpath"* > * Sp = Sp + 8;* > > * fastpath: // Formerly c3aO* > * if (R1 & 7 >= 2) goto c3aW; else goto c3aX;* > * c3aW:* > * R1 = P64[R1 + 6] & (-8);* > * call (I64[R1])(R1) args: 8, res: 0, upd: 8;* > * c3aX:* > * R1 = PicBaseReg + lvl_r39S_closure;* > * call (I64[R1])(R1) args: 8, res: 0, upd: 8;* > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From takenobu.hs at gmail.com Sun Oct 25 08:09:29 2015 From: takenobu.hs at gmail.com (Takenobu Tani) Date: Sun, 25 Oct 2015 17:09:29 +0900 Subject: Better calling conventions for strict functions (bang patterns)? In-Reply-To: References: Message-ID: Hi, I'm interested in execution performance. Maybe modern hardware (which implement IA64, ARMv8) is able to predict a long chain of jumps [1]. But prediction accuracy for indirect jump is low, especially dynamic addressed indirect jumps. By the way, Ryan's example code will be fast by following optimization: (If c3aX is most fast path, c3aX is reached without taken-branch.) // Skip to the chase if it's already evaluated: start: // if (R2 & 7 != 0) goto fastpath; else goto slowpath; if (R2 & 7 == 0) goto slowpath; // *** (1) remove branch for fastpath fastpath: // Formerly c3aO // *** (1) move fastpath here // if (R1 & 7 >= 2) goto c3aW; else goto c3aX; if (R1 & 7 >= 2) goto c3aW; // *** (2) remove branch for prior path(c3aX) c3aX: // *** (2) move else path to here(without branch) R1 = PicBaseReg + lvl_r39S_closure; call (I64[R1])(R1) args: 8, res: 0, upd: 8; // *** indirect jump, but fixed address (100% hit) c3aW: R1 = P64[R1 + 6] & (-8); call (I64[R1])(R1) args: 8, res: 0, upd: 8; // *** indirect jump, dynamic address (hit or miss) //c3aX: // R1 = PicBaseReg + lvl_r39S_closure; // call (I64[R1])(R1) args: 8, res: 0, upd: 8; slowpath: // Formerly c3aY if ((Sp + -8) < SpLim) goto c3aZ; else goto c3b0; c3aZ: // nop R1 = PicBaseReg + foo_closure; call (I64[BaseReg - 8])(R2, R1) args: 8, res: 0, upd: 8; c3b0: I64[Sp - 8] = PicBaseReg + block_c3aO_info; R1 = R2; Sp = Sp - 8; call (I64[R1])(R1) returns to fastpath, args: 8, res: 8, upd: 8; // Sp bump moved to here so it's separate from "fastpath" Sp = Sp + 8; goto fastpath; // *** //fastpath: // Formerly c3aO // if (R1 & 7 >= 2) goto c3aW; else goto c3aX; //c3aW: // R1 = P64[R1 + 6] & (-8); // call (I64[R1])(R1) args: 8, res: 0, upd: 8; //c3aX: // R1 = PicBaseReg + lvl_r39S_closure; // call (I64[R1])(R1) args: 8, res: 0, upd: 8; [1]: Intel64 and IA-32 Architectures Optimization Reference Manual http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-optimization-manual.pdf 3.4 OPTIMIZING THE FRONT END 2.3.2.3 Branch Prediction I'm just studying and drawing about lazy evaluation. This thread is helpful to me :) Regards, Takenobu 2015-10-25 5:53 GMT+09:00 Carter Schonwald : > Doesn't modern hardware have pretty good branch prediction? In which case > the order of the branches may not matter unless it's a long chain of calls? > Vs say an inner loop that hasn't been inlined? > > Either way, I'd love be stay in the loop on this topic, for work I'm > building a strongly normalizing language that supports both strict and call > by need evaluation strategies. > > > On Friday, October 23, 2015, Ryan Newton wrote: > >> >>> 1. Small tweaks: The CMM code above seems to be *betting* than the >>> thunk is unevaluated, because it does the stack check and stack write >>> *before* the predicate test that checks if the thunk is evaluated (if >>> (R1 & 7 != 0) goto c3aO; else goto c3aP;). With a bang-pattern >>> function, couldn't it make the opposite bet? That is, branch on whether >>> the thunk is evaluated first, and then the wasted computation is only a >>> single correctly predicted branch (and a read of a tag that we need to read >>> anyway). >>> >>> Oh, a small further addition would be needed for this tweak. In the >> generated code above "Sp = Sp + 8;" happens *late*, but I think it could >> happen right after the call to the thunk. In general, does it seem >> feasible to separate the slowpath from fastpath as in the following tweak >> of the example CMM? >> >> >> * // Skip to the chase if it's already evaluated:* >> * start:* >> * if (R2 & 7 != 0) goto fastpath; else goto slowpath;* >> >> * slowpath: // Formerly c3aY* >> * if ((Sp + -8) < SpLim) goto c3aZ; else goto c3b0;* >> * c3aZ:* >> * // nop* >> * R1 = PicBaseReg + foo_closure;* >> * call (I64[BaseReg - 8])(R2, R1) args: 8, res: 0, upd: 8;* >> * c3b0:* >> * I64[Sp - 8] = PicBaseReg + block_c3aO_info;* >> * R1 = R2;* >> * Sp = Sp - 8;* >> >> * call (I64[R1])(R1) returns to fastpath, args: 8, res: 8, upd: 8;* >> * // Sp bump moved to here so it's separate from "fastpath"* >> * Sp = Sp + 8;* >> >> * fastpath: // Formerly c3aO* >> * if (R1 & 7 >= 2) goto c3aW; else goto c3aX;* >> * c3aW:* >> * R1 = P64[R1 + 6] & (-8);* >> * call (I64[R1])(R1) args: 8, res: 0, upd: 8;* >> * c3aX:* >> * R1 = PicBaseReg + lvl_r39S_closure;* >> * call (I64[R1])(R1) args: 8, res: 0, upd: 8;* >> >> >> >> > _______________________________________________ > 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 Mon Oct 26 07:59:26 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 26 Oct 2015 07:59:26 +0000 Subject: Sphinx on Windows Message-ID: The GHC wiki says you need Sphinx to build docs, https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Tools and refers to the Preparation doc for how to install Sphinx https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation But the Windows sub-page of Preparation does not say how to install Sphinx. Question: how does one install Sphinx on Windows? The sphinx-doc home page mutters about 'pip', but I've never used that. Does anyone have instructions? Thanks Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvriedel at gmail.com Mon Oct 26 08:27:18 2015 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Mon, 26 Oct 2015 09:27:18 +0100 Subject: Sphinx on Windows In-Reply-To: (Simon Peyton Jones's message of "Mon, 26 Oct 2015 07:59:26 +0000") References: Message-ID: <87h9le2fx5.fsf@gmail.com> Hi, On 2015-10-26 at 08:59:26 +0100, Simon Peyton Jones wrote: > The GHC wiki says you need Sphinx to build docs, > https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Tools > and refers to the Preparation doc for how to install Sphinx > https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation > But the Windows sub-page of Preparation does not say how to install Sphinx. > Question: how does one install Sphinx on Windows? The sphinx-doc home > page mutters about 'pip', but I've never used that. Does anyone have > instructions? Have you tried following the instructions on http://sphinx-doc.org/latest/install.html#windows-install-python-and-sphinx ? If those instructions work, I guess we should link there... Cheers, hvr From kane at kane.cx Mon Oct 26 08:32:17 2015 From: kane at kane.cx (David Kraeutmann) Date: Mon, 26 Oct 2015 09:32:17 +0100 Subject: Sphinx on Windows In-Reply-To: References: Message-ID: 'pip' is just a Python package manager. Following the steps at http://sphinx-doc.org/latest/install.html#windows-install-python-and-sphinx should give you a working sphinx install. I can test those on my Windows machine once I'm home, but that won't be for a few hours. On Mon, Oct 26, 2015 at 8:59 AM, Simon Peyton Jones wrote: > The GHC wiki says you need Sphinx to build docs, > > https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Tools > > and refers to the Preparation doc for how to install Sphinx > > https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation > > But the Windows sub-page of Preparation does not say how to install Sphinx. > > Question: how does one install Sphinx on Windows? The sphinx-doc home page > mutters about ?pip?, but I?ve never used that. Does anyone have > instructions? > > Thanks > > Simon > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From simonpj at microsoft.com Mon Oct 26 09:41:39 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 26 Oct 2015 09:41:39 +0000 Subject: Sphinx on Windows In-Reply-To: References: Message-ID: <7e3970cc66724d7a92e0fa3f26ed3bc5@DB4PR30MB030.064d.mgd.msft.net> I have not tried that. But 'pip' gives "command not found". Maybe I need something in my path? I appear to have python 2.7.5 installed; it does not appear to have pip.exe. Simon | -----Original Message----- | From: David Kraeutmann [mailto:kane at kane.cx] | Sent: 26 October 2015 08:32 | To: Simon Peyton Jones | Cc: ghc-devs at haskell.org | Subject: Re: Sphinx on Windows | | 'pip' is just a Python package manager. Following the steps at | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fsphinx- | doc.org%2flatest%2finstall.html%23windows-install-python-and- | sphinx&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c865e98e064ee4e54daa | d08d2dddff6dd%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=TtHa5dAl%2fEASoNW | kXJDQ0Om6ilkxRguR%2bpBrZP19ujc%3d | should give you a working sphinx install. I can test those on my Windows | machine once I'm home, but that won't be for a few hours. | | On Mon, Oct 26, 2015 at 8:59 AM, Simon Peyton Jones | wrote: | > The GHC wiki says you need Sphinx to build docs, | > | > | > https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Tools | > | > and refers to the Preparation doc for how to install Sphinx | > | > https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation | > | > But the Windows sub-page of Preparation does not say how to install | Sphinx. | > | > Question: how does one install Sphinx on Windows? The sphinx-doc home | > page mutters about ?pip?, but I?ve never used that. Does anyone have | > instructions? | > | > Thanks | > | > Simon | > | > | > _______________________________________________ | > 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%7c865e98e064ee4e54daad0 | 8d2dddff6dd%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=zUsjfvEKGbIjR%2b9QP | InIXPKB7P%2bt2zXcPxLPvHlzWNs%3d | > From christiaan.baaij at gmail.com Mon Oct 26 09:53:27 2015 From: christiaan.baaij at gmail.com (Christiaan Baaij) Date: Mon, 26 Oct 2015 10:53:27 +0100 Subject: Duplicated typedef trips my gcc over In-Reply-To: References: Message-ID: I cannot build HEAD for the same reason. Same GCC version. On 21 October 2015 at 13:08, Gabor Greif wrote: > Hi all, > > look: > > $ git grep "typedef struct LibDwSession_ " > rts/Libdw.c:typedef struct LibDwSession_ LibDwSession; > rts/Libdw.h:typedef struct LibDwSession_ LibDwSession; > > $ which gcc > /usr/bin/gcc > > $ gcc --version > gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4) > Copyright (C) 2010 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > Any reason why we need the typedef in rts/Libdw.c ?? My gcc complains > about it... > > Cheers, > > Gabor > _______________________________________________ > 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 Oct 26 10:01:04 2015 From: kane at kane.cx (David Kraeutmann) Date: Mon, 26 Oct 2015 11:01:04 +0100 Subject: Sphinx on Windows In-Reply-To: <7e3970cc66724d7a92e0fa3f26ed3bc5@DB4PR30MB030.064d.mgd.msft.net> References: <7e3970cc66724d7a92e0fa3f26ed3bc5@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Grab https://bootstrap.pypa.io/get-pip.py and do `python get-pip.py' from a command prompt (might need to be elevated, not sure). After that 'pip' should be available and you can do 'pip install sphinx'. On Mon, Oct 26, 2015 at 10:41 AM, Simon Peyton Jones wrote: > I have not tried that. But 'pip' gives "command not found". > > Maybe I need something in my path? I appear to have python 2.7.5 installed; it does not appear to have pip.exe. > > Simon > > | -----Original Message----- > | From: David Kraeutmann [mailto:kane at kane.cx] > | Sent: 26 October 2015 08:32 > | To: Simon Peyton Jones > | Cc: ghc-devs at haskell.org > | Subject: Re: Sphinx on Windows > | > | 'pip' is just a Python package manager. Following the steps at > | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fsphinx- > | doc.org%2flatest%2finstall.html%23windows-install-python-and- > | sphinx&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c865e98e064ee4e54daa > | d08d2dddff6dd%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=TtHa5dAl%2fEASoNW > | kXJDQ0Om6ilkxRguR%2bpBrZP19ujc%3d > | should give you a working sphinx install. I can test those on my Windows > | machine once I'm home, but that won't be for a few hours. > | > | On Mon, Oct 26, 2015 at 8:59 AM, Simon Peyton Jones > | wrote: > | > The GHC wiki says you need Sphinx to build docs, > | > > | > > | > https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Tools > | > > | > and refers to the Preparation doc for how to install Sphinx > | > > | > https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation > | > > | > But the Windows sub-page of Preparation does not say how to install > | Sphinx. > | > > | > Question: how does one install Sphinx on Windows? The sphinx-doc home > | > page mutters about ?pip?, but I?ve never used that. Does anyone have > | > instructions? > | > > | > Thanks > | > > | > Simon > | > > | > > | > _______________________________________________ > | > 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%7c865e98e064ee4e54daad0 > | 8d2dddff6dd%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=zUsjfvEKGbIjR%2b9QP > | InIXPKB7P%2bt2zXcPxLPvHlzWNs%3d > | > From simonpj at microsoft.com Mon Oct 26 10:07:12 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 26 Oct 2015 10:07:12 +0000 Subject: Sphinx on Windows In-Reply-To: References: <7e3970cc66724d7a92e0fa3f26ed3bc5@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Thanks. But it's a bit inefficient to debug by email. For now I've simply switched off the sphinx stuff in my build.mk. Might you work it through when you have access to a machine, and document the result? If the desired sequence is to * get pip * use pip to get sphinx then could the docs on https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows be update to say precisely that? Someone went to some trouble to make that page short and easy, and perhaps there is a more direct route. I'm not sure. Many thanks Simon | -----Original Message----- | From: David Kraeutmann [mailto:kane at kane.cx] | Sent: 26 October 2015 10:01 | To: Simon Peyton Jones | Cc: ghc-devs at haskell.org | Subject: Re: Sphinx on Windows | | Grab | https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fbootstrap.p | ypa.io%2fget- | pip.py&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c2143737483a740eb651 | 308d2ddec5e3d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=YnlD5KrF3LBjq2ys8 | M4ZSsv26Qgrwo7WdYYaUh2sNiU%3d and do `python | https://na01.safelinks.protection.outlook.com/?url=get- | pip.py&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c2143737483a740eb651 | 308d2ddec5e3d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=2DVk4wuIWO9bYpS7Y | XBuInrDI9jER9ETucrMnvvPjEA%3d' | from a command prompt (might need to be elevated, not sure). After that | 'pip' should be available and you can do 'pip install sphinx'. | | On Mon, Oct 26, 2015 at 10:41 AM, Simon Peyton Jones | wrote: | > I have not tried that. But 'pip' gives "command not found". | > | > Maybe I need something in my path? I appear to have python 2.7.5 | installed; it does not appear to have pip.exe. | > | > Simon | > | > | -----Original Message----- | > | From: David Kraeutmann [mailto:kane at kane.cx] | > | Sent: 26 October 2015 08:32 | > | To: Simon Peyton Jones | > | Cc: ghc-devs at haskell.org | > | Subject: Re: Sphinx on Windows | > | | > | 'pip' is just a Python package manager. Following the steps at | > | | > | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fsphi | > | nx- | > | doc.org%2flatest%2finstall.html%23windows-install-python-and- | > | | > | sphinx&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c865e98e064e | > | e4e54daa | > | d08d2dddff6dd%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=TtHa5dAl% | > | 2fEASoNW | > | kXJDQ0Om6ilkxRguR%2bpBrZP19ujc%3d | > | should give you a working sphinx install. I can test those on my | > | Windows machine once I'm home, but that won't be for a few hours. | > | | > | On Mon, Oct 26, 2015 at 8:59 AM, Simon Peyton Jones | > | | > | wrote: | > | > The GHC wiki says you need Sphinx to build docs, > > > | > | https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Tools | > | > | > | > and refers to the Preparation doc for how to install Sphinx > > | > | https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation | > | > | > | > But the Windows sub-page of Preparation does not say how to | > | install Sphinx. | > | > | > | > Question: how does one install Sphinx on Windows? The sphinx-doc | > | home > page mutters about ?pip?, but I?ve never used that. Does | > | anyone have > instructions? | > | > | > | > Thanks | > | > | > | > Simon | > | > | > | > | > | > _______________________________________________ | > | > 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%7c865e98e064ee4 | > | e54daad0 | > | 8d2dddff6dd%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=zUsjfvEKGbI | > | jR%2b9QP | > | InIXPKB7P%2bt2zXcPxLPvHlzWNs%3d | > | > From ggreif at gmail.com Mon Oct 26 10:18:37 2015 From: ggreif at gmail.com (Gabor Greif) Date: Mon, 26 Oct 2015 11:18:37 +0100 Subject: Duplicated typedef trips my gcc over In-Reply-To: References: Message-ID: I have just committed a tentative fix I am using for a while, and keep watching the buildbots. Cheers, Gabor On 10/26/15, Christiaan Baaij wrote: > I cannot build HEAD for the same reason. Same GCC version. > > On 21 October 2015 at 13:08, Gabor Greif wrote: > >> Hi all, >> >> look: >> >> $ git grep "typedef struct LibDwSession_ " >> rts/Libdw.c:typedef struct LibDwSession_ LibDwSession; >> rts/Libdw.h:typedef struct LibDwSession_ LibDwSession; >> >> $ which gcc >> /usr/bin/gcc >> >> $ gcc --version >> gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4) >> Copyright (C) 2010 Free Software Foundation, Inc. >> This is free software; see the source for copying conditions. There is >> NO >> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR >> PURPOSE. >> >> Any reason why we need the typedef in rts/Libdw.c ?? My gcc complains >> about it... >> >> Cheers, >> >> Gabor >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > From ben at smart-cactus.org Mon Oct 26 10:35:57 2015 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 26 Oct 2015 11:35:57 +0100 Subject: Duplicated typedef trips my gcc over In-Reply-To: References: Message-ID: <87d1w16ho2.fsf@smart-cactus.org> Gabor Greif writes: > Hi all, > > look: > > $ git grep "typedef struct LibDwSession_ " > rts/Libdw.c:typedef struct LibDwSession_ LibDwSession; > rts/Libdw.h:typedef struct LibDwSession_ LibDwSession; > > $ which gcc > /usr/bin/gcc > > $ gcc --version > gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4) > Copyright (C) 2010 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > Any reason why we need the typedef in rts/Libdw.c ?? My gcc complains > about it... > Nope; your fix ought to be fine. Thanks! - 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 Mon Oct 26 10:38:55 2015 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 26 Oct 2015 11:38:55 +0100 Subject: Sphinx on Windows In-Reply-To: <7e3970cc66724d7a92e0fa3f26ed3bc5@DB4PR30MB030.064d.mgd.msft.net> References: <7e3970cc66724d7a92e0fa3f26ed3bc5@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <87a8r56hj4.fsf@smart-cactus.org> Simon Peyton Jones writes: > I have not tried that. But 'pip' gives "command not found". > > Maybe I need something in my path? I appear to have python 2.7.5 installed; it does not appear to have pip.exe. > Pip ships with Python 2.7.9 and later. Alternatively, you this script [1] will install pip for you. Just download it and run it with, $ python get-pip.py See the Sphinx installation page [2] for details. Cheers, - Ben [1] https://bootstrap.pypa.io/get-pip.py [2] http://sphinx-doc.org/install.html#windows-install-python-and-sphinx -------------- 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 Oct 26 12:20:30 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Mon, 26 Oct 2015 14:20:30 +0200 Subject: [GHC] #11019: ApiAnnotations: Make all RdrName occurences Located In-Reply-To: <059.c44acc9d4bd85a32e3a536f879025df8@haskell.org> References: <044.6f9b0661f882f5c32756a32bbf81653d@haskell.org> <059.c44acc9d4bd85a32e3a536f879025df8@haskell.org> Message-ID: At the moment in HaRe we do use the wrapped location, but it results in code that is much more complex. This change is more about bringing predictability to the AST than anything else. If anyone feels strongly that it should not happen then we can live without it. On Mon, Oct 26, 2015 at 2:11 PM, GHC wrote: > #11019: ApiAnnotations: Make all RdrName occurences Located > -------------------------------------+------------------------------------- > Reporter: alanz | Owner: alanz > Type: bug | Status: new > Priority: normal | Milestone: 8.0.1 > Component: Compiler | Version: 7.10.2 > Resolution: | Keywords: > | ApiAnnotations > Operating System: Unknown/Multiple | Architecture: > | Unknown/Multiple > Type of failure: None/Unknown | Test Case: > Blocked By: | Blocking: > Related Tickets: | Differential Rev(s): > Wiki Page: | > -------------------------------------+------------------------------------- > > Comment (by goldfire): > > Perhaps I'm missing something very simple, but if you have a, for example, > `LHsExpr Name` which matches the pattern `(L loc (HsVar name))`, the `loc` > should apply just as well to the `name` as to the overall expression. My > understanding of each of the cases above is that they all have this > property, so adding another `Located` wrapper would be redundant. > > Or am I missing something? > > -- > Ticket URL: > GHC > The Glasgow Haskell Compiler > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Oct 26 12:57:55 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 26 Oct 2015 12:57:55 +0000 Subject: Can't push to haddock repo Message-ID: I can't update the haddock repository! (I want to add a new branch for my in-flight work.) Can anyone help? Thanks Simon git push --set-upstream origin wip/spj-wildcard-refactor remote: W refs/heads/wip/spj-wildcard-refactor haddock simonpj DENIED by refs/.* remote: error: hook declined to update refs/heads/wip/spj-wildcard-refactor To ssh://git at git.haskell.org/haddock.git ! [remote rejected] wip/spj-wildcard-refactor -> wip/spj-wildcard-refactor (hook declined) error: failed to push some refs to 'ssh://git at git.haskell.org/haddock.git' haddock $ -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvriedel at gmail.com Mon Oct 26 13:03:31 2015 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Mon, 26 Oct 2015 14:03:31 +0100 Subject: Can't push to haddock repo In-Reply-To: (Simon Peyton Jones's message of "Mon, 26 Oct 2015 12:57:55 +0000") References: Message-ID: <87k2q9dboc.fsf@gmail.com> In the GHC tree: $ grep haddock packages utils/haddock - - ssh://git at github.com/haskell/haddock.git says that the upstream repo for Haddock is ssh://... (there are some comments in the 'packages' file that explain what the last column means) so you have to do something like git push ssh://git at github.com/haskell/haddock.git HEAD:wip/spj-wildcard-refactor (the 'HEAD:' part may be optional, it just says, push what is the current HEAD of your local repo to the remote branch wip/...) HTH On 2015-10-26 at 13:57:55 +0100, Simon Peyton Jones wrote: > I can't update the haddock repository! (I want to add a new branch for my in-flight work.) > Can anyone help? > Thanks > Simon > > > git push --set-upstream origin wip/spj-wildcard-refactor > > remote: W refs/heads/wip/spj-wildcard-refactor haddock simonpj DENIED by refs/.* > > remote: error: hook declined to update refs/heads/wip/spj-wildcard-refactor > > To ssh://git at git.haskell.org/haddock.git > > ! [remote rejected] wip/spj-wildcard-refactor -> wip/spj-wildcard-refactor (hook declined) > > error: failed to push some refs to 'ssh://git at git.haskell.org/haddock.git' > > haddock $ > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- "Elegance is not optional" -- Richard O'Keefe From simonpj at microsoft.com Mon Oct 26 13:24:05 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 26 Oct 2015 13:24:05 +0000 Subject: Can't push to haddock repo In-Reply-To: <87k2q9dboc.fsf@gmail.com> References: <87k2q9dboc.fsf@gmail.com> Message-ID: Well in utils/haddock/.git/config I see [remote "origin"] url = git://git.haskell.org/haddock.git pushurl = ssh://git at git.haskell.org/haddock.git So that looks right. Why would git push not work? Simon | -----Original Message----- | From: Herbert Valerio Riedel [mailto:hvriedel at gmail.com] | Sent: 26 October 2015 13:04 | To: Simon Peyton Jones | Cc: ghc-devs at haskell.org | Subject: Re: Can't push to haddock repo | | | In the GHC tree: | | $ grep haddock packages | utils/haddock - - | ssh://git at github.com/haskell/haddock.git | | says that the upstream repo for Haddock is ssh://... | | (there are some comments in the 'packages' file that explain what the | last column means) | | so you have to do something like | | git push ssh://git at github.com/haskell/haddock.git HEAD:wip/spj-wildcard- | refactor | | (the 'HEAD:' part may be optional, it just says, push what is the | current HEAD of your local repo to the remote branch wip/...) | | HTH | | On 2015-10-26 at 13:57:55 +0100, Simon Peyton Jones wrote: | > I can't update the haddock repository! (I want to add a new branch for | my in-flight work.) | > Can anyone help? | > Thanks | > Simon | > | > | > git push --set-upstream origin wip/spj-wildcard-refactor | > | > remote: W refs/heads/wip/spj-wildcard-refactor haddock simonpj DENIED by | refs/.* | > | > remote: error: hook declined to update refs/heads/wip/spj-wildcard- | refactor | > | > To ssh://git at git.haskell.org/haddock.git | > | > ! [remote rejected] wip/spj-wildcard-refactor -> wip/spj-wildcard- | refactor (hook declined) | > | > error: failed to push some refs to | 'ssh://git at git.haskell.org/haddock.git' | > | > haddock $ | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs at haskell.org | > | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskel | l.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c8b244454862541a00577 | 08d2de05db9f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=kCypWx5Kq7ffV9piW | ItQNerjzDLU68rgHUacMsV%2f5pk%3d | | -- | "Elegance is not optional" -- Richard O'Keefe From ben at well-typed.com Mon Oct 26 13:54:55 2015 From: ben at well-typed.com (Ben Gamari) Date: Mon, 26 Oct 2015 14:54:55 +0100 Subject: Can't push to haddock repo In-Reply-To: References: <87k2q9dboc.fsf@gmail.com> Message-ID: <871tch68gg.fsf@smart-cactus.org> Simon Peyton Jones writes: > Well in utils/haddock/.git/config I see > [remote "origin"] > url = git://git.haskell.org/haddock.git > pushurl = ssh://git at git.haskell.org/haddock.git > Note the difference in hostnames, ssh://git at git.haskell.org/haddock.git ssh://git at github.com/haskell/haddock.git The point being, Haddock is hosted on Github. I believe the repo on git.haskell.org is merely a mirror. It's a bit hard to keep track of all of this at times, so the upstream repositories are documented in the `packages` file at the root of the GHC repository. 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 Mon Oct 26 14:07:27 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 26 Oct 2015 14:07:27 +0000 Subject: Can't push to haddock repo In-Reply-To: <871tch68gg.fsf@smart-cactus.org> References: <87k2q9dboc.fsf@gmail.com> <871tch68gg.fsf@smart-cactus.org> Message-ID: <65687b5e820848f1bad0daef64f60aac@DB4PR30MB030.064d.mgd.msft.net> ah yes, my bad. Thanks | -----Original Message----- | From: Ben Gamari [mailto:ben at well-typed.com] | Sent: 26 October 2015 13:55 | To: Simon Peyton Jones; Herbert Valerio Riedel | Cc: ghc-devs at haskell.org | Subject: RE: Can't push to haddock repo | | Simon Peyton Jones writes: | | > Well in utils/haddock/.git/config I see [remote "origin"] | > url = git://git.haskell.org/haddock.git | > pushurl = ssh://git at git.haskell.org/haddock.git | > | Note the difference in hostnames, | | ssh://git at git.haskell.org/haddock.git | ssh://git at github.com/haskell/haddock.git | | The point being, Haddock is hosted on Github. I believe the repo on | git.haskell.org is merely a mirror. | | It's a bit hard to keep track of all of this at times, so the upstream | repositories are documented in the `packages` file at the root of the GHC | repository. | | Cheers, | | - Ben From simonpj at microsoft.com Mon Oct 26 14:27:08 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 26 Oct 2015 14:27:08 +0000 Subject: Better calling conventions for strict functions (bang patterns)? In-Reply-To: References: Message-ID: <57f6d556b7514199b57396df3987f7bb@DB4PR30MB030.064d.mgd.msft.net> Ryan Yes, I?m sure there is room for improvement here! Good observations. In particular, while I?d like DATA to support this, I believe that most ?eval?s find that the thing being evaluated is already evaluated; so the fast-path should be that case. We should bet for evaluated. NB, however, that the stack-overflow check applies to the entire function body. Suppose we do f x = case x of (p,q) -> case p of True -> False; False -> True Then we can eliminate the stack check only if both the eval of ?x? and the eval of ?p? both take the fast path. Another avenue you might like to think about is this: if function f calls g, then g?s stack-overflow test could perhaps be absorbed into ?f?s. So f x = case (g x) of True -> False; False -> True So maybe f could call a super-fast entry point for g that didn?t have a stack overflow test! (Watch out: loops, recursion, etc) I?m happy to advise. Simon From: Ryan Newton [mailto:rrnewton at gmail.com] Sent: 23 October 2015 19:31 To: Simon Peyton Jones Cc: ghc-devs at haskell.org; ?mer Sinan A?acan; Ryan Scott; Chao-Hong Chen; Johan Tibell Subject: Re: Better calling conventions for strict functions (bang patterns)? Ah, yes, so just to give a concrete example in this thread, if we take the `foo` function above and say `map foo ls`, we may well get unevaluated arguments to foo. (And this is almost precisely the same as the first example that Strict-Core paper!) Thanks for the paper reference. I read it and it's great -- just what I was looking for. An approach that eliminates any jealousy of ML/Scheme compiler techniques vis a vis calling conventions ;-). I'm also wondering if there are some incremental steps that can be taken, short of what is proposed in the paper. 1. Small tweaks: The CMM code above seems to be betting than the thunk is unevaluated, because it does the stack check and stack write before the predicate test that checks if the thunk is evaluated (if (R1 & 7 != 0) goto c3aO; else goto c3aP;). With a bang-pattern function, couldn't it make the opposite bet? That is, branch on whether the thunk is evaluated first, and then the wasted computation is only a single correctly predicted branch (and a read of a tag that we need to read anyway). 2. The option of multiple entrypoints which is considered and discarded as fragile in the beginning of the paper (for direct call vs indirect / 1st order vs higher order). That fragile option is along the lines of what I wanted to discuss on this thread. It does seem like a tricky phase ordering concern, but how bad is it exactly? The conflict with the a case-expr rewrite is illustrated clearly in the paper, but that just means that such optimizations must happen before the final choice of which function entrypoint to call, doesn't it? I'm not 100% sure where it could go in the current compiler pipeline, but couldn't the adjustment of call target from "foo" to "foo_with_known_whnf_args" happen quite late? Cheers, -Ryan P.S. One of the students CC'd, Ryan Scott, is currently on internship at Intel labs and is working to (hopefully) liberate the Intell Haskell Research Compiler as open source. Like the 2009 paper, it also uses a strict IR, and I think it will be interesting to see exactly how it handles the conversion from Core to its IR. (Probably the same as Fig 10 in the paper.) On Fri, Oct 23, 2015 at 10:11 AM, Simon Peyton Jones > wrote: It?s absolutely the case that bang patterns etc tell the caller what to do, but the function CANNOT ASSUME that its argument is evaluated. Reason: higher order functions. I think that the way to allow functions that can assume their arg is evaluated is through types: see Type are calling conventions. But it?d be a fairly big deal to implement. Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Ryan Newton Sent: 23 October 2015 14:54 To: ghc-devs at haskell.org; ?mer Sinan A?acan; Ryan Scott; Chao-Hong Chen; Johan Tibell Subject: Better calling conventions for strict functions (bang patterns)? Hi all, With module-level Strict and StrictData pragmas coming soon, one obvious question is what kind of the code quality GHC can achieve for strict programs. When it came up in discussion in our research group we realized we didn't actually know whether the bang patterns, `f !x`, on function arguments were enforced by caller or callee. Here's a Gist that shows the compilation of a trivial function: foo :: Maybe Int -> Int foo !x = case x of Just y -> y https://gist.github.com/rrnewton/1ac722189c65f26fe9ac If that function is compiled to *assume* its input is in WHNF, it should be just as efficient as the isomorphic MLton/OCaml code, right? It only needs to branch on the tag, do a field dereference, and return. But as you can see from the STG and CMM generated, foo does indeed enter the thunk, adding an extra indirect jump. Here's the body: c3aY: if ((Sp + -8) < SpLim) goto c3aZ; else goto c3b0; c3aZ: // nop R1 = PicBaseReg + foo_closure; call (I64[BaseReg - 8])(R2, R1) args: 8, res: 0, upd: 8; c3b0: I64[Sp - 8] = PicBaseReg + block_c3aO_info; R1 = R2; Sp = Sp - 8; if (R1 & 7 != 0) goto c3aO; else goto c3aP; c3aP: call (I64[R1])(R1) returns to c3aO, args: 8, res: 8, upd: 8; c3aO: if (R1 & 7 >= 2) goto c3aW; else goto c3aX; c3aW: R1 = P64[R1 + 6] & (-8); Sp = Sp + 8; call (I64[R1])(R1) args: 8, res: 0, upd: 8; c3aX: R1 = PicBaseReg + lvl_r39S_closure; Sp = Sp + 8; call (I64[R1])(R1) args: 8, res: 0, upd: 8; The call inside c3aP is entering "x" as a thunk, which also incurs all of the stack limit check code. I believe that IF the input could be assumed to be in WHNF, everything above the label "c3aO" could be omitted. So... if GHC is going to be a fabulous pure and imperative language, and a fabulous lazy and strict compiler/runtime.. is there some work we can do here to improve this situation? Would the following make sense: * Put together a benchmark suite of all-strict programs with Strict/StrictData (compare a few benchmark's generated code to MLton, if time allows) * Modify GHC to change calling conventions for bang patterns -- caller enforces WHNF rather than callee. Existing strictness/demand/cardinality analysis would stay the same. Unless there's something I'm really missing here, the result should be that you can have a whole chain of strict function calls, each of which knows its arguments and the arguments it passes to its callees are all in WHNF, without ever generating thunk-entry sequences. Thanks for your time, -Ryan -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyrab at mail.ru Mon Oct 26 14:40:20 2015 From: kyrab at mail.ru (kyra) Date: Mon, 26 Oct 2015 17:40:20 +0300 Subject: Sphinx on Windows In-Reply-To: References: Message-ID: <562E3B54.8040107@mail.ru> The Sphinx + GHC HEAD on Windows story is somewhat complicated. Incidentally I've just managed to get it all working, thus I can share some of my knowledge: 1. Sphinx + GHC HEAD *doesn't work* on Windows if unmodified. The problem is in 'mkUserGuidePart' utility. It crashes when trying to create utf8 encoded files when run in the console with default codepage. But if one changes console codepage to 65001 (chcp 65001) then 'mkUserGuidePart' runs successfully *but* Sphinx stops working complaining it doesn't know what cp65001 encoding is. I've found that this fact is known to Python community but they won't fix it in any foreseeable future. Thus, the only way to make *both* mkUserGuidePart and Sphinx work on windows is to modify mkUserGuidePart. I've made the following quick fix for it: diff -urN a/utils/mkUserGuidePart/Main.hs b/utils/mkUserGuidePart/Main.hs --- a/utils/mkUserGuidePart/Main.hs 2015-10-08 14:09:24.000000000 +0300 +++ b/utils/mkUserGuidePart/Main.hs 2015-10-24 21:42:41.321262400 +0300 @@ -7,6 +7,11 @@ import Table import Options +import System.IO + +writeFileUtf8 :: FilePath -> String -> IO () +writeFileUtf8 f txt = withFile f WriteMode (\ hdl -> hSetEncoding hdl utf8 >> hPutStr hdl txt) + -- | A ReStructuredText fragment type ReST = String @@ -27,7 +32,7 @@ writeRestFile :: FilePath -> ReST -> IO () writeRestFile fname content = - writeFile fname $ unlines + writeFileUtf8 fname $ unlines [ ".. This file is generated by utils/mkUserGuidePart" , "" , content 2. Regarding Python installation on Windows -- 2 options worked for me: -- the simplest is to install WinPython (http://winpython.github.io/) which contains all necessary bits -- more problematic is to install mingw-w64-x86_64-python2-sphinx (change x86_64 for i686 for 32-bit environment) from MSys2. It doesn't work out of the box and further fixes are necessary: -- the sphinx driver is called sphinx-build2 instead of sphinx-build thus one need to modify configure.ac accordingly -- the sphinx distribution itself is broken because python scripts are broken, for example, sphinx-build2-script.py starts with #!/usr/bin/env python2.exe which is wrong because thus it starts MSys2 python (instead of MINGW python) which misses necessary packages. I've had to modify all related python scripts changing /usr/bin/env python2.exe to hardcoded MINGW python path. Hope this helps. Cheers, Kyra On 26.10.2015 10:59, Simon Peyton Jones wrote: > > The GHC wiki says you need Sphinx to build docs, > > https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Tools > > and refers to the Preparation doc for how to install Sphinx > > https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation > > But the Windows sub-page of Preparation does not say how to install > Sphinx. > > Question: how does one install Sphinx on Windows? The sphinx-doc home > page mutters about ?pip?, but I?ve never used that. Does anyone have > instructions? > > Thanks > > Simon > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From edzhavoronkov at gmail.com Mon Oct 26 14:52:38 2015 From: edzhavoronkov at gmail.com (=?UTF-8?B?0K3QtNCz0LDRgCDQltCw0LLQvtGA0L7QvdC60L7Qsg==?=) Date: Mon, 26 Oct 2015 17:52:38 +0300 Subject: Warning suppression pragmas In-Reply-To: References: Message-ID: Hello Richard! Can you take a look at some sort of specification i wrote week ago? I placed it here: https://ghc.haskell.org/trac/ghc/wiki/Design/LocalWarningPragmas I can imagine only two use cases, and i'm not sure about correcteness of it --- ? ?????????, ?????????? ????? Best regards, Edgar A. Zhavoronkov 2015-10-20 1:44 GMT+03:00 ????? ?????????? : > Oh, okay, sure > > --- > ? ?????????, > ?????????? ????? > > Yours sincerely, > Zhavornkov Edgar > > 2015-10-20 1:37 GMT+03:00 Richard Eisenberg : > >> Sure. But before thinking about implementation, let's think about >> specification. Write a wiki page (perhaps >> https://ghc.haskell.org/trac/ghc/wiki/Design/LocalWarningPragmas ) with >> the design of how the feature should work, with several examples. Once we >> know what we're building, then we can talk about how to build it. >> >> Thanks! >> Richard >> >> On Oct 19, 2015, at 6:21 PM, ????? ?????????? >> wrote: >> >> Hello, Richard, >> >> Do you know something about defining own pragmas in GHC? >> >> --- >> >> ? ?????????, >> ?????????? ????? >> >> 2015-10-20 1:17 GMT+03:00 Richard Eisenberg : >> >>> Hi Edgar, >>> >>> No, that doesn't exist yet. Would surely be useful, though. >>> >>> Richard >>> >>> On Oct 19, 2015, at 6:16 PM, ????? ?????????? >>> wrote: >>> >>> No, i mean exactly pragmas in source code, that i can particulary add to >>> function or a part of the code for example. >>> E.g: >>> >>> {-# BEGIN_SUPPRESS_WARNINGS #-} >>> >>> foo :: a -> b >>> #do something that throws warnings >>> >>> {-# END_SUPPRESS_WARNINGS #-} >>> >>> >>> >>> 2015-10-20 1:10 GMT+03:00 Richard Eisenberg : >>> >>>> I just responded to #602, but perhaps you're just looking for the >>>> -fno-warn-XXX options listed here: >>>> https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/flag-reference.html#idp14879296 >>>> >>>> Richard >>>> >>>> On Oct 19, 2015, at 5:22 PM, ????? ?????????? >>>> wrote: >>>> >>>> Hi everyone! >>>> >>>> Do you know, if there is pragma for warning suppression? I want to >>>> implement something like warning suppression related to this ticket in >>>> GHC's Trac (https://ghc.haskell.org/trac/ghc/ticket/602). Or i need to >>>> implement that kind of pragma by myself? >>>> >>>> Thanks in advance! >>>> Edgar >>>> _______________________________________________ >>>> 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 Mon Oct 26 15:19:54 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 26 Oct 2015 15:19:54 +0000 Subject: Warning suppression pragmas In-Reply-To: References: Message-ID: What is $warning_names$?? From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of ????? ?????????? Sent: 26 October 2015 14:53 To: Richard Eisenberg Cc: ghc-devs at haskell.org Subject: Re: Warning suppression pragmas Hello Richard! Can you take a look at some sort of specification i wrote week ago? I placed it here: https://ghc.haskell.org/trac/ghc/wiki/Design/LocalWarningPragmas I can imagine only two use cases, and i'm not sure about correcteness of it --- ? ?????????, ?????????? ????? Best regards, Edgar A. Zhavoronkov 2015-10-20 1:44 GMT+03:00 ????? ?????????? >: Oh, okay, sure --- ? ?????????, ?????????? ????? Yours sincerely, Zhavornkov Edgar 2015-10-20 1:37 GMT+03:00 Richard Eisenberg >: Sure. But before thinking about implementation, let's think about specification. Write a wiki page (perhaps https://ghc.haskell.org/trac/ghc/wiki/Design/LocalWarningPragmas ) with the design of how the feature should work, with several examples. Once we know what we're building, then we can talk about how to build it. Thanks! Richard On Oct 19, 2015, at 6:21 PM, ????? ?????????? > wrote: Hello, Richard, Do you know something about defining own pragmas in GHC? --- ? ?????????, ?????????? ????? 2015-10-20 1:17 GMT+03:00 Richard Eisenberg >: Hi Edgar, No, that doesn't exist yet. Would surely be useful, though. Richard On Oct 19, 2015, at 6:16 PM, ????? ?????????? > wrote: No, i mean exactly pragmas in source code, that i can particulary add to function or a part of the code for example. E.g: {-# BEGIN_SUPPRESS_WARNINGS #-} foo :: a -> b #do something that throws warnings {-# END_SUPPRESS_WARNINGS #-} 2015-10-20 1:10 GMT+03:00 Richard Eisenberg >: I just responded to #602, but perhaps you're just looking for the -fno-warn-XXX options listed here: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/flag-reference.html#idp14879296 Richard On Oct 19, 2015, at 5:22 PM, ????? ?????????? > wrote: Hi everyone! Do you know, if there is pragma for warning suppression? I want to implement something like warning suppression related to this ticket in GHC's Trac (https://ghc.haskell.org/trac/ghc/ticket/602). Or i need to implement that kind of pragma by myself? Thanks in advance! Edgar _______________________________________________ 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 Mon Oct 26 15:20:58 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 26 Oct 2015 15:20:58 +0000 Subject: Sphinx on Windows In-Reply-To: <562E3B54.8040107@mail.ru> References: <562E3B54.8040107@mail.ru> Message-ID: Thanks. I'll just disable it for now. When you have this sorted out, could you add something to the Windows instructions for GHC devs? That'd be super-helpful Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of kyra | Sent: 26 October 2015 14:40 | To: ghc-devs at haskell.org | Subject: Re: Sphinx on Windows | | The Sphinx + GHC HEAD on Windows story is somewhat complicated. | Incidentally I've just managed to get it all working, thus I can share some | of my knowledge: | | 1. Sphinx + GHC HEAD *doesn't work* on Windows if unmodified. | | The problem is in 'mkUserGuidePart' utility. It crashes when trying to | create utf8 encoded files when run in the console with default codepage. | But if one changes console codepage to 65001 (chcp 65001) then | 'mkUserGuidePart' runs successfully *but* Sphinx stops working complaining | it doesn't know what cp65001 encoding is. I've found that this fact is known | to Python community but they won't fix it in any foreseeable future. | | Thus, the only way to make *both* mkUserGuidePart and Sphinx work on windows | is to modify mkUserGuidePart. | I've made the following quick fix for it: | | diff -urN a/utils/mkUserGuidePart/Main.hs b/utils/mkUserGuidePart/Main.hs | --- a/utils/mkUserGuidePart/Main.hs 2015-10-08 14:09:24.000000000 +0300 | +++ b/utils/mkUserGuidePart/Main.hs 2015-10-24 21:42:41.321262400 +0300 | @@ -7,6 +7,11 @@ | import Table | import Options | | +import System.IO | + | +writeFileUtf8 :: FilePath -> String -> IO () | +writeFileUtf8 f txt = withFile f WriteMode (\ hdl -> hSetEncoding hdl | utf8 >> hPutStr hdl txt) | + | -- | A ReStructuredText fragment | type ReST = String | | @@ -27,7 +32,7 @@ | | writeRestFile :: FilePath -> ReST -> IO () | writeRestFile fname content = | - writeFile fname $ unlines | + writeFileUtf8 fname $ unlines | [ ".. This file is generated by utils/mkUserGuidePart" | , "" | , content | | 2. Regarding Python installation on Windows -- 2 options worked for me: | -- the simplest is to install WinPython | (https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwinpython.g | ithub.io%2f&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c8b1e7e1d25f548 | 6c3b2e08d2de136222%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=hreGbIXD5Fcq | HRYefVgz54Yr9UwsFjfXMui1MLZ97UI%3d) | which contains all necessary bits | -- more problematic is to install mingw-w64-x86_64-python2-sphinx (change | x86_64 for i686 for 32-bit environment) from MSys2. It doesn't work out of | the box and further fixes are necessary: | -- the sphinx driver is called sphinx-build2 instead of sphinx-build | thus one need to modify | https://na01.safelinks.protection.outlook.com/?url=configure.ac&data=01%7c01 | %7csimonpj%40064d.mgd.microsoft.com%7c8b1e7e1d25f5486c3b2e08d2de136222%7c72f | 988bf86f141af91ab2d7cd011db47%7c1&sdata=LkUUK8z66o9oJH3zM%2fVdZvwhEeOwaVzqYE | %2fue8NMrNU%3d accordingly | -- the sphinx distribution itself is broken because python scripts are | broken, for example, | https://na01.safelinks.protection.outlook.com/?url=sphinx-build2- | script.py&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c8b1e7e1d25f5486c | 3b2e08d2de136222%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=bwwa7fhpWKWWXE | QIHyopPVoPd0DiVb9p5HvkvoUVNis%3d starts with #!/usr/bin/env python2.exe | which is wrong because thus it starts MSys2 python (instead of MINGW python) | which misses necessary packages. I've had to modify all related python | scripts changing /usr/bin/env python2.exe to hardcoded MINGW python path. | | Hope this helps. | | Cheers, | Kyra | | On 26.10.2015 10:59, Simon Peyton Jones wrote: | > | > The GHC wiki says you need Sphinx to build docs, | > | > https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Tools | > | > and refers to the Preparation doc for how to install Sphinx | > | > https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation | > | > But the Windows sub-page of Preparation does not say how to install | > Sphinx. | > | > Question: how does one install Sphinx on Windows? The sphinx-doc home | > page mutters about 'pip', but I've never used that. Does anyone have | > instructions? | > | > Thanks | > | > Simon | > | > | > | > _______________________________________________ | > 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%7c8b1e7e1d25f5486c3b2e08d2de136222%7c72 | > f988bf86f141af91ab2d7cd011db47%7c1&sdata=8teFBXUzJgll4Eo0pBReMMOMd6v%2 | > bdQQ1yhOp3u9M3og%3d | | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell | .org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c8b1e7e1d25f5486c3b2e0 | 8d2de136222%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=8teFBXUzJgll4Eo0pBR | eMMOMd6v%2bdQQ1yhOp3u9M3og%3d From simonpj at microsoft.com Mon Oct 26 15:24:00 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 26 Oct 2015 15:24:00 +0000 Subject: recomp013 Message-ID: driver/recomp013 is failing, on Linux, on HEAD for me: Actual stdout output differs from expected: --- ./driver/recomp013/recomp013.stdout.normalised 2015-10-26 14:26:51.920153558 +0000 +++ ./driver/recomp013/recomp013.run.stdout.normalised 2015-10-26 14:26:51.920153558 +0000 @@ -3,5 +3,3 @@ [2 of 3] Compiling B ( B.hs, B.o ) [3 of 3] Compiling C ( C.hs, C.o ) second run -[2 of 3] Compiling B ( B.hs, B.o ) -[3 of 3] Compiling C ( C.hs, C.o ) [B changed] -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Mon Oct 26 16:00:04 2015 From: ben at well-typed.com (Ben Gamari) Date: Mon, 26 Oct 2015 17:00:04 +0100 Subject: Sphinx on Windows In-Reply-To: <562E3B54.8040107@mail.ru> References: <562E3B54.8040107@mail.ru> Message-ID: <87y4ep4o3f.fsf@smart-cactus.org> kyra writes: > The Sphinx + GHC HEAD on Windows story is somewhat complicated. > Incidentally I've just managed to get it all working, thus I can share > some of my knowledge: > Thanks for writing this down, Kyra! These notes are very helpful. Would you like to add a comment to your patch describing the rationale for the change and open a Phabricator Differential [1] so we can get it upstream? Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/wiki/Phabricator -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From edzhavoronkov at gmail.com Mon Oct 26 16:15:03 2015 From: edzhavoronkov at gmail.com (=?UTF-8?B?0K3QtNCz0LDRgCDQltCw0LLQvtGA0L7QvdC60L7Qsg==?=) Date: Mon, 26 Oct 2015 19:15:03 +0300 Subject: Warning suppression pragmas In-Reply-To: References: Message-ID: Hi Simon! It is a name of particular warning. By the way, you made me think of more general idea. So i think it would be enough to suppress all kinds of warnings that a function can throw(and a bit easier for me as a total newbee in GHC hacking =) ) --- ? ?????????, ?????????? ????? Best regards, Edgar A. Zhavoronkov 2015-10-26 18:19 GMT+03:00 Simon Peyton Jones : > What is $warning_names$?? > > > > *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *????? > ?????????? > *Sent:* 26 October 2015 14:53 > *To:* Richard Eisenberg > *Cc:* ghc-devs at haskell.org > *Subject:* Re: Warning suppression pragmas > > > > Hello Richard! > > > > Can you take a look at some sort of specification i wrote week ago? > > I placed it here: > https://ghc.haskell.org/trac/ghc/wiki/Design/LocalWarningPragmas > > I can imagine only two use cases, and i'm not sure about correcteness of it > > > --- > > ? ?????????, > > ?????????? ????? > > > > Best regards, > > Edgar A. Zhavoronkov > > > > 2015-10-20 1:44 GMT+03:00 ????? ?????????? : > > Oh, okay, sure > > > --- > > ? ?????????, > > ?????????? ????? > > > > Yours sincerely, > > Zhavornkov Edgar > > > > 2015-10-20 1:37 GMT+03:00 Richard Eisenberg : > > Sure. But before thinking about implementation, let's think about > specification. Write a wiki page (perhaps > https://ghc.haskell.org/trac/ghc/wiki/Design/LocalWarningPragmas ) with > the design of how the feature should work, with several examples. Once we > know what we're building, then we can talk about how to build it. > > > > Thanks! > > Richard > > > > On Oct 19, 2015, at 6:21 PM, ????? ?????????? > wrote: > > > > Hello, Richard, > > > > Do you know something about defining own pragmas in GHC? > > > --- > > > > ? ?????????, > > ?????????? ????? > > > > 2015-10-20 1:17 GMT+03:00 Richard Eisenberg : > > Hi Edgar, > > > > No, that doesn't exist yet. Would surely be useful, though. > > > > Richard > > > > On Oct 19, 2015, at 6:16 PM, ????? ?????????? > wrote: > > > > No, i mean exactly pragmas in source code, that i can particulary add to > function or a part of the code for example. > > E.g: > > > > {-# BEGIN_SUPPRESS_WARNINGS #-} > > > > foo :: a -> b > > #do something that throws warnings > > > > {-# END_SUPPRESS_WARNINGS #-} > > > > > > > > 2015-10-20 1:10 GMT+03:00 Richard Eisenberg : > > I just responded to #602, but perhaps you're just looking for the > -fno-warn-XXX options listed here: > https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/flag-reference.html#idp14879296 > > > > > Richard > > > > On Oct 19, 2015, at 5:22 PM, ????? ?????????? > wrote: > > > > Hi everyone! > > Do you know, if there is pragma for warning suppression? I want to > implement something like warning suppression related to this ticket in > GHC's Trac (https://ghc.haskell.org/trac/ghc/ticket/602). Or i need to > implement that kind of pragma by myself? > > Thanks in advance! > Edgar > > _______________________________________________ > 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 Mon Oct 26 16:32:27 2015 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Mon, 26 Oct 2015 12:32:27 -0400 Subject: Segfault in a CoreLinted program (and a GHC-generated Core question) Message-ID: I have a very simple Core plugin that generates some functions. After my Core-to-Core pass is done, I'm running the linter to make sure the Core generated by my plugin is well-formed and well-typed. However, even though lint checker passes, the code generated by my plugin is failing with a segfault. I created a git repo for demonstration: https://github.com/osa1/plugins This is where the CoreLint is happening: https://github.com/osa1/plugins/blob/master/src/Plugins.hs#L38 I'm using GHC HEAD(it doesn't build with 7.10). Here's how to run: Make sure GHC HEAD is in the $PATH, then $ cabal install --with-ghc=ghc-stage2 $ cd test Adding bunch of -ddump parameters here for debugging purposes: $ ghc-stage2 -fplugin=Plugins --make Main.hs -fforce-recomp -ddump-simpl -ddump-ds -ddump-to-file -ddump-stg Now if you run the generated program, it should first print some numbers and then segfault. --- I heard from Simon in various talks(e.g. Haskell exchange 2015) that if lint passes, then there should be no segfaults, so I thought this should be a bug. I'm actually having some other problems with CoreLint too, for example, even though Core lint passes, if I run Core simplifier pass after my plugin runs, GHC is failing with various different panics. Some of those panics are happening inside STG generation, not in simplifier(but it works fine if I disable the simplifier!) It seems like CoreLint is not strict enough, it's not checking some invariants that GHC simplifier and STG code generator are assuming. So my questions are: Am I right in assuming that CoreLint accepted programs should not segfault? What about internal invariants? Should CoreLint check for those? Is there any pass that checks for invariants and prints helpful messages in case of a invariant invalidation? As an attempt at debugging the code generated by my plugin, I wrote the function that is supposed to be generated by my Core pass in Haskell and compiled with GHC. Generated Core is mostly the same, except at one point it has an extra lambda directly applied to a void#, something like ((\_ -> ...) void#). Where can I learn more about why GHC is doing that? Thanks. From ben at well-typed.com Mon Oct 26 16:45:06 2015 From: ben at well-typed.com (Ben Gamari) Date: Mon, 26 Oct 2015 17:45:06 +0100 Subject: Warning suppression pragmas In-Reply-To: References: Message-ID: <87si4x4m0d.fsf@smart-cactus.org> ????? ?????????? writes: > Hello Richard! > > Can you take a look at some sort of specification i wrote week ago? > I placed it here: > https://ghc.haskell.org/trac/ghc/wiki/Design/LocalWarningPragmas > I can imagine only two use cases, and i'm not sure about correcteness of it > Thanks for writing this up! The specification is a good start but it really needs more detail. For instance, what syntactic elements do you want this pragma to apply to? Bindings? Expressions? Top-level definitions like classes, types, and instances? Any lexical scope? It would be nice if the use-cases you mention were a bit more concrete. It wouldn't hurt to mention particular warnings that you might imagine that this would be useful for. It would likely be useful to draw inspiration from some of the schemes used by other languages listed on the ticket (Rust and C# IIRC). It wouldn't hurt to draw attention to the similarities and differences to these other schemes in the proposal text. On a more bike-shed-y note, `SUPPRESS_WARNINGS` is arguably a bit on the long side. Personally I would prefer not to see the pragma be bracketed as you propose in your last example as its effect then becomes quite "non-local". This pragma should, in my opinion, be a tool of precision, used sparingly for well-understood reasons. Allowing bracketed regions makes it too easy for definitions to "sneak in" to the supressed region, hiding legitimate warnings. In the interest of keeping the proposal concrete and concise I would either remove this alternative or move it to a dedicated "Alternatives" section. I'm looking forward to seeing what becomes of this. You might consider submitting the next iteration of the proposal to the Haskell subreddit to get a few more eyes on it. Onwards! 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 afarmer at ittc.ku.edu Mon Oct 26 16:59:03 2015 From: afarmer at ittc.ku.edu (Andrew Farmer) Date: Mon, 26 Oct 2015 09:59:03 -0700 Subject: [DISARMED] RE: Better calling conventions for strict functions (bang patterns)? In-Reply-To: References: Message-ID: Simon, I really enjoyed reading this paper... I was wondering if you could comment on the implementation of Strict Core? Was it ever implemented in GHC (even as a proof-of-concept)? If not, was it just due to a lack of time or some fundamental limitation or problem discovered after the paper? If it was implemented, was any benefit actually measured? Can you speculate on whether some of the more recent changes/additions to Core (such as coercions and roles) might fit into this? (I don't see any obvious reason they couldn't, but that is me.) Thanks! Andrew On Fri, Oct 23, 2015 at 7:11 AM, Simon Peyton Jones wrote: > It?s absolutely the case that bang patterns etc tell the caller what to > do, but the function CANNOT ASSUME that its argument is evaluated. Reason: > higher order functions. > > > > I think that the way to allow functions that can assume their arg is > evaluated is through types: see Type are calling conventions > . > But it?d be a fairly big deal to implement. > > > > Simon > > > > > > *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Ryan > Newton > *Sent:* 23 October 2015 14:54 > *To:* ghc-devs at haskell.org; ?mer Sinan A?acan; Ryan Scott; Chao-Hong > Chen; Johan Tibell > *Subject:* Better calling conventions for strict functions (bang > patterns)? > > > > Hi all, > > > > With module-level Strict and StrictData pragmas coming soon, one obvious > question is what kind of the code quality GHC can achieve for strict > programs. > > > > When it came up in discussion in our research group we realized we didn't > actually know whether the bang patterns, `f !x`, on function arguments were > enforced by caller or callee. > > > > Here's a Gist that shows the compilation of a trivial function: > > foo :: Maybe Int -> Int > > foo !x = > > case x of > > Just y -> y > > > > *MailScanner has detected a possible fraud attempt from > "na01.safelinks.protection.outlook.com" claiming to be* > https://gist.github.com/rrnewton/1ac722189c65f26fe9ac > > > > > If that function is compiled to *assume* its input is in WHNF, it should > be just as efficient as the isomorphic MLton/OCaml code, right? It only > needs to branch on the tag, do a field dereference, and return. > > > > But as you can see from the STG and CMM generated, foo *does indeed* > enter the thunk, adding an extra indirect jump. Here's the body: > > c3aY: > > if ((Sp + -8) < SpLim) goto c3aZ; else goto c3b0; > > c3aZ: > > // nop > > R1 = PicBaseReg + foo_closure; > > call (I64[BaseReg - 8])(R2, R1) args: 8, res: 0, upd: 8; > > c3b0: > > I64[Sp - 8] = PicBaseReg + block_c3aO_info; > > R1 = R2; > > Sp = Sp - 8; > > if (R1 & 7 != 0) goto c3aO; else goto c3aP; > > c3aP: > > call (I64[R1])(R1) returns to c3aO, args: 8, res: 8, upd: 8; > > c3aO: > > if (R1 & 7 >= 2) goto c3aW; else goto c3aX; > > c3aW: > > R1 = P64[R1 + 6] & (-8); > > Sp = Sp + 8; > > call (I64[R1])(R1) args: 8, res: 0, upd: 8; > > c3aX: > > R1 = PicBaseReg + lvl_r39S_closure; > > Sp = Sp + 8; > > call (I64[R1])(R1) args: 8, res: 0, upd: 8; > > > > > > The call inside c3aP is entering "x" as a thunk, which also incurs all of > the stack limit check code. I believe that IF the input could be assumed > to be in WHNF, everything above the label "c3aO" could be omitted. > > > > So... if GHC is going to be a fabulous pure *and* imperative language, > and a fabulous lazy *and* strict compiler/runtime.. is there some work we > can do here to improve this situation? Would the following make sense: > > - Put together a benchmark suite of all-strict programs with > Strict/StrictData (compare a few benchmark's generated code to MLton, if > time allows) > - Modify GHC to change calling conventions for bang patterns -- caller > enforces WHNF rather than callee. Existing strictness/demand/cardinality > analysis would stay the same. > > Unless there's something I'm really missing here, the result should be > that you can have a whole chain of strict function calls, each of which > knows its arguments and the arguments it passes to its callees are all in > WHNF, without ever generating thunk-entry sequences. > > > > Thanks for your time, > > -Ryan > > > > _______________________________________________ > 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 Mon Oct 26 17:23:20 2015 From: ben at well-typed.com (Ben Gamari) Date: Mon, 26 Oct 2015 18:23:20 +0100 Subject: Segfault in a CoreLinted program (and a GHC-generated Core question) In-Reply-To: References: Message-ID: <87oafl4k8n.fsf@smart-cactus.org> ?mer Sinan A?acan writes: > I have a very simple Core plugin that generates some functions. After my > Core-to-Core pass is done, I'm running the linter to make sure the Core > generated by my plugin is well-formed and well-typed. However, even though lint > checker passes, the code generated by my plugin is failing with a segfault. > ... > > So my questions are: Am I right in assuming that CoreLint accepted programs > should not segfault? What about internal invariants? Should CoreLint check for > those? Is there any pass that checks for invariants and prints helpful messages > in case of a invariant invalidation? > My understanding is that CoreLint should (in principle) check all internal invariants necessary to ensure the soundness of the Core. If a Core program passes CoreLint it ought not to segfault. It sounds like you found a bug in CoreLint. > As an attempt at debugging the code generated by my plugin, I wrote the > function that is supposed to be generated by my Core pass in Haskell and > compiled with GHC. Generated Core is mostly the same, except at one point it > has an extra lambda directly applied to a void#, something like ((\_ -> ...) > void#). Where can I learn more about why GHC is doing that? > Hmm, interesting. I'm afraid I'm not sure what semantics void# has in Core but it sure does sound fishy. Sadly grepping the source tree for clues doesn't turn much up. Simon, perhaps you could comment 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 simonpj at microsoft.com Mon Oct 26 17:43:09 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 26 Oct 2015 17:43:09 +0000 Subject: Segfault in a CoreLinted program (and a GHC-generated Core question) In-Reply-To: References: Message-ID: <8daefc4bfba5473f973e4e7a939b0c7a@DB4PR30MB030.064d.mgd.msft.net> | So my questions are: Am I right in assuming that CoreLint accepted programs | should not segfault? Yes. Modulo unsafeCoerce, and FFI calls. | What about internal invariants? Should CoreLint check | for those? Is there any pass that checks for invariants and prints helpful | messages in case of a invariant invalidation? Yes; they are documented in CoreSyn, which the data type, and Lint checks them. | As an attempt at debugging the code generated by my plugin, I wrote the | function that is supposed to be generated by my Core pass in Haskell and | compiled with GHC. Generated Core is mostly the same, except at one point it | has an extra lambda directly applied to a void#, something like ((\_ -> ...) | void#). Where can I learn more about why GHC is doing that? Show me the code! Instead of generating x :: Int# = GHC sometimes generates x :: Void# -> Int# = \_ - and then calls (x void#), to make any div-zero failures happen at the right place. I'm not sure if that is what you are seeing, but we can work it out when you give more detail. Simon From simonpj at microsoft.com Mon Oct 26 17:43:46 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 26 Oct 2015 17:43:46 +0000 Subject: [DISARMED] RE: Better calling conventions for strict functions (bang patterns)? In-Reply-To: References: Message-ID: <3f7822b858d84a37b983c1200343775c@DB4PR30MB030.064d.mgd.msft.net> I?m glad you liked it! No, I don?t think it was ever implemented. I don?t think coercions will be a problem. Simon From: xichekolas at gmail.com [mailto:xichekolas at gmail.com] On Behalf Of Andrew Farmer Sent: 26 October 2015 16:59 To: Simon Peyton Jones Cc: ghc-devs at haskell.org Subject: Re: [DISARMED] RE: Better calling conventions for strict functions (bang patterns)? Simon, I really enjoyed reading this paper... I was wondering if you could comment on the implementation of Strict Core? Was it ever implemented in GHC (even as a proof-of-concept)? If not, was it just due to a lack of time or some fundamental limitation or problem discovered after the paper? If it was implemented, was any benefit actually measured? Can you speculate on whether some of the more recent changes/additions to Core (such as coercions and roles) might fit into this? (I don't see any obvious reason they couldn't, but that is me.) Thanks! Andrew On Fri, Oct 23, 2015 at 7:11 AM, Simon Peyton Jones > wrote: It?s absolutely the case that bang patterns etc tell the caller what to do, but the function CANNOT ASSUME that its argument is evaluated. Reason: higher order functions. I think that the way to allow functions that can assume their arg is evaluated is through types: see Type are calling conventions. But it?d be a fairly big deal to implement. Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Ryan Newton Sent: 23 October 2015 14:54 To: ghc-devs at haskell.org; ?mer Sinan A?acan; Ryan Scott; Chao-Hong Chen; Johan Tibell Subject: Better calling conventions for strict functions (bang patterns)? Hi all, With module-level Strict and StrictData pragmas coming soon, one obvious question is what kind of the code quality GHC can achieve for strict programs. When it came up in discussion in our research group we realized we didn't actually know whether the bang patterns, `f !x`, on function arguments were enforced by caller or callee. Here's a Gist that shows the compilation of a trivial function: foo :: Maybe Int -> Int foo !x = case x of Just y -> y MailScanner has detected a possible fraud attempt from "na01.safelinks.protection.outlook.com" claiming to be https://gist.github.com/rrnewton/1ac722189c65f26fe9ac If that function is compiled to *assume* its input is in WHNF, it should be just as efficient as the isomorphic MLton/OCaml code, right? It only needs to branch on the tag, do a field dereference, and return. But as you can see from the STG and CMM generated, foo does indeed enter the thunk, adding an extra indirect jump. Here's the body: c3aY: if ((Sp + -8) < SpLim) goto c3aZ; else goto c3b0; c3aZ: // nop R1 = PicBaseReg + foo_closure; call (I64[BaseReg - 8])(R2, R1) args: 8, res: 0, upd: 8; c3b0: I64[Sp - 8] = PicBaseReg + block_c3aO_info; R1 = R2; Sp = Sp - 8; if (R1 & 7 != 0) goto c3aO; else goto c3aP; c3aP: call (I64[R1])(R1) returns to c3aO, args: 8, res: 8, upd: 8; c3aO: if (R1 & 7 >= 2) goto c3aW; else goto c3aX; c3aW: R1 = P64[R1 + 6] & (-8); Sp = Sp + 8; call (I64[R1])(R1) args: 8, res: 0, upd: 8; c3aX: R1 = PicBaseReg + lvl_r39S_closure; Sp = Sp + 8; call (I64[R1])(R1) args: 8, res: 0, upd: 8; The call inside c3aP is entering "x" as a thunk, which also incurs all of the stack limit check code. I believe that IF the input could be assumed to be in WHNF, everything above the label "c3aO" could be omitted. So... if GHC is going to be a fabulous pure and imperative language, and a fabulous lazy and strict compiler/runtime.. is there some work we can do here to improve this situation? Would the following make sense: * Put together a benchmark suite of all-strict programs with Strict/StrictData (compare a few benchmark's generated code to MLton, if time allows) * Modify GHC to change calling conventions for bang patterns -- caller enforces WHNF rather than callee. Existing strictness/demand/cardinality analysis would stay the same. Unless there's something I'm really missing here, the result should be that you can have a whole chain of strict function calls, each of which knows its arguments and the arguments it passes to its callees are all in WHNF, without ever generating thunk-entry sequences. Thanks for your time, -Ryan _______________________________________________ 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 Mon Oct 26 17:48:17 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 26 Oct 2015 17:48:17 +0000 Subject: can't get haddock patch Message-ID: Ben What does this mean? (below) Does it mean you have not pushed something to the haddock repo> This happens when I'm on branch wip/T9858-typeable-ben2, in the main repo Simon git submodule update fatal: reference is not a tree: 289ef817aad02c341beb6d4c28ba0495872f5a0f Unable to checkout '289ef817aad02c341beb6d4c28ba0495872f5a0f' in submodule path 'utils/haddock' simonpj at cam-05-unx:~/code/HEAD-2$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Mon Oct 26 18:55:42 2015 From: ben at well-typed.com (Ben Gamari) Date: Mon, 26 Oct 2015 19:55:42 +0100 Subject: can't get haddock patch In-Reply-To: References: Message-ID: <874mhdzcgh.fsf@smart-cactus.org> Simon Peyton Jones writes: > Ben > What does this mean? (below) Does it mean you have not pushed something to the haddock repo> > This happens when I'm on branch wip/T9858-typeable-ben2, in the main repo > > Simon > > git submodule update > > fatal: reference is not a tree: 289ef817aad02c341beb6d4c28ba0495872f5a0f > This means that the commit listed doesn't appear to be a commit in the `haddock` repository. I suspect I forgot to point out that the haddock changes are available in my Haddock repository on Github [1]. You would have needed to do something like this to see them, $ cd utils/haddock $ git remote add bgamari git://github.com/bgamari/haddock $ git remote update At which point you would have commit in question and could try `git submodule update` again. Regardless, I can take care of it from here. Cheers, - Ben [1] https://github.com/bgamari/haddock/tree/T9858 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From edzhavoronkov at gmail.com Mon Oct 26 18:59:24 2015 From: edzhavoronkov at gmail.com (=?UTF-8?B?0K3QtNCz0LDRgCDQltCw0LLQvtGA0L7QvdC60L7Qsg==?=) Date: Mon, 26 Oct 2015 21:59:24 +0300 Subject: Warning suppression pragmas In-Reply-To: <87si4x4m0d.fsf@smart-cactus.org> References: <87si4x4m0d.fsf@smart-cactus.org> Message-ID: Hi Ben! Thanks for your feedback I thought a little and fixed some in wiki page In my opinion SUPPRESS_WARNINGS is not a real long name for pragma, but i can't come up with whort name that clearly describes purpose of such pragma =( Your suggestions are really welcome) --- ? ?????????, ?????????? ????? Best regards, Edgar A. Zhavoronkov 2015-10-26 19:45 GMT+03:00 Ben Gamari : > ????? ?????????? writes: > > > Hello Richard! > > > > Can you take a look at some sort of specification i wrote week ago? > > I placed it here: > > https://ghc.haskell.org/trac/ghc/wiki/Design/LocalWarningPragmas > > I can imagine only two use cases, and i'm not sure about correcteness of > it > > > Thanks for writing this up! > > The specification is a good start but it really needs more detail. For > instance, what syntactic elements do you want this pragma to apply to? > Bindings? Expressions? Top-level definitions like classes, types, and > instances? Any lexical scope? > > It would be nice if the use-cases you mention were a bit more concrete. > It wouldn't hurt to mention particular warnings that you might imagine > that this would be useful for. > > It would likely be useful to draw inspiration from some of the schemes > used by other languages listed on the ticket (Rust and C# IIRC). It > wouldn't hurt to draw attention to the similarities and differences to > these other schemes in the proposal text. > > On a more bike-shed-y note, `SUPPRESS_WARNINGS` is arguably a bit on the > long side. > > Personally I would prefer not to see the pragma be bracketed as you > propose in your last example as its effect then becomes quite > "non-local". This pragma should, in my opinion, be a tool of precision, > used sparingly for well-understood reasons. Allowing bracketed regions > makes it too easy for definitions to "sneak in" to the supressed region, > hiding legitimate warnings. In the interest of keeping the proposal > concrete and concise I would either remove this alternative or move it > to a dedicated "Alternatives" section. > > I'm looking forward to seeing what becomes of this. You might consider > submitting the next iteration of the proposal to the Haskell subreddit > to get a few more eyes on it. Onwards! > > Cheers, > > - Ben > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Mon Oct 26 19:42:20 2015 From: ezyang at mit.edu (Edward Z. Yang) Date: Mon, 26 Oct 2015 12:42:20 -0700 Subject: recomp013 In-Reply-To: References: Message-ID: <1445888515-sup-31@sabre> I couldn't repro on a devel2 build. Edward Excerpts from Simon Peyton Jones's message of 2015-10-26 08:24:00 -0700: > driver/recomp013 is failing, on Linux, on HEAD for me: > > Actual stdout output differs from expected: > > --- ./driver/recomp013/recomp013.stdout.normalised 2015-10-26 14:26:51.920153558 +0000 > > +++ ./driver/recomp013/recomp013.run.stdout.normalised 2015-10-26 14:26:51.920153558 +0000 > > @@ -3,5 +3,3 @@ > > [2 of 3] Compiling B ( B.hs, B.o ) > > [3 of 3] Compiling C ( C.hs, C.o ) > > second run > > -[2 of 3] Compiling B ( B.hs, B.o ) > > -[3 of 3] Compiling C ( C.hs, C.o ) [B changed] From ben at well-typed.com Mon Oct 26 20:01:02 2015 From: ben at well-typed.com (Ben Gamari) Date: Mon, 26 Oct 2015 21:01:02 +0100 Subject: recomp013 In-Reply-To: <1445888515-sup-31@sabre> References: <1445888515-sup-31@sabre> Message-ID: <87eggh4cxt.fsf@smart-cactus.org> "Edward Z. Yang" writes: > I couldn't repro on a devel2 build. > I also haven't seen this in my recent builds. I'll keep an eye out for it though. 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 rasen.dubi at gmail.com Mon Oct 26 20:59:46 2015 From: rasen.dubi at gmail.com (Alexey Shmalko) Date: Mon, 26 Oct 2015 22:59:46 +0200 Subject: Warning suppression pragmas In-Reply-To: References: <87si4x4m0d.fsf@smart-cactus.org> Message-ID: Hi! I think SUPPRESS could be enough. Hope this helps On Mon, Oct 26, 2015 at 8:59 PM, ????? ?????????? wrote: > Hi Ben! > Thanks for your feedback > I thought a little and fixed some in wiki page > > In my opinion SUPPRESS_WARNINGS is not a real long name for pragma, but i > can't come up with whort name that clearly describes purpose of such pragma > =( > Your suggestions are really welcome) > > --- > ? ?????????, > ?????????? ????? > > Best regards, > Edgar A. Zhavoronkov > > 2015-10-26 19:45 GMT+03:00 Ben Gamari : >> >> ????? ?????????? writes: >> >> > Hello Richard! >> > >> > Can you take a look at some sort of specification i wrote week ago? >> > I placed it here: >> > https://ghc.haskell.org/trac/ghc/wiki/Design/LocalWarningPragmas >> > I can imagine only two use cases, and i'm not sure about correcteness of >> > it >> > >> Thanks for writing this up! >> >> The specification is a good start but it really needs more detail. For >> instance, what syntactic elements do you want this pragma to apply to? >> Bindings? Expressions? Top-level definitions like classes, types, and >> instances? Any lexical scope? >> >> It would be nice if the use-cases you mention were a bit more concrete. >> It wouldn't hurt to mention particular warnings that you might imagine >> that this would be useful for. >> >> It would likely be useful to draw inspiration from some of the schemes >> used by other languages listed on the ticket (Rust and C# IIRC). It >> wouldn't hurt to draw attention to the similarities and differences to >> these other schemes in the proposal text. >> >> On a more bike-shed-y note, `SUPPRESS_WARNINGS` is arguably a bit on the >> long side. >> >> Personally I would prefer not to see the pragma be bracketed as you >> propose in your last example as its effect then becomes quite >> "non-local". This pragma should, in my opinion, be a tool of precision, >> used sparingly for well-understood reasons. Allowing bracketed regions >> makes it too easy for definitions to "sneak in" to the supressed region, >> hiding legitimate warnings. In the interest of keeping the proposal >> concrete and concise I would either remove this alternative or move it >> to a dedicated "Alternatives" section. >> >> I'm looking forward to seeing what becomes of this. You might consider >> submitting the next iteration of the proposal to the Haskell subreddit >> to get a few more eyes on it. Onwards! >> >> Cheers, >> >> - Ben >> > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From edzhavoronkov at gmail.com Mon Oct 26 21:11:15 2015 From: edzhavoronkov at gmail.com (=?UTF-8?B?0K3QtNCz0LDRgCDQltCw0LLQvtGA0L7QvdC60L7Qsg==?=) Date: Tue, 27 Oct 2015 00:11:15 +0300 Subject: Warning suppression pragmas In-Reply-To: References: <87si4x4m0d.fsf@smart-cactus.org> Message-ID: Hello everyone once again! Am i right, that in case in need to define my own pragma in GHC, i need to add it to lexer? How can i understand that GHC recognizes my defined pragma? I am experimenting on my local machine and i want to try something out --- ? ?????????, ?????????? ????? Best regards, Edgar A. Zhavoronkov 2015-10-26 21:59 GMT+03:00 ????? ?????????? : > Hi Ben! > Thanks for your feedback > I thought a little and fixed some in wiki page > > In my opinion SUPPRESS_WARNINGS is not a real long name for pragma, but i > can't come up with whort name that clearly describes purpose of such pragma > =( > Your suggestions are really welcome) > > --- > ? ?????????, > ?????????? ????? > > Best regards, > Edgar A. Zhavoronkov > > 2015-10-26 19:45 GMT+03:00 Ben Gamari : > >> ????? ?????????? writes: >> >> > Hello Richard! >> > >> > Can you take a look at some sort of specification i wrote week ago? >> > I placed it here: >> > https://ghc.haskell.org/trac/ghc/wiki/Design/LocalWarningPragmas >> > I can imagine only two use cases, and i'm not sure about correcteness >> of it >> > >> Thanks for writing this up! >> >> The specification is a good start but it really needs more detail. For >> instance, what syntactic elements do you want this pragma to apply to? >> Bindings? Expressions? Top-level definitions like classes, types, and >> instances? Any lexical scope? >> >> It would be nice if the use-cases you mention were a bit more concrete. >> It wouldn't hurt to mention particular warnings that you might imagine >> that this would be useful for. >> >> It would likely be useful to draw inspiration from some of the schemes >> used by other languages listed on the ticket (Rust and C# IIRC). It >> wouldn't hurt to draw attention to the similarities and differences to >> these other schemes in the proposal text. >> >> On a more bike-shed-y note, `SUPPRESS_WARNINGS` is arguably a bit on the >> long side. >> >> Personally I would prefer not to see the pragma be bracketed as you >> propose in your last example as its effect then becomes quite >> "non-local". This pragma should, in my opinion, be a tool of precision, >> used sparingly for well-understood reasons. Allowing bracketed regions >> makes it too easy for definitions to "sneak in" to the supressed region, >> hiding legitimate warnings. In the interest of keeping the proposal >> concrete and concise I would either remove this alternative or move it >> to a dedicated "Alternatives" section. >> >> I'm looking forward to seeing what becomes of this. You might consider >> submitting the next iteration of the proposal to the Haskell subreddit >> to get a few more eyes on it. Onwards! >> >> Cheers, >> >> - Ben >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Oct 26 21:19:23 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 26 Oct 2015 21:19:23 +0000 Subject: Can't build on Windows Message-ID: Gurgah. GHC is broken on my windows laptop. See below. Anyone have any ideas? Frustrating. Oddly the symbol is defined in the .exe bash$ nm inplace/bin/ghc-stage2.exe | grep stg_upd_frame 02c248e0 T _stg_upd_frame_info This is admittedly on a branch that I have modified; but I have only modified stuff in the front end, nothing in the RTS etc. I suppose I will try to build a unmodified HEAD too. can anyone help? Thanks! Simon bash$ c:/code/HEAD/inplace/bin/ghc-stage2 --interactive GHCi, version 7.11.20151026: http://www.haskell.org/ghc/ :? for help ghc-stage2.exe: unable to load package `ghc-prim-0.4.0.0' ghc-stage2.exe: C:\code\HEAD\libraries\ghc-prim\dist-install\build\HSghc-prim-0.4.0.0.o: unknown symbol `_stg_upd_frame_info' HEAD $ -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Oct 26 21:23:03 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 26 Oct 2015 21:23:03 +0000 Subject: can't get haddock patch In-Reply-To: <874mhdzcgh.fsf@smart-cactus.org> References: <874mhdzcgh.fsf@smart-cactus.org> Message-ID: <95db4289c94a44c29318eaa77642b6d1@DB4PR30MB030.064d.mgd.msft.net> | Regardless, I can take care of it from here. great. But I could not validate because of this, so may not be finished. Would it make sense to push changes to the haddock repo (as I have done for my other inflight changes)? Anyway, if you'd like me to take this any further, let me know explicitly, with instructions for how to build. Thakns Simon | -----Original Message----- | From: Ben Gamari [mailto:ben at well-typed.com] | Sent: 26 October 2015 18:56 | To: Simon Peyton Jones | Cc: ghc-devs at haskell.org | Subject: Re: can't get haddock patch | | Simon Peyton Jones writes: | | > Ben | > What does this mean? (below) Does it mean you have not pushed something | to the haddock repo> | > This happens when I'm on branch wip/T9858-typeable-ben2, in the main | repo | > | > Simon | > | > git submodule update | > | > fatal: reference is not a tree: 289ef817aad02c341beb6d4c28ba0495872f5a0f | > | This means that the commit listed doesn't appear to be a commit in the | `haddock` repository. | | I suspect I forgot to point out that the haddock changes are available | in my Haddock repository on Github [1]. You would have needed to do | something like this to see them, | | $ cd utils/haddock | $ git remote add bgamari git://github.com/bgamari/haddock | $ git remote update | | At which point you would have commit in question and could try `git | submodule update` again. | | Regardless, I can take care of it from here. | | Cheers, | | - Ben | | | [1] https://github.com/bgamari/haddock/tree/T9858 From simonpj at microsoft.com Mon Oct 26 23:25:15 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 26 Oct 2015 23:25:15 +0000 Subject: Can't build on Windows In-Reply-To: References: Message-ID: <7e805c7ce187493c9b7bae89c07dbc1a@DB4PR30MB030.064d.mgd.msft.net> It happens with unmodified HEAD too. Sigh. Can anyone help? Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Simon Peyton Jones Sent: 26 October 2015 21:19 To: ghc-devs at haskell.org Subject: Can't build on Windows Gurgah. GHC is broken on my windows laptop. See below. Anyone have any ideas? Frustrating. Oddly the symbol is defined in the .exe bash$ nm inplace/bin/ghc-stage2.exe | grep stg_upd_frame 02c248e0 T _stg_upd_frame_info This is admittedly on a branch that I have modified; but I have only modified stuff in the front end, nothing in the RTS etc. I suppose I will try to build a unmodified HEAD too. can anyone help? Thanks! Simon bash$ c:/code/HEAD/inplace/bin/ghc-stage2 --interactive GHCi, version 7.11.20151026: http://www.haskell.org/ghc/ :? for help ghc-stage2.exe: unable to load package `ghc-prim-0.4.0.0' ghc-stage2.exe: C:\code\HEAD\libraries\ghc-prim\dist-install\build\HSghc-prim-0.4.0.0.o: unknown symbol `_stg_upd_frame_info' HEAD $ -------------- next part -------------- An HTML attachment was scrubbed... URL: From howard_b_golden at yahoo.com Mon Oct 26 23:35:27 2015 From: howard_b_golden at yahoo.com (Howard B. Golden) Date: Mon, 26 Oct 2015 16:35:27 -0700 Subject: Warning suppression pragmas In-Reply-To: References: <87si4x4m0d.fsf@smart-cactus.org> Message-ID: <33F81532-8E7E-4873-A859-B6AA301DD664@yahoo.com> On US TV, Archie Bunker said "Stifle!" Howard > On Oct 26, 2015, at 1:59 PM, Alexey Shmalko wrote: > > Hi! > > I think SUPPRESS could be enough. > > Hope this helps > > On Mon, Oct 26, 2015 at 8:59 PM, ????? ?????????? > wrote: >> Hi Ben! >> Thanks for your feedback >> I thought a little and fixed some in wiki page >> >> In my opinion SUPPRESS_WARNINGS is not a real long name for pragma, but i >> can't come up with whort name that clearly describes purpose of such pragma >> =( >> Your suggestions are really welcome) >> >> --- >> ? ?????????, >> ?????????? ????? >> >> Best regards, >> Edgar A. Zhavoronkov >> >> 2015-10-26 19:45 GMT+03:00 Ben Gamari : >>> >>> ????? ?????????? writes: >>> >>>> Hello Richard! >>>> >>>> Can you take a look at some sort of specification i wrote week ago? >>>> I placed it here: >>>> https://ghc.haskell.org/trac/ghc/wiki/Design/LocalWarningPragmas >>>> I can imagine only two use cases, and i'm not sure about correcteness of >>>> it >>> Thanks for writing this up! >>> >>> The specification is a good start but it really needs more detail. For >>> instance, what syntactic elements do you want this pragma to apply to? >>> Bindings? Expressions? Top-level definitions like classes, types, and >>> instances? Any lexical scope? >>> >>> It would be nice if the use-cases you mention were a bit more concrete. >>> It wouldn't hurt to mention particular warnings that you might imagine >>> that this would be useful for. >>> >>> It would likely be useful to draw inspiration from some of the schemes >>> used by other languages listed on the ticket (Rust and C# IIRC). It >>> wouldn't hurt to draw attention to the similarities and differences to >>> these other schemes in the proposal text. >>> >>> On a more bike-shed-y note, `SUPPRESS_WARNINGS` is arguably a bit on the >>> long side. >>> >>> Personally I would prefer not to see the pragma be bracketed as you >>> propose in your last example as its effect then becomes quite >>> "non-local". This pragma should, in my opinion, be a tool of precision, >>> used sparingly for well-understood reasons. Allowing bracketed regions >>> makes it too easy for definitions to "sneak in" to the supressed region, >>> hiding legitimate warnings. In the interest of keeping the proposal >>> concrete and concise I would either remove this alternative or move it >>> to a dedicated "Alternatives" section. >>> >>> I'm looking forward to seeing what becomes of this. You might consider >>> submitting the next iteration of the proposal to the Haskell subreddit >>> to get a few more eyes on it. Onwards! >>> >>> Cheers, >>> >>> - Ben >> >> >> _______________________________________________ >> 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 austin at well-typed.com Mon Oct 26 23:36:51 2015 From: austin at well-typed.com (Austin Seipp) Date: Mon, 26 Oct 2015 18:36:51 -0500 Subject: Can't build on Windows In-Reply-To: References: Message-ID: (Resending to list properly) Hrm, I can't see anything off hand in the past few weeks that would have caused this at a glance. Can you try bisecting it perhaps? You can probably do something like: $ git bisect start $ git bisect bad $ git bisect good dcc342870b4d8a739ccbed3ae26e84dcc3579914 $ git bisect run ./validate This will probably take a while, though. The commit 'dcc342870b4d8a739ccbed3ae26e84dcc3579914' was chosen randomly, however. Any idea when this started happening? If it's the past few weeks, the above might work On Mon, Oct 26, 2015 at 4:19 PM, Simon Peyton Jones wrote: > Gurgah. GHC is broken on my windows laptop. See below. Anyone have any > ideas? Frustrating. > > Oddly the symbol is defined in the .exe > > bash$ nm inplace/bin/ghc-stage2.exe | grep stg_upd_frame > > 02c248e0 T _stg_upd_frame_info > > This is admittedly on a branch that I have modified; but I have only > modified stuff in the front end, nothing in the RTS etc. I suppose I will > try to build a unmodified HEAD too. > > can anyone help? Thanks! > > Simon > > > > bash$ c:/code/HEAD/inplace/bin/ghc-stage2 --interactive > > GHCi, version 7.11.20151026: http://www.haskell.org/ghc/ :? for help > > ghc-stage2.exe: unable to load package `ghc-prim-0.4.0.0' > > ghc-stage2.exe: > C:\code\HEAD\libraries\ghc-prim\dist-install\build\HSghc-prim-0.4.0.0.o: > unknown symbol `_stg_upd_frame_info' > > HEAD $ > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From simonpj at microsoft.com Mon Oct 26 23:44:39 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 26 Oct 2015 23:44:39 +0000 Subject: Can't build on Windows In-Reply-To: References: Message-ID: <9b9548c274ef4359b964651e9393ccb7@DB4PR30MB030.064d.mgd.msft.net> But don't our windows buildbots do this for us? Surely! That's what they are for. Me bisecting on my little laptop is not a very happy situation. Don't we have better technology? Simon | -----Original Message----- | From: mad.one at gmail.com [mailto:mad.one at gmail.com] On Behalf Of Austin | Seipp | Sent: 26 October 2015 23:37 | To: Simon Peyton Jones | Cc: ghc-devs at haskell.org | Subject: Re: Can't build on Windows | | (Resending to list properly) | | Hrm, I can't see anything off hand in the past few weeks that would | have caused this at a glance. | | Can you try bisecting it perhaps? You can probably do something like: | | $ git bisect start | $ git bisect bad | $ git bisect good dcc342870b4d8a739ccbed3ae26e84dcc3579914 | $ git bisect run ./validate | | This will probably take a while, though. | | The commit 'dcc342870b4d8a739ccbed3ae26e84dcc3579914' was chosen | randomly, however. Any idea when this started happening? If it's the | past few weeks, the above might work | | On Mon, Oct 26, 2015 at 4:19 PM, Simon Peyton Jones | wrote: | > Gurgah. GHC is broken on my windows laptop. See below. Anyone have | any | > ideas? Frustrating. | > | > Oddly the symbol is defined in the .exe | > | > bash$ nm inplace/bin/ghc-stage2.exe | grep stg_upd_frame | > | > 02c248e0 T _stg_upd_frame_info | > | > This is admittedly on a branch that I have modified; but I have only | > modified stuff in the front end, nothing in the RTS etc. I suppose I | will | > try to build a unmodified HEAD too. | > | > can anyone help? Thanks! | > | > Simon | > | > | > | > bash$ c:/code/HEAD/inplace/bin/ghc-stage2 --interactive | > | > GHCi, version 7.11.20151026: | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.haskell | .org%2fghc%2f&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c0ddd3793727 | 34905b9e108d2de5e53ad%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=qOu5IQhF | 9zwGyKO5nvAirOIC%2faHswQxRUDkSUQZGBGo%3d :? for help | > | > ghc-stage2.exe: unable to load package `ghc-prim-0.4.0.0' | > | > ghc-stage2.exe: | > C:\code\HEAD\libraries\ghc-prim\dist-install\build\HSghc-prim-0.4.0.0.o: | > unknown symbol `_stg_upd_frame_info' | > | > HEAD $ | > | > | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs at haskell.org | > | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskel | l.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c0ddd379372734905b9e1 | 08d2de5e53ad%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=q0prCf7bCbf3hCv0S | wWCQ1Ps%2b4zJB31rMF34n%2fhBq0I%3d | > | | | | -- | Regards, | | Austin Seipp, Haskell Consultant | Well-Typed LLP, | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.well- | typed.com%2f&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c0ddd37937273 | 4905b9e108d2de5e53ad%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=jbueQwg9b | CXMVdExfCrBmk9FIfLit2W5GZJNoKIGF8c%3d From omeragacan at gmail.com Mon Oct 26 23:57:19 2015 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Mon, 26 Oct 2015 19:57:19 -0400 Subject: Segfault in a CoreLinted program (and a GHC-generated Core question) In-Reply-To: <8daefc4bfba5473f973e4e7a939b0c7a@DB4PR30MB030.064d.mgd.msft.net> References: <8daefc4bfba5473f973e4e7a939b0c7a@DB4PR30MB030.064d.mgd.msft.net> Message-ID: OK, thanks to people at IRC channel(especially @rwbarton) I realized that my lint calls were not actually running, simply because I wasn't using -dcore-lint.. I didn't know such a flag exists, and even with the absence of the flag I'd expect a core lint would work, because I'm explicitly calling the lint function without checking any flags! CoreLint is now giving me really awesome diagnostics! Sorry for the noise.. (I'll try to document linter functions or CoreLint module to let the user know he/she needs this flag!) 2015-10-26 13:43 GMT-04:00 Simon Peyton Jones : > | So my questions are: Am I right in assuming that CoreLint accepted programs > | should not segfault? > > Yes. Modulo unsafeCoerce, and FFI calls. > > | What about internal invariants? Should CoreLint check > | for those? Is there any pass that checks for invariants and prints helpful > | messages in case of a invariant invalidation? > > Yes; they are documented in CoreSyn, which the data type, and Lint checks them. > > | As an attempt at debugging the code generated by my plugin, I wrote the > | function that is supposed to be generated by my Core pass in Haskell and > | compiled with GHC. Generated Core is mostly the same, except at one point it > | has an extra lambda directly applied to a void#, something like ((\_ -> ...) > | void#). Where can I learn more about why GHC is doing that? > > Show me the code! > > Instead of generating > > x :: Int# = > > GHC sometimes generates > > x :: Void# -> Int# = \_ - > > and then calls (x void#), to make any div-zero failures happen at the right place. > > I'm not sure if that is what you are seeing, but we can work it out when you give more detail. > > Simon From thomasmiedema at gmail.com Tue Oct 27 00:54:35 2015 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Tue, 27 Oct 2015 01:54:35 +0100 Subject: Can't build on Windows In-Reply-To: References: Message-ID: I can not reproduce this on 64bit Windows, a9c93bdd8b027d6de09a3eada7721e7fd2d3e050 builds succesfully with flavour devel2. * Which build flavour are you using? Any other mk/build.mk settings? * 32bit or 64bit? * Output of `git status` (i.e. did you 'git submodule update'? In case that fixes it, I suggest you use git pullall for all your pulling needs) * Try `make maintainer-clean`. * In case you use llvm, note that HEAD needs llvm-3.7 now. On Mon, Oct 26, 2015 at 10:19 PM, Simon Peyton Jones wrote: > Gurgah. GHC is broken on my windows laptop. See below. Anyone have any > ideas? Frustrating. > > Oddly the symbol is defined in the .exe > > bash$ nm inplace/bin/ghc-stage2.exe | grep stg_upd_frame > > 02c248e0 T _stg_upd_frame_info > > This is admittedly on a branch that I have modified; but I have only > modified stuff in the front end, nothing in the RTS etc. I suppose I will > try to build a unmodified HEAD too. > > can anyone help? Thanks! > > Simon > > > > bash$ c:/code/HEAD/inplace/bin/ghc-stage2 --interactive > > GHCi, version 7.11.20151026: http://www.haskell.org/ghc/ :? for help > > ghc-stage2.exe: unable to load package `ghc-prim-0.4.0.0' > > ghc-stage2.exe: > C:\code\HEAD\libraries\ghc-prim\dist-install\build\HSghc-prim-0.4.0.0.o: > unknown symbol `_stg_upd_frame_info' > > HEAD $ > > _______________________________________________ > 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 ezyang at mit.edu Tue Oct 27 01:50:31 2015 From: ezyang at mit.edu (Edward Z. Yang) Date: Mon, 26 Oct 2015 18:50:31 -0700 Subject: Can't build on Windows In-Reply-To: References: Message-ID: <1445910621-sup-6067@sabre> Same here, can't reproduce on 64bit Windows 10. Edward Excerpts from Thomas Miedema's message of 2015-10-26 17:54:35 -0700: > I can not reproduce this on 64bit > Windows, a9c93bdd8b027d6de09a3eada7721e7fd2d3e050 builds succesfully with > flavour devel2. > > * Which build flavour are you using? Any other mk/build.mk settings? > * 32bit or 64bit? > * Output of `git status` (i.e. did you 'git submodule update'? In case that > fixes it, I suggest you use git pullall > > for > all your pulling needs) > * Try `make maintainer-clean`. > * In case you use llvm, note that HEAD needs llvm-3.7 now. > > > > On Mon, Oct 26, 2015 at 10:19 PM, Simon Peyton Jones > wrote: > > > Gurgah. GHC is broken on my windows laptop. See below. Anyone have any > > ideas? Frustrating. > > > > Oddly the symbol is defined in the .exe > > > > bash$ nm inplace/bin/ghc-stage2.exe | grep stg_upd_frame > > > > 02c248e0 T _stg_upd_frame_info > > > > This is admittedly on a branch that I have modified; but I have only > > modified stuff in the front end, nothing in the RTS etc. I suppose I will > > try to build a unmodified HEAD too. > > > > can anyone help? Thanks! > > > > Simon > > > > > > > > bash$ c:/code/HEAD/inplace/bin/ghc-stage2 --interactive > > > > GHCi, version 7.11.20151026: http://www.haskell.org/ghc/ :? for help > > > > ghc-stage2.exe: unable to load package `ghc-prim-0.4.0.0' > > > > ghc-stage2.exe: > > C:\code\HEAD\libraries\ghc-prim\dist-install\build\HSghc-prim-0.4.0.0.o: > > unknown symbol `_stg_upd_frame_info' > > > > HEAD $ > > > > _______________________________________________ > > 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 Oct 27 08:07:49 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 27 Oct 2015 08:07:49 +0000 Subject: Can't build on Windows In-Reply-To: References: Message-ID: ? I was using ?sh validate?. Incidentally, does that still use validate.mk, are-validating.mk etc? Or is all that gone now, in which case if I want to modify the validate settings what do I do? ? 32 vs 64 bit? How do I find out? I?m on a 64-bit processor, but for all I know I?m building GHC with 32 bit stuff. How would I tell? ? `git submodule update? appeared not to do anything ? I?m on a9c93b as well, same as you I?ll try ?make maintainer-clean?. Am I using LLVM? I don?t know. I?m just saying ?sh validate?. How would I install LLVM? The Windows preparation page is silent on that. https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows Incidentally, the stage2 compiler can build statically-linked binaries; it?s just ghc-stage2 ?interactive that immediately fails with the error below. How could I investigate the actual error more directly? Trying random things around the side is good, but so is directly investigating the cause, if only I knew how. Thanks! Simon From: Thomas Miedema [mailto:thomasmiedema at gmail.com] Sent: 27 October 2015 00:55 To: Simon Peyton Jones Cc: ghc-devs at haskell.org Subject: Re: Can't build on Windows I can not reproduce this on 64bit Windows, a9c93bdd8b027d6de09a3eada7721e7fd2d3e050 builds succesfully with flavour devel2. * Which build flavour are you using? Any other mk/build.mk settings? * 32bit or 64bit? * Output of `git status` (i.e. did you 'git submodule update'? In case that fixes it, I suggest you use git pullall for all your pulling needs) * Try `make maintainer-clean`. * In case you use llvm, note that HEAD needs llvm-3.7 now. On Mon, Oct 26, 2015 at 10:19 PM, Simon Peyton Jones > wrote: Gurgah. GHC is broken on my windows laptop. See below. Anyone have any ideas? Frustrating. Oddly the symbol is defined in the .exe bash$ nm inplace/bin/ghc-stage2.exe | grep stg_upd_frame 02c248e0 T _stg_upd_frame_info This is admittedly on a branch that I have modified; but I have only modified stuff in the front end, nothing in the RTS etc. I suppose I will try to build a unmodified HEAD too. can anyone help? Thanks! Simon bash$ c:/code/HEAD/inplace/bin/ghc-stage2 --interactive GHCi, version 7.11.20151026: http://www.haskell.org/ghc/ :? for help ghc-stage2.exe: unable to load package `ghc-prim-0.4.0.0' ghc-stage2.exe: C:\code\HEAD\libraries\ghc-prim\dist-install\build\HSghc-prim-0.4.0.0.o: unknown symbol `_stg_upd_frame_info' HEAD $ _______________________________________________ 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 Oct 27 09:06:10 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 27 Oct 2015 09:06:10 +0000 Subject: dll-split Message-ID: It's just not my day. Now, on Linux, on my branch wip/spj-wildcard-refactor, I get a failure in dll-split! Should dll-split be running at all on Linux???? The output it produces is below. I'm totally stuck. Help desperately needed. Simon inplace/bin/dll-split compiler/stage2/build/.depend-v-p-dyn.haskell "DynFlags" "Annotations ApiAnnotation Avail Bag BasicTypes Binary BooleanFormula BreakArray BufWrite Class CmdLineParser CmmType CoAxiom ConLike Coercion Config Constants CoreArity CoreFVs CoreSubst CoreSyn CoreTidy CoreUnfold CoreUtils CoreSeq CoreStats CostCentre Ctype DataCon Demand Digraph DriverPhases DynFlags Encoding ErrUtils Exception FamInstEnv FastFunctions FastMutInt FastString FastStringEnv FieldLabel Fingerprint FiniteMap ForeignCall Hooks HsBinds HsDecls HsDoc HsExpr HsImpExp HsLit PlaceHolder HsPat HsSyn HsTypes HsUtils HscTypes IOEnv Id IdInfo IfaceSyn IfaceType InstEnv Kind Lexeme Lexer ListSetOps Literal Maybes MkCore MkId Module MonadUtils Name NameEnv NameSet OccName OccurAnal OptCoercion OrdList Outputable PackageConfig Packages Pair Panic PatSyn PipelineMonad Platform PlatformConstants PprCore PrelNames PrelRules Pretty PrimOp RdrName Rules Serialized SrcLoc StaticFlags StringBuffer TcEvidence TcRnTypes TcType TrieMap TyCon Type TypeRep TysPrim TysWiredIn Unify UniqFM UniqSet UniqSupply Unique Util Var VarEnv VarSet Bitmap BlockId ByteCodeAsm ByteCodeInstr ByteCodeItbls CLabel Cmm CmmCallConv CmmExpr CmmInfo CmmMachOp CmmNode CmmSwitch CmmUtils CodeGen.Platform CodeGen.Platform.ARM CodeGen.Platform.ARM64 CodeGen.Platform.NoRegs CodeGen.Platform.PPC CodeGen.Platform.PPC_Darwin CodeGen.Platform.SPARC CodeGen.Platform.X86 CodeGen.Platform.X86_64 Hoopl Hoopl.Dataflow InteractiveEvalTypes MkGraph PprCmm PprCmmDecl PprCmmExpr Reg RegClass SMRep StgCmmArgRep StgCmmClosure StgCmmEnv StgCmmLayout StgCmmMonad StgCmmProf StgCmmTicky StgCmmUtils StgSyn Stream" Reachable modules from DynFlags out of date Please fix compiler/ghc.mk, or building DLLs on Windows may break (#7780) Redundant modules: Ctype Lexer simonpj at cam-05-unx:~/5builds/HEAD-2$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Tue Oct 27 09:12:28 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Tue, 27 Oct 2015 11:12:28 +0200 Subject: dll-split In-Reply-To: References: Message-ID: I think you need to remove Ctype and Lexer from https://github.com/ghc/ghc/blob/master/compiler/ghc.mk#L498 On 27 Oct 2015 11:06 AM, "Simon Peyton Jones" wrote: > It?s just not my day. > > Now, on Linux, on my branch wip/spj-wildcard-refactor, I get a failure in > dll-split! Should dll-split be running at all on Linux???? > > The output it produces is below. > > I?m totally stuck. Help desperately needed. > > Simon > > > > inplace/bin/dll-split compiler/stage2/build/.depend-v-p-dyn.haskell > "DynFlags" "Annotations ApiAnnotation Avail Bag BasicTypes Binary > BooleanFormula BreakArray BufWrite Class CmdLineParser CmmType CoAxiom > ConLike Coercion Config Constants CoreArity CoreFVs CoreSubst CoreSyn > CoreTidy CoreUnfold CoreUtils CoreSeq CoreStats CostCentre Ctype DataCon > Demand Digraph DriverPhases DynFlags Encoding ErrUtils Exception FamInstEnv > FastFunctions FastMutInt FastString FastStringEnv FieldLabel Fingerprint > FiniteMap ForeignCall Hooks HsBinds HsDecls HsDoc HsExpr HsImpExp HsLit > PlaceHolder HsPat HsSyn HsTypes HsUtils HscTypes IOEnv Id IdInfo IfaceSyn > IfaceType InstEnv Kind Lexeme Lexer ListSetOps Literal Maybes MkCore MkId > Module MonadUtils Name NameEnv NameSet OccName OccurAnal OptCoercion > OrdList Outputable PackageConfig Packages Pair Panic PatSyn PipelineMonad > Platform PlatformConstants PprCore PrelNames PrelRules Pretty PrimOp > RdrName Rules Serialized SrcLoc StaticFlags StringBuffer TcEvidence > TcRnTypes TcType TrieMap TyCon Type TypeRep TysPrim TysWiredIn Unify UniqFM > UniqSet UniqSupply Unique Util Var VarEnv VarSet Bitmap BlockId ByteCodeAsm > ByteCodeInstr ByteCodeItbls CLabel Cmm CmmCallConv CmmExpr CmmInfo > CmmMachOp CmmNode CmmSwitch CmmUtils CodeGen.Platform CodeGen.Platform.ARM > CodeGen.Platform.ARM64 CodeGen.Platform.NoRegs CodeGen.Platform.PPC > CodeGen.Platform.PPC_Darwin CodeGen.Platform.SPARC CodeGen.Platform.X86 > CodeGen.Platform.X86_64 Hoopl Hoopl.Dataflow InteractiveEvalTypes MkGraph > PprCmm PprCmmDecl PprCmmExpr Reg RegClass SMRep StgCmmArgRep StgCmmClosure > StgCmmEnv StgCmmLayout StgCmmMonad StgCmmProf StgCmmTicky StgCmmUtils > StgSyn Stream" > > Reachable modules from DynFlags out of date > > Please fix compiler/ghc.mk, or building DLLs on Windows may break (#7780) > > Redundant modules: Ctype Lexer > > simonpj at cam-05-unx:~/5builds/HEAD-2$ > > _______________________________________________ > 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 Tue Oct 27 09:16:06 2015 From: ben at well-typed.com (Ben Gamari) Date: Tue, 27 Oct 2015 10:16:06 +0100 Subject: dll-split In-Reply-To: References: Message-ID: <87611s4qp5.fsf@smart-cactus.org> Simon Peyton Jones writes: > It's just not my day. > Now, on Linux, on my branch wip/spj-wildcard-refactor, I get a failure > in dll-split! Should dll-split be running at all on Linux???? > I'm looking into it. Give me a few minutes. I believe dll-split is run to ensure that the module list remains consistent, even when developers are building on non-Windows platforms. 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 Tue Oct 27 09:20:48 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 27 Oct 2015 09:20:48 +0000 Subject: dll-split In-Reply-To: References: Message-ID: Thanks. Indeed, in parallel, I randomly tried that and indeed it?s going again now. ? But why is dll-split running at all on Linux? Ben says: ?I believe dll-split is run to ensure that the module list remains consistent, even when developers are building on non-Windows platforms?. That makes sense; but it would be good to document it. ? I?m puzzled by why my branch might have changed the transitive dependencies from DynFlags. But you can?t really help with that! Anyway, by simply removing those two, the pipe is unblocked. I hope it?s the right thing to do. Thanks! Simon From: Alan & Kim Zimmerman [mailto:alan.zimm at gmail.com] Sent: 27 October 2015 09:12 To: Simon Peyton Jones Cc: ghc-devs at haskell.org; Ben Gamari Subject: Re: dll-split I think you need to remove Ctype and Lexer from https://github.com/ghc/ghc/blob/master/compiler/ghc.mk#L498 On 27 Oct 2015 11:06 AM, "Simon Peyton Jones" > wrote: It?s just not my day. Now, on Linux, on my branch wip/spj-wildcard-refactor, I get a failure in dll-split! Should dll-split be running at all on Linux???? The output it produces is below. I?m totally stuck. Help desperately needed. Simon inplace/bin/dll-split compiler/stage2/build/.depend-v-p-dyn.haskell "DynFlags" "Annotations ApiAnnotation Avail Bag BasicTypes Binary BooleanFormula BreakArray BufWrite Class CmdLineParser CmmType CoAxiom ConLike Coercion Config Constants CoreArity CoreFVs CoreSubst CoreSyn CoreTidy CoreUnfold CoreUtils CoreSeq CoreStats CostCentre Ctype DataCon Demand Digraph DriverPhases DynFlags Encoding ErrUtils Exception FamInstEnv FastFunctions FastMutInt FastString FastStringEnv FieldLabel Fingerprint FiniteMap ForeignCall Hooks HsBinds HsDecls HsDoc HsExpr HsImpExp HsLit PlaceHolder HsPat HsSyn HsTypes HsUtils HscTypes IOEnv Id IdInfo IfaceSyn IfaceType InstEnv Kind Lexeme Lexer ListSetOps Literal Maybes MkCore MkId Module MonadUtils Name NameEnv NameSet OccName OccurAnal OptCoercion OrdList Outputable PackageConfig Packages Pair Panic PatSyn PipelineMonad Platform PlatformConstants PprCore PrelNames PrelRules Pretty PrimOp RdrName Rules Serialized SrcLoc StaticFlags StringBuffer TcEvidence TcRnTypes TcType TrieMap TyCon Type TypeRep TysPrim TysWiredIn Unify UniqFM UniqSet UniqSupply Unique Util Var VarEnv VarSet Bitmap BlockId ByteCodeAsm ByteCodeInstr ByteCodeItbls CLabel Cmm CmmCallConv CmmExpr CmmInfo CmmMachOp CmmNode CmmSwitch CmmUtils CodeGen.Platform CodeGen.Platform.ARM CodeGen.Platform.ARM64 CodeGen.Platform.NoRegs CodeGen.Platform.PPC CodeGen.Platform.PPC_Darwin CodeGen.Platform.SPARC CodeGen.Platform.X86 CodeGen.Platform.X86_64 Hoopl Hoopl.Dataflow InteractiveEvalTypes MkGraph PprCmm PprCmmDecl PprCmmExpr Reg RegClass SMRep StgCmmArgRep StgCmmClosure StgCmmEnv StgCmmLayout StgCmmMonad StgCmmProf StgCmmTicky StgCmmUtils StgSyn Stream" Reachable modules from DynFlags out of date Please fix compiler/ghc.mk, or building DLLs on Windows may break (#7780) Redundant modules: Ctype Lexer simonpj at cam-05-unx:~/5builds/HEAD-2$ _______________________________________________ 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 smart-cactus.org Tue Oct 27 09:22:25 2015 From: ben at smart-cactus.org (Ben Gamari) Date: Tue, 27 Oct 2015 10:22:25 +0100 Subject: dll-split In-Reply-To: References: Message-ID: <8737ww4qem.fsf@smart-cactus.org> Alan & Kim Zimmerman writes: > I think you need to remove Ctype and Lexer from > https://github.com/ghc/ghc/blob/master/compiler/ghc.mk#L498 > Thanks Alan! That being said looking at the branch it's not entirely clear to me where this change came from. It doesn't appear that Simon has added or removed import to these modules. 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 Tue Oct 27 10:06:48 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 27 Oct 2015 10:06:48 +0000 Subject: New error on linux Message-ID: <7bae30d868084d40b48bbbfb386f6913@DB4PR30MB030.064d.mgd.msft.net> Clean build on HEAD on Linux is now giving a new error. Actual stderr output differs from expected: --- ./driver/T10970a.stderr.normalised 2015-10-27 09:44:02.279188078 +0000 +++ ./driver/T10970a.comp.stderr.normalised 2015-10-27 09:44:02.279188078 +0000 @@ -1,6 +1,4 @@ T10970a.hs:4:0: missing binary operator before token "(" - #if MIN_VERSION_base(3,0,0) - ^ `gcc' failed in phase `C pre-processor'. (Exit code: 1) I figured out the recomp013 problem; there was a commit which interacted badly with link trees commit cdca31ebf7744dcae66a6715500395a63bcc3ee2 Author: Edward Z. Yang Date: Wed Sep 9 22:02:48 2015 -0700 Don't check in autogenerated hs files for recomp013.. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Tue Oct 27 10:31:12 2015 From: ben at smart-cactus.org (Ben Gamari) Date: Tue, 27 Oct 2015 11:31:12 +0100 Subject: New error on linux In-Reply-To: <7bae30d868084d40b48bbbfb386f6913@DB4PR30MB030.064d.mgd.msft.net> References: <7bae30d868084d40b48bbbfb386f6913@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <87y4eo38nj.fsf@smart-cactus.org> Simon Peyton Jones writes: > Clean build on HEAD on Linux is now giving a new error. > > Actual stderr output differs from expected: > > --- ./driver/T10970a.stderr.normalised 2015-10-27 09:44:02.279188078 +0000 > > +++ ./driver/T10970a.comp.stderr.normalised 2015-10-27 09:44:02.279188078 +0000 > > @@ -1,6 +1,4 @@ > > T10970a.hs:4:0: > > missing binary operator before token "(" > > - #if MIN_VERSION_base(3,0,0) > > - ^ > > `gcc' failed in phase `C pre-processor'. (Exit code: 1) > Hmm, it is possible that the output produced by this test is gcc-version dependent. What GCC version are you using? I believe Edward must have been using 5.2.* as `master` currently validates for me and this is the version I am using. 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 Tue Oct 27 10:35:18 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 27 Oct 2015 10:35:18 +0000 Subject: New error on linux In-Reply-To: <87y4eo38nj.fsf@smart-cactus.org> References: <7bae30d868084d40b48bbbfb386f6913@DB4PR30MB030.064d.mgd.msft.net> <87y4eo38nj.fsf@smart-cactus.org> Message-ID: <694ec4af3e2c469e87a2699560d87d60@DB4PR30MB030.064d.mgd.msft.net> gcc 4.6.3 | -----Original Message----- | From: Ben Gamari [mailto:ben at smart-cactus.org] | Sent: 27 October 2015 10:31 | To: Simon Peyton Jones; ghc-devs at haskell.org | Subject: Re: New error on linux | | Simon Peyton Jones writes: | | > Clean build on HEAD on Linux is now giving a new error. | > | > Actual stderr output differs from expected: | > | > --- ./driver/T10970a.stderr.normalised 2015-10-27 09:44:02.279188078 | +0000 | > | > +++ ./driver/T10970a.comp.stderr.normalised 2015-10-27 | 09:44:02.279188078 +0000 | > | > @@ -1,6 +1,4 @@ | > | > T10970a.hs:4:0: | > | > missing binary operator before token "(" | > | > - #if MIN_VERSION_base(3,0,0) | > | > - ^ | > | > `gcc' failed in phase `C pre-processor'. (Exit code: 1) | > | Hmm, it is possible that the output produced by this test is gcc-version | dependent. What GCC version are you using? | | I believe Edward must have been using 5.2.* as `master` currently validates | for me and this is the version I am using. | | Cheers, | | - Ben From ben at smart-cactus.org Tue Oct 27 11:04:42 2015 From: ben at smart-cactus.org (Ben Gamari) Date: Tue, 27 Oct 2015 12:04:42 +0100 Subject: New error on linux In-Reply-To: <694ec4af3e2c469e87a2699560d87d60@DB4PR30MB030.064d.mgd.msft.net> References: <7bae30d868084d40b48bbbfb386f6913@DB4PR30MB030.064d.mgd.msft.net> <87y4eo38nj.fsf@smart-cactus.org> <694ec4af3e2c469e87a2699560d87d60@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <87pp00373p.fsf@smart-cactus.org> Simon Peyton Jones writes: > gcc 4.6.3 > Alright, we'll need to figure out what to do about these differences. 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 Tue Oct 27 11:22:58 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 27 Oct 2015 11:22:58 +0000 Subject: Doc warnings Message-ID: <6b373e6062624713b2117e7a47490752@DB4PR30MB030.064d.mgd.msft.net> I'm getting these warnings relating to the user manual. They seem non-fatal, but are alarming. Simon reading sources... [ 66%] ghc looking for now-outdated files... none found pickling environment... done checking consistency... /5playpen/simonpj/HEAD-2/docs/users_guide/ghc.rst:: WARNING: document isn't included in any toctree done writing... ghc.1 { WARNING: file compiler/simplCore/SimplCore.hs, line 600 Simplifier bailing out after 4 iterations [6069, 1479, 780, 43] Size = {terms: 5,210, types: 10,459, coercions: 2,136} Interesting! A join var that isn't let-no-escaped [$j_snPt] } build succeeded, 1 warning. reading sources... [100%] glasgow_exts WARNING: file compiler/simplCore/SimplEnv.hs, line 528 go_Xn2R WARNING: file compiler/simplCore/SimplEnv.hs, line 528 go_Xn2R looking for now-outdated files... none found pickling environment... done checking consistency... /5playpen/simonpj/HEAD-2/docs/users_guide/ghc.rst:: WARNING: document isn't included in any toctree done preparing documents... done -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Tue Oct 27 13:44:02 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Tue, 27 Oct 2015 09:44:02 -0400 Subject: Segfault in a CoreLinted program (and a GHC-generated Core question) In-Reply-To: References: <8daefc4bfba5473f973e4e7a939b0c7a@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <5CD51E8A-64A4-43AD-9761-62787EA61265@cis.upenn.edu> Phew. This was an alarming email! If a core-linted program segfaults, there's either a bug in CoreLint or a bug in the theory behind GHC. If it's the latter, someone will have an interesting paper to write... :) Richard On Oct 26, 2015, at 7:57 PM, ?mer Sinan A?acan wrote: > OK, thanks to people at IRC channel(especially @rwbarton) I realized > that my lint calls were not actually running, simply because I wasn't > using -dcore-lint.. I didn't know such a flag exists, and even with > the absence of the flag I'd expect a core lint would work, because I'm > explicitly calling the lint function without checking any flags! > > CoreLint is now giving me really awesome diagnostics! Sorry for the noise.. > > (I'll try to document linter functions or CoreLint module to let the > user know he/she needs this flag!) > > 2015-10-26 13:43 GMT-04:00 Simon Peyton Jones : >> | So my questions are: Am I right in assuming that CoreLint accepted programs >> | should not segfault? >> >> Yes. Modulo unsafeCoerce, and FFI calls. >> >> | What about internal invariants? Should CoreLint check >> | for those? Is there any pass that checks for invariants and prints helpful >> | messages in case of a invariant invalidation? >> >> Yes; they are documented in CoreSyn, which the data type, and Lint checks them. >> >> | As an attempt at debugging the code generated by my plugin, I wrote the >> | function that is supposed to be generated by my Core pass in Haskell and >> | compiled with GHC. Generated Core is mostly the same, except at one point it >> | has an extra lambda directly applied to a void#, something like ((\_ -> ...) >> | void#). Where can I learn more about why GHC is doing that? >> >> Show me the code! >> >> Instead of generating >> >> x :: Int# = >> >> GHC sometimes generates >> >> x :: Void# -> Int# = \_ - >> >> and then calls (x void#), to make any div-zero failures happen at the right place. >> >> I'm not sure if that is what you are seeing, but we can work it out when you give more detail. >> >> Simon > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From ben at smart-cactus.org Tue Oct 27 14:11:08 2015 From: ben at smart-cactus.org (Ben Gamari) Date: Tue, 27 Oct 2015 15:11:08 +0100 Subject: Doc warnings In-Reply-To: <6b373e6062624713b2117e7a47490752@DB4PR30MB030.064d.mgd.msft.net> References: <6b373e6062624713b2117e7a47490752@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <87mvv42ygz.fsf@smart-cactus.org> Simon Peyton Jones writes: > I'm getting these warnings relating to the user manual. They seem non-fatal, but are alarming. > Simon > > > reading sources... [ 66%] ghc > > > > looking for now-outdated files... none found > > pickling environment... done > > checking consistency... /5playpen/simonpj/HEAD-2/docs/users_guide/ghc.rst:: WARNING: document isn't included in any toctree > Fixed. It was harmless so I had been putting off diving into it for quite a while. > done > > writing... ghc.1 { WARNING: file compiler/simplCore/SimplCore.hs, line 600 > > Simplifier bailing out after 4 iterations [6069, 1479, 780, 43] > > Size = {terms: 5,210, types: 10,459, coercions: 2,136} > > Interesting! A join var that isn't let-no-escaped [$j_snPt] > > } > Presumably this is just output from a concurrently running GHC process. 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 Tue Oct 27 14:28:25 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 27 Oct 2015 15:28:25 +0100 Subject: Segfault in a CoreLinted program (and a GHC-generated Core question) In-Reply-To: <5CD51E8A-64A4-43AD-9761-62787EA61265@cis.upenn.edu> References: <8daefc4bfba5473f973e4e7a939b0c7a@DB4PR30MB030.064d.mgd.msft.net> <5CD51E8A-64A4-43AD-9761-62787EA61265@cis.upenn.edu> Message-ID: <1445956105.1433.1.camel@joachim-breitner.de> Am Dienstag, den 27.10.2015, 09:44 -0400 schrieb Richard Eisenberg: > Phew. This was an alarming email! If a core-linted program segfaults, > there's either a bug in CoreLint or a bug in the theory behind GHC. > If it's the latter, someone will have an interesting paper to > write... :) ... or in the translation to STG, or in a STG to STG pass, or in the translation to C--, or in a C-- to C-- pass, or in the code generator, or in the linker, or in... 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 Tue Oct 27 14:31:33 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 27 Oct 2015 14:31:33 +0000 Subject: stg_upd_frame_info still broken Message-ID: Friends I still cannot build GHC on Windows. On Ben's advice I dumped my current msys setup and re-installed msys64 as described here https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows I cloned an entirely new GHC repository. Then 'sh validate'. Same result as before: any attempt to run GHCi fails with an unresolved symbol. bash$ c:/code/HEAD-1/inplace/bin/ghc-stage2 --interactive GHCi, version 7.11.20151026: http://www.haskell.org/ghc/ :? for help ghc-stage2.exe: unable to load package `ghc-prim-0.4.0.0' ghc-stage2.exe: C:\code\HEAD-1\libraries\ghc-prim\dist-install\build\HSghc-prim-0.4.0.0.o: unknown symbol `_stg_upd_frame_info' How could I actually find what the problem is? Trying random things and hoping the problem goes away clearly is not working. Very stuck and deeply frustrated Thanks Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Tue Oct 27 14:41:19 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Tue, 27 Oct 2015 10:41:19 -0400 Subject: Segfault in a CoreLinted program (and a GHC-generated Core question) In-Reply-To: <1445956105.1433.1.camel@joachim-breitner.de> References: <8daefc4bfba5473f973e4e7a939b0c7a@DB4PR30MB030.064d.mgd.msft.net> <5CD51E8A-64A4-43AD-9761-62787EA61265@cis.upenn.edu> <1445956105.1433.1.camel@joachim-breitner.de> Message-ID: <7A3668C3-3771-4B89-ACE9-6642D134C7D6@cis.upenn.edu> Didn't you know? Once the core-to-core passes are complete, a binary appears on disk by sheer magic. And magic is never wrong. Richard On Oct 27, 2015, at 10:28 AM, Joachim Breitner wrote: > Am Dienstag, den 27.10.2015, 09:44 -0400 schrieb Richard Eisenberg: >> Phew. This was an alarming email! If a core-linted program segfaults, >> there's either a bug in CoreLint or a bug in the theory behind GHC. >> If it's the latter, someone will have an interesting paper to >> write... :) > > ... or in the translation to STG, or in a STG to STG pass, or in the > translation to C--, or in a C-- to C-- pass, or in the code generator, > or in the linker, or in... > > 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 ben at well-typed.com Tue Oct 27 14:46:33 2015 From: ben at well-typed.com (Ben Gamari) Date: Tue, 27 Oct 2015 15:46:33 +0100 Subject: stg_upd_frame_info still broken In-Reply-To: References: Message-ID: <87io5s2wty.fsf@smart-cactus.org> Simon Peyton Jones writes: > Friends > I still cannot build GHC on Windows. On Ben's advice I dumped my > current msys setup and re-installed msys64 as described here > https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows I'm sorry to hear that updating msys2 didn't do the trick. I'm still trying to reproduce this in the background. My previous builds were of the ghc-7.10 branch so it's possible this regression was introduced into `master`. > I cloned an entirely new GHC repository. > Then 'sh validate'. > Same result as before: any attempt to run GHCi fails with an unresolved symbol. > > bash$ c:/code/HEAD-1/inplace/bin/ghc-stage2 --interactive > > GHCi, version 7.11.20151026: http://www.haskell.org/ghc/ :? for help > > ghc-stage2.exe: unable to load package `ghc-prim-0.4.0.0' > > ghc-stage2.exe: C:\code\HEAD-1\libraries\ghc-prim\dist-install\build\HSghc-prim-0.4.0.0.o: unknown symbol `_stg_upd_frame_info' > > How could I actually find what the problem is? Trying random things > and hoping the problem goes away clearly is not working. > I would first try to find the object file which is supposed to provide this symbol and figure out whether the problem is one of the RTL (which is what I would put my money on) or some part of the build toolchain. 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 Tue Oct 27 14:54:49 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 27 Oct 2015 15:54:49 +0100 Subject: Segfault in a CoreLinted program (and a GHC-generated Core question) In-Reply-To: <7A3668C3-3771-4B89-ACE9-6642D134C7D6@cis.upenn.edu> References: <8daefc4bfba5473f973e4e7a939b0c7a@DB4PR30MB030.064d.mgd.msft.net> <5CD51E8A-64A4-43AD-9761-62787EA61265@cis.upenn.edu> <1445956105.1433.1.camel@joachim-breitner.de> <7A3668C3-3771-4B89-ACE9-6642D134C7D6@cis.upenn.edu> Message-ID: <1445957689.1433.3.camel@joachim-breitner.de> Am Dienstag, den 27.10.2015, 10:41 -0400 schrieb Richard Eisenberg: > Didn't you know? Once the core-to-core passes are complete, a binary > appears on disk by sheer magic. And magic is never wrong. Ah, no, I didn?t. No wonder my feeble attempts to make the code generation for switches more efficient didn?t yield the desired performance boosts. 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 Tue Oct 27 14:55:46 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 27 Oct 2015 14:55:46 +0000 Subject: stg_upd_frame_info still broken In-Reply-To: <87io5s2wty.fsf@smart-cactus.org> References: <87io5s2wty.fsf@smart-cactus.org> Message-ID: I'm sure it's the runtime linker. Static linking is fine. The symbol is defined in Updates.cmm, and is there in Updates.o, and in ghc-stage2.exe | -----Original Message----- | From: Ben Gamari [mailto:ben at well-typed.com] | Sent: 27 October 2015 14:47 | To: Simon Peyton Jones; ghc-devs at haskell.org | Subject: Re: stg_upd_frame_info still broken | | Simon Peyton Jones writes: | | > Friends | > I still cannot build GHC on Windows. On Ben's advice I dumped my | > current msys setup and re-installed msys64 as described here | > https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows | | I'm sorry to hear that updating msys2 didn't do the trick. I'm still trying | to reproduce this in the background. My previous builds were of the ghc-7.10 | branch so it's possible this regression was introduced into `master`. | | > I cloned an entirely new GHC repository. | > Then 'sh validate'. | > Same result as before: any attempt to run GHCi fails with an unresolved | symbol. | > | > bash$ c:/code/HEAD-1/inplace/bin/ghc-stage2 --interactive | > | > GHCi, version 7.11.20151026: http://www.haskell.org/ghc/ :? for help | > | > ghc-stage2.exe: unable to load package `ghc-prim-0.4.0.0' | > | > ghc-stage2.exe: C:\code\HEAD-1\libraries\ghc-prim\dist- | install\build\HSghc-prim-0.4.0.0.o: unknown symbol `_stg_upd_frame_info' | > | > How could I actually find what the problem is? Trying random things | > and hoping the problem goes away clearly is not working. | > | I would first try to find the object file which is supposed to provide this | symbol and figure out whether the problem is one of the RTL (which is what I | would put my money on) or some part of the build toolchain. | | Cheers, | | - Ben From rwbarton at gmail.com Tue Oct 27 14:56:44 2015 From: rwbarton at gmail.com (Reid Barton) Date: Tue, 27 Oct 2015 10:56:44 -0400 Subject: stg_upd_frame_info still broken In-Reply-To: <87io5s2wty.fsf@smart-cactus.org> References: <87io5s2wty.fsf@smart-cactus.org> Message-ID: On Tue, Oct 27, 2015 at 10:46 AM, Ben Gamari wrote: > Simon Peyton Jones writes: > > I cloned an entirely new GHC repository. > > Then 'sh validate'. > > Same result as before: any attempt to run GHCi fails with an unresolved > symbol. > > > > bash$ c:/code/HEAD-1/inplace/bin/ghc-stage2 --interactive > > > > GHCi, version 7.11.20151026: http://www.haskell.org/ghc/ :? for help > > > > ghc-stage2.exe: unable to load package `ghc-prim-0.4.0.0' > > > > ghc-stage2.exe: > C:\code\HEAD-1\libraries\ghc-prim\dist-install\build\HSghc-prim-0.4.0.0.o: > unknown symbol `_stg_upd_frame_info' > > > > How could I actually find what the problem is? Trying random things > > and hoping the problem goes away clearly is not working. > > > I would first try to find the object file which is supposed to provide > this symbol and figure out whether the problem is one of the RTL > (which is what I would put my money on) or some part of the build > toolchain. > I'm pretty sure this error is being produced by ghc's own runtime linker, which has a built-in symbol table (essentially just a C array of structs of { "foo", &foo }). This array is built from a bunch of macros such as SymI_HasProto(stg_upd_frame_info), which used to be present in rts/Linker.c but were moved to rts/RtsSymbols.c in commit abc214b77d. I guess that commit or a related one was not correct. Windows is the only (major?) platform on which the ghc executable is built statically by default, and therefore uses ghc's own runtime linker. I'll try building a Linux ghc with GHC_DYNAMIC=NO and if it exhibits the same problem I should be able to provide a quick fix. Regards, Reid Barton -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Oct 27 14:57:51 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 27 Oct 2015 14:57:51 +0000 Subject: stg_upd_frame_info still broken In-Reply-To: References: <87io5s2wty.fsf@smart-cactus.org> Message-ID: <275d7edc8ad3414e9bbff7ac7ea7d4ea@DB4PR30MB030.064d.mgd.msft.net> I'm pretty sure this error is being produced by ghc's own runtime linker, which has a built-in symbol table (essentially just a C array of structs of { "foo", &foo }). This array is built from a bunch of macros such as SymI_HasProto(stg_upd_frame_info), which used to be present in rts/Linker.c but were moved to rts/RtsSymbols.c in commit abc214b77d. I guess that commit or a related one was not correct. Windows is the only (major?) platform on which the ghc executable is built statically by default, and therefore uses ghc's own runtime linker. Ah. That sounds very plausible Thanks S From: Reid Barton [mailto:rwbarton at gmail.com] Sent: 27 October 2015 14:57 To: Ben Gamari Cc: Simon Peyton Jones; ghc-devs at haskell.org Subject: Re: stg_upd_frame_info still broken On Tue, Oct 27, 2015 at 10:46 AM, Ben Gamari > wrote: Simon Peyton Jones > writes: > I cloned an entirely new GHC repository. > Then 'sh validate'. > Same result as before: any attempt to run GHCi fails with an unresolved symbol. > > bash$ c:/code/HEAD-1/inplace/bin/ghc-stage2 --interactive > > GHCi, version 7.11.20151026: http://www.haskell.org/ghc/ :? for help > > ghc-stage2.exe: unable to load package `ghc-prim-0.4.0.0' > > ghc-stage2.exe: C:\code\HEAD-1\libraries\ghc-prim\dist-install\build\HSghc-prim-0.4.0.0.o: unknown symbol `_stg_upd_frame_info' > > How could I actually find what the problem is? Trying random things > and hoping the problem goes away clearly is not working. > I would first try to find the object file which is supposed to provide this symbol and figure out whether the problem is one of the RTL (which is what I would put my money on) or some part of the build toolchain. I'm pretty sure this error is being produced by ghc's own runtime linker, which has a built-in symbol table (essentially just a C array of structs of { "foo", &foo }). This array is built from a bunch of macros such as SymI_HasProto(stg_upd_frame_info), which used to be present in rts/Linker.c but were moved to rts/RtsSymbols.c in commit abc214b77d. I guess that commit or a related one was not correct. Windows is the only (major?) platform on which the ghc executable is built statically by default, and therefore uses ghc's own runtime linker. I'll try building a Linux ghc with GHC_DYNAMIC=NO and if it exhibits the same problem I should be able to provide a quick fix. Regards, Reid Barton -------------- next part -------------- An HTML attachment was scrubbed... URL: From rwbarton at gmail.com Tue Oct 27 15:25:58 2015 From: rwbarton at gmail.com (Reid Barton) Date: Tue, 27 Oct 2015 11:25:58 -0400 Subject: stg_upd_frame_info still broken In-Reply-To: <275d7edc8ad3414e9bbff7ac7ea7d4ea@DB4PR30MB030.064d.mgd.msft.net> References: <87io5s2wty.fsf@smart-cactus.org> <275d7edc8ad3414e9bbff7ac7ea7d4ea@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Unfortunately the DYNAMIC_GHC_PROGRAMS=NO build on Linux did produce a working ghci, so I guess that leaves reviewing the likely culprit patch(es) very carefully... Regards, Reid Barton On Tue, Oct 27, 2015 at 10:57 AM, Simon Peyton Jones wrote: > I'm pretty sure this error is being produced by ghc's own runtime linker, > which has a built-in symbol table (essentially just a C array of structs of > { "foo", &foo }). This array is built from a bunch of macros such as > SymI_HasProto(stg_upd_frame_info), which used to be present in rts/Linker.c > but were moved to rts/RtsSymbols.c in commit abc214b77d. I guess that > commit or a related one was not correct. Windows is the only (major?) > platform on which the ghc executable is built statically by default, and > therefore uses ghc's own runtime linker. > > > > Ah. That sounds very plausible Thanks > > > > S > > > > *From:* Reid Barton [mailto:rwbarton at gmail.com] > *Sent:* 27 October 2015 14:57 > *To:* Ben Gamari > *Cc:* Simon Peyton Jones; ghc-devs at haskell.org > *Subject:* Re: stg_upd_frame_info still broken > > > > On Tue, Oct 27, 2015 at 10:46 AM, Ben Gamari wrote: > > Simon Peyton Jones writes: > > I cloned an entirely new GHC repository. > > Then 'sh validate'. > > Same result as before: any attempt to run GHCi fails with an unresolved > symbol. > > > > bash$ c:/code/HEAD-1/inplace/bin/ghc-stage2 --interactive > > > > GHCi, version 7.11.20151026: http://www.haskell.org/ghc/ > > :? for help > > > > ghc-stage2.exe: unable to load package `ghc-prim-0.4.0.0' > > > > ghc-stage2.exe: > C:\code\HEAD-1\libraries\ghc-prim\dist-install\build\HSghc-prim-0.4.0.0.o: > unknown symbol `_stg_upd_frame_info' > > > > How could I actually find what the problem is? Trying random things > > and hoping the problem goes away clearly is not working. > > > I would first try to find the object file which is supposed to provide > this symbol and figure out whether the problem is one of the RTL > (which is what I would put my money on) or some part of the build > toolchain. > > > > I'm pretty sure this error is being produced by ghc's own runtime linker, > which has a built-in symbol table (essentially just a C array of structs of > { "foo", &foo }). This array is built from a bunch of macros such as > SymI_HasProto(stg_upd_frame_info), which used to be present in rts/Linker.c > but were moved to rts/RtsSymbols.c in commit abc214b77d. I guess that > commit or a related one was not correct. Windows is the only (major?) > platform on which the ghc executable is built statically by default, and > therefore uses ghc's own runtime linker. > > I'll try building a Linux ghc with GHC_DYNAMIC=NO and if it exhibits the > same problem I should be able to provide a quick fix. > > Regards, > > Reid Barton > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rwbarton at gmail.com Tue Oct 27 15:54:23 2015 From: rwbarton at gmail.com (Reid Barton) Date: Tue, 27 Oct 2015 11:54:23 -0400 Subject: stg_upd_frame_info still broken In-Reply-To: References: <87io5s2wty.fsf@smart-cactus.org> <275d7edc8ad3414e9bbff7ac7ea7d4ea@DB4PR30MB030.064d.mgd.msft.net> Message-ID: I got lucky and found an error in the first place I looked. I have no way to test it, but I expect that https://phabricator.haskell.org/D1382 will fix the build on Windows, or at least make it closer to correct :) Regards, Reid On Tue, Oct 27, 2015 at 11:25 AM, Reid Barton wrote: > Unfortunately the DYNAMIC_GHC_PROGRAMS=NO build on Linux did produce a > working ghci, so I guess that leaves reviewing the likely culprit patch(es) > very carefully... > > Regards, > Reid Barton > > > On Tue, Oct 27, 2015 at 10:57 AM, Simon Peyton Jones < > simonpj at microsoft.com> wrote: > >> I'm pretty sure this error is being produced by ghc's own runtime >> linker, which has a built-in symbol table (essentially just a C array of >> structs of { "foo", &foo }). This array is built from a bunch of macros >> such as SymI_HasProto(stg_upd_frame_info), which used to be present in >> rts/Linker.c but were moved to rts/RtsSymbols.c in commit abc214b77d. I >> guess that commit or a related one was not correct. Windows is the only >> (major?) platform on which the ghc executable is built statically by >> default, and therefore uses ghc's own runtime linker. >> >> >> >> Ah. That sounds very plausible Thanks >> >> >> >> S >> >> >> >> *From:* Reid Barton [mailto:rwbarton at gmail.com] >> *Sent:* 27 October 2015 14:57 >> *To:* Ben Gamari >> *Cc:* Simon Peyton Jones; ghc-devs at haskell.org >> *Subject:* Re: stg_upd_frame_info still broken >> >> >> >> On Tue, Oct 27, 2015 at 10:46 AM, Ben Gamari wrote: >> >> Simon Peyton Jones writes: >> > I cloned an entirely new GHC repository. >> > Then 'sh validate'. >> > Same result as before: any attempt to run GHCi fails with an unresolved >> symbol. >> > >> > bash$ c:/code/HEAD-1/inplace/bin/ghc-stage2 --interactive >> > >> > GHCi, version 7.11.20151026: http://www.haskell.org/ghc/ >> >> :? for help >> > >> > ghc-stage2.exe: unable to load package `ghc-prim-0.4.0.0' >> > >> > ghc-stage2.exe: >> C:\code\HEAD-1\libraries\ghc-prim\dist-install\build\HSghc-prim-0.4.0.0.o: >> unknown symbol `_stg_upd_frame_info' >> > >> > How could I actually find what the problem is? Trying random things >> > and hoping the problem goes away clearly is not working. >> > >> I would first try to find the object file which is supposed to provide >> this symbol and figure out whether the problem is one of the RTL >> (which is what I would put my money on) or some part of the build >> toolchain. >> >> >> >> I'm pretty sure this error is being produced by ghc's own runtime >> linker, which has a built-in symbol table (essentially just a C array of >> structs of { "foo", &foo }). This array is built from a bunch of macros >> such as SymI_HasProto(stg_upd_frame_info), which used to be present in >> rts/Linker.c but were moved to rts/RtsSymbols.c in commit abc214b77d. I >> guess that commit or a related one was not correct. Windows is the only >> (major?) platform on which the ghc executable is built statically by >> default, and therefore uses ghc's own runtime linker. >> >> I'll try building a Linux ghc with GHC_DYNAMIC=NO and if it exhibits the >> same problem I should be able to provide a quick fix. >> >> Regards, >> >> Reid Barton >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Tue Oct 27 16:14:44 2015 From: ben at well-typed.com (Ben Gamari) Date: Tue, 27 Oct 2015 17:14:44 +0100 Subject: stg_upd_frame_info still broken In-Reply-To: References: <87io5s2wty.fsf@smart-cactus.org> <275d7edc8ad3414e9bbff7ac7ea7d4ea@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <87eggg2sqz.fsf@smart-cactus.org> Reid Barton writes: > I got lucky and found an error in the first place I looked. I have no way > to test it, but I expect that https://phabricator.haskell.org/D1382 will > fix the build on Windows, or at least make it closer to correct :) > I can test. 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 iavor.diatchki at gmail.com Tue Oct 27 17:27:04 2015 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Tue, 27 Oct 2015 10:27:04 -0700 Subject: Type-level error messages In-Reply-To: <8dd0d26809c543e88c9e2da6f91a8f2d@DB4PR30MB030.064d.mgd.msft.net> References: <156b77b4a1a444c7a8d4465d4d941c9d@AM3PR30MB019.064d.mgd.msft.net> <8dd0d26809c543e88c9e2da6f91a8f2d@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Hello, On Thu, Oct 22, 2015 at 9:47 AM, Simon Peyton Jones wrote: > I?ve forgotten the state of your type-level error messages work. How?s it > going? > > I think we should try to add it to 8.0.1. The current status is that the > idea is implemented on a branch. Then, there were some comments and > suggestions that maybe we should do things in a different way, > implementation wise. I haven't had a chance to look into these in detail, > or implement them, and as far as I know nobody else has stepped up to make > the changes. So we could simply go with the current version, and if for > some reason we want to change the implementation we could do it later, as I > don't think the API will be affected in any way. When do the changes > need to happen by, so that it makes it in 8.0? I have been a bit busy, > but I could probably find some time to make whatever changes are required > for this to be merged. > > > > OK good! In that case > > ? Add it to the hoped-for features in the GHC 8.01. status page > Where is the GHC 8.01 status page? ? Write a wiki page with a specification > > Here is the specification: https://ghc.haskell.org/trac/ghc/wiki/CustomTypeErros > ? Announce the proposal and seek feedback > We already had a discussion about it, there are notes on the wiki. I don't think any of the comments were about the actual design, the comments seem to be more about the implementation. On that front, if I am to make the necessary changes, maybe we could have a chat (or e-mail conversation) to make sure that I understand the changes and the motivation for them---the wiki is not a great media for question/answer type of discussions. > ? Meanwhile make sure the branch reflects what you want to be in > it > > I think that the branch should be in an OK state, except that it is not merged with the latest HEAD. -Iavor > > If you don?t have time, well, no harm done? any progress you make on the > above will still be useful. > > > > Simon > > > > *From:* Iavor Diatchki [mailto:iavor.diatchki at gmail.com] > *Sent:* 22 October 2015 17:42 > *To:* Simon Peyton Jones > *Cc:* Augustsson, Lennart > *Subject:* Re: Type-level error messages > > > > Hello, > > > > I think we should try to add it to 8.0.1. The current status is that the > idea is implemented on a branch. Then, there were some comments and > suggestions that maybe we should do things in a different way, > implementation wise. I haven't had a chance to look into these in detail, > or implement them, and as far as I know nobody else has stepped up to make > the changes. So we could simply go with the current version, and if for > some reason we want to change the implementation we could do it later, as I > don't think the API will be affected in any way. When do the changes > need to happen by, so that it makes it in 8.0? I have been a bit busy, > but I could probably find some time to make whatever changes are required > for this to be merged. > > > > -Iavor > > > > > > > > > > > > > > On Thu, Oct 22, 2015 at 3:47 AM, Simon Peyton Jones > wrote: > > Iavor > > I?ve forgotten the state of your type-level error messages work. How?s it > going? > > It?s not mentioned on > https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1: shouldn?t it be? > > Simon > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Oct 27 17:27:01 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 27 Oct 2015 17:27:01 +0000 Subject: stg_upd_frame_info still broken In-Reply-To: References: <87io5s2wty.fsf@smart-cactus.org> <275d7edc8ad3414e9bbff7ac7ea7d4ea@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Well done Reid! That fixed it. Austin will commit it. Thanks for such timely help. You are a star Simon From: Reid Barton [mailto:rwbarton at gmail.com] Sent: 27 October 2015 15:54 To: Simon Peyton Jones Cc: Ben Gamari; ghc-devs at haskell.org Subject: Re: stg_upd_frame_info still broken I got lucky and found an error in the first place I looked. I have no way to test it, but I expect that https://phabricator.haskell.org/D1382 will fix the build on Windows, or at least make it closer to correct :) Regards, Reid On Tue, Oct 27, 2015 at 11:25 AM, Reid Barton > wrote: Unfortunately the DYNAMIC_GHC_PROGRAMS=NO build on Linux did produce a working ghci, so I guess that leaves reviewing the likely culprit patch(es) very carefully... Regards, Reid Barton On Tue, Oct 27, 2015 at 10:57 AM, Simon Peyton Jones > wrote: I'm pretty sure this error is being produced by ghc's own runtime linker, which has a built-in symbol table (essentially just a C array of structs of { "foo", &foo }). This array is built from a bunch of macros such as SymI_HasProto(stg_upd_frame_info), which used to be present in rts/Linker.c but were moved to rts/RtsSymbols.c in commit abc214b77d. I guess that commit or a related one was not correct. Windows is the only (major?) platform on which the ghc executable is built statically by default, and therefore uses ghc's own runtime linker. Ah. That sounds very plausible Thanks S From: Reid Barton [mailto:rwbarton at gmail.com] Sent: 27 October 2015 14:57 To: Ben Gamari Cc: Simon Peyton Jones; ghc-devs at haskell.org Subject: Re: stg_upd_frame_info still broken On Tue, Oct 27, 2015 at 10:46 AM, Ben Gamari > wrote: Simon Peyton Jones > writes: > I cloned an entirely new GHC repository. > Then 'sh validate'. > Same result as before: any attempt to run GHCi fails with an unresolved symbol. > > bash$ c:/code/HEAD-1/inplace/bin/ghc-stage2 --interactive > > GHCi, version 7.11.20151026: http://www.haskell.org/ghc/ :? for help > > ghc-stage2.exe: unable to load package `ghc-prim-0.4.0.0' > > ghc-stage2.exe: C:\code\HEAD-1\libraries\ghc-prim\dist-install\build\HSghc-prim-0.4.0.0.o: unknown symbol `_stg_upd_frame_info' > > How could I actually find what the problem is? Trying random things > and hoping the problem goes away clearly is not working. > I would first try to find the object file which is supposed to provide this symbol and figure out whether the problem is one of the RTL (which is what I would put my money on) or some part of the build toolchain. I'm pretty sure this error is being produced by ghc's own runtime linker, which has a built-in symbol table (essentially just a C array of structs of { "foo", &foo }). This array is built from a bunch of macros such as SymI_HasProto(stg_upd_frame_info), which used to be present in rts/Linker.c but were moved to rts/RtsSymbols.c in commit abc214b77d. I guess that commit or a related one was not correct. Windows is the only (major?) platform on which the ghc executable is built statically by default, and therefore uses ghc's own runtime linker. I'll try building a Linux ghc with GHC_DYNAMIC=NO and if it exhibits the same problem I should be able to provide a quick fix. Regards, Reid Barton -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Tue Oct 27 17:36:36 2015 From: ezyang at mit.edu (Edward Z. Yang) Date: Tue, 27 Oct 2015 10:36:36 -0700 Subject: New error on linux In-Reply-To: <87pp00373p.fsf@smart-cactus.org> References: <7bae30d868084d40b48bbbfb386f6913@DB4PR30MB030.064d.mgd.msft.net> <87y4eo38nj.fsf@smart-cactus.org> <694ec4af3e2c469e87a2699560d87d60@DB4PR30MB030.064d.mgd.msft.net> <87pp00373p.fsf@smart-cactus.org> Message-ID: <1445967375-sup-9095@sabre> That's simple, we can just use ifdef to test for macro appearance. I'll commit a fix. Edward Excerpts from Ben Gamari's message of 2015-10-27 04:04:42 -0700: > Simon Peyton Jones writes: > > > gcc 4.6.3 > > > Alright, we'll need to figure out what to do about these differences. > > Cheers, > > - Ben From ezyang at mit.edu Tue Oct 27 17:47:24 2015 From: ezyang at mit.edu (Edward Z. Yang) Date: Tue, 27 Oct 2015 10:47:24 -0700 Subject: New error on linux In-Reply-To: <1445967375-sup-9095@sabre> References: <7bae30d868084d40b48bbbfb386f6913@DB4PR30MB030.064d.mgd.msft.net> <87y4eo38nj.fsf@smart-cactus.org> <694ec4af3e2c469e87a2699560d87d60@DB4PR30MB030.064d.mgd.msft.net> <87pp00373p.fsf@smart-cactus.org> <1445967375-sup-9095@sabre> Message-ID: <1445968038-sup-4833@sabre> OK fixed. Edward Excerpts from Edward Z. Yang's message of 2015-10-27 10:36:36 -0700: > That's simple, we can just use ifdef to test for macro appearance. > I'll commit a fix. > > Edward > > Excerpts from Ben Gamari's message of 2015-10-27 04:04:42 -0700: > > Simon Peyton Jones writes: > > > > > gcc 4.6.3 > > > > > Alright, we'll need to figure out what to do about these differences. > > > > Cheers, > > > > - Ben From ben at well-typed.com Tue Oct 27 18:12:24 2015 From: ben at well-typed.com (Ben Gamari) Date: Tue, 27 Oct 2015 19:12:24 +0100 Subject: Type-level error messages In-Reply-To: <8dd0d26809c543e88c9e2da6f91a8f2d@DB4PR30MB030.064d.mgd.msft.net> References: <156b77b4a1a444c7a8d4465d4d941c9d@AM3PR30MB019.064d.mgd.msft.net> <8dd0d26809c543e88c9e2da6f91a8f2d@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <878u6o2nav.fsf@smart-cactus.org> Simon Peyton Jones writes: > I?ve forgotten the state of your type-level error messages work. How?s it going? > > Iavor Diatchki writes: > > > I think we should try to add it to 8.0.1. The current status is that > > the idea is implemented on a branch. Then, there were some comments > > and suggestions that maybe we should do things in a different way, > > implementation wise. I haven't had a chance to look into these in > > detail, or implement them, and as far as I know nobody else has > > stepped up to make the changes. So we could simply go with the current > > version, and if for some reason we want to change the implementation > > we could do it later, as I don't think the API will be affected in any > > way. When do the changes need to happen by, so that it makes it in > > 8.0? I have been a bit busy, but I could probably find some time to > > make whatever changes are required for this to be merged. > Hi Iavor, Do you think you will be able to get to this for 8.0? To be viable for 8.0 you should plan on having a patch ready for merge by the last week of November, which means the specification and such should be finished a fair bit sooner. Again, the outstanding tasks are, * Add it to the hoped-for features in the GHC 8.01. status page * Write a wiki page with a specification * Announce the proposal and seek feedback * Meanwhile make sure the branch reflects what you want to be in 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 smart-cactus.org Tue Oct 27 18:14:16 2015 From: ben at smart-cactus.org (Ben Gamari) Date: Tue, 27 Oct 2015 19:14:16 +0100 Subject: New error on linux In-Reply-To: <1445968038-sup-4833@sabre> References: <7bae30d868084d40b48bbbfb386f6913@DB4PR30MB030.064d.mgd.msft.net> <87y4eo38nj.fsf@smart-cactus.org> <694ec4af3e2c469e87a2699560d87d60@DB4PR30MB030.064d.mgd.msft.net> <87pp00373p.fsf@smart-cactus.org> <1445967375-sup-9095@sabre> <1445968038-sup-4833@sabre> Message-ID: <874mhc2n7r.fsf@smart-cactus.org> "Edward Z. Yang" writes: > OK fixed. > Thanks Edward! 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 Tue Oct 27 18:27:33 2015 From: ben at well-typed.com (Ben Gamari) Date: Tue, 27 Oct 2015 19:27:33 +0100 Subject: Type-level error messages In-Reply-To: References: <156b77b4a1a444c7a8d4465d4d941c9d@AM3PR30MB019.064d.mgd.msft.net> <8dd0d26809c543e88c9e2da6f91a8f2d@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <878u6oxj3e.fsf@smart-cactus.org> Iavor Diatchki writes: > Hello, > Hello! Very good timing on the message; we just finished discussing your work not more than an hour ago. You can disregard my message; I didn't notice yours before sending it. > On Thu, Oct 22, 2015 at 9:47 AM, Simon Peyton Jones > wrote: > >> I?ve forgotten the state of your type-level error messages work. How?s it >> going? >> >> I think we should try to add it to 8.0.1. The current status is that the >> idea is implemented on a branch. Then, there were some comments and >> suggestions that maybe we should do things in a different way, >> implementation wise. I haven't had a chance to look into these in detail, >> or implement them, and as far as I know nobody else has stepped up to make >> the changes. So we could simply go with the current version, and if for >> some reason we want to change the implementation we could do it later, as I >> don't think the API will be affected in any way. When do the changes >> need to happen by, so that it makes it in 8.0? I have been a bit busy, >> but I could probably find some time to make whatever changes are required >> for this to be merged. >> >> OK good! In that case >> >> ? Add it to the hoped-for features in the GHC 8.01. status page >> > Where is the GHC 8.01 status page? > Here, https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1 > ? Write a wiki page with a specification >> >> Here is the specification: > https://ghc.haskell.org/trac/ghc/wiki/CustomTypeErros > Great! I have moved this to, https://ghc.haskell.org/trac/ghc/wiki/Proposal/CustomTypeErrors and left a redirect page in the old location. Is there a Trac ticket for this? > >> ? Announce the proposal and seek feedback >> > We already had a discussion about it, there are notes on the wiki. I don't > think any of the comments were about the actual design, the comments seem > to be more about the implementation. On that front, if I am to make the > necessary changes, maybe we could have a chat (or e-mail conversation) to > make sure that I understand the changes and the motivation for them---the > wiki is not a great media for question/answer type of discussions. > I'll let you and Simon work this out. >> ? Meanwhile make sure the branch reflects what you want to be in >> it >> >> I think that the branch should be in an OK state, except that it is not > merged with the latest HEAD. > Where can this branch be found? 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 Tue Oct 27 20:14:48 2015 From: ben at well-typed.com (Ben Gamari) Date: Tue, 27 Oct 2015 21:14:48 +0100 Subject: unboundKey and fromIntegerClassOpKey unique overlap? Message-ID: <87vb9svzk7.fsf@smart-cactus.org> Hello everyone, I noticed while looking through PrelNames that unboundKey and fromIntegerClassOpKey appear to share a unique in the master branch. Is this safe/expected? 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 iavor.diatchki at gmail.com Tue Oct 27 20:48:40 2015 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Tue, 27 Oct 2015 13:48:40 -0700 Subject: Type-level error messages In-Reply-To: <878u6oxj3e.fsf@smart-cactus.org> References: <156b77b4a1a444c7a8d4465d4d941c9d@AM3PR30MB019.064d.mgd.msft.net> <8dd0d26809c543e88c9e2da6f91a8f2d@DB4PR30MB030.064d.mgd.msft.net> <878u6oxj3e.fsf@smart-cactus.org> Message-ID: Hi Ben, I updated the wiki page for GHC 8.0.1 to add an entry for the custom type errors (under "in flight, but likely to make it"). It shouldn't be a problem to make all changes needed by the end of November. Ther phabricator link is this: https://phabricator.haskell.org/D1236 The ticket is here: https://ghc.haskell.org/trac/ghc/ticket/9637 Disclaimer: I don't really understand the phabricator work-flow, I just blindly followed the instructions on the wiki to create this, but I don't really know how to update it or make changes to it. I'd be happy to push a standard git branch, if that would be useful for you. It certainly would be easier for me, as I have a good mental model of what git does, but have only very rudimentary understanding of phabricator. -Iavor On Tue, Oct 27, 2015 at 11:27 AM, Ben Gamari wrote: > Iavor Diatchki writes: > > > Hello, > > > Hello! > > Very good timing on the message; we just finished discussing your work > not more than an hour ago. You can disregard my message; I didn't notice > yours before sending it. > > > On Thu, Oct 22, 2015 at 9:47 AM, Simon Peyton Jones < > simonpj at microsoft.com> > > wrote: > > > >> I?ve forgotten the state of your type-level error messages work. How?s > it > >> going? > >> > >> I think we should try to add it to 8.0.1. The current status is that > the > >> idea is implemented on a branch. Then, there were some comments and > >> suggestions that maybe we should do things in a different way, > >> implementation wise. I haven't had a chance to look into these in > detail, > >> or implement them, and as far as I know nobody else has stepped up to > make > >> the changes. So we could simply go with the current version, and if for > >> some reason we want to change the implementation we could do it later, > as I > >> don't think the API will be affected in any way. When do the changes > >> need to happen by, so that it makes it in 8.0? I have been a bit busy, > >> but I could probably find some time to make whatever changes are > required > >> for this to be merged. > >> > >> OK good! In that case > >> > >> ? Add it to the hoped-for features in the GHC 8.01. status page > >> > > Where is the GHC 8.01 status page? > > > Here, > > https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1 > > > ? Write a wiki page with a specification > >> > >> Here is the specification: > > https://ghc.haskell.org/trac/ghc/wiki/CustomTypeErros > > > Great! I have moved this to, > > https://ghc.haskell.org/trac/ghc/wiki/Proposal/CustomTypeErrors > > and left a redirect page in the old location. > > Is there a Trac ticket for this? > > > > >> ? Announce the proposal and seek feedback > >> > > We already had a discussion about it, there are notes on the wiki. I > don't > > think any of the comments were about the actual design, the comments seem > > to be more about the implementation. On that front, if I am to make the > > necessary changes, maybe we could have a chat (or e-mail conversation) to > > make sure that I understand the changes and the motivation for them---the > > wiki is not a great media for question/answer type of discussions. > > > I'll let you and Simon work this out. > > >> ? Meanwhile make sure the branch reflects what you want to be in > >> it > >> > >> I think that the branch should be in an OK state, except that it is not > > merged with the latest HEAD. > > > Where can this branch be found? > > Cheers, > > - Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewtpickering at gmail.com Tue Oct 27 21:09:42 2015 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Tue, 27 Oct 2015 21:09:42 +0000 Subject: Type-level error messages In-Reply-To: References: <156b77b4a1a444c7a8d4465d4d941c9d@AM3PR30MB019.064d.mgd.msft.net> <8dd0d26809c543e88c9e2da6f91a8f2d@DB4PR30MB030.064d.mgd.msft.net> <878u6oxj3e.fsf@smart-cactus.org> Message-ID: Hi Iavor, You can update your diff by using "arc diff --update D1236" Matt On Tue, Oct 27, 2015 at 8:48 PM, Iavor Diatchki wrote: > Hi Ben, > > I updated the wiki page for GHC 8.0.1 to add an entry for the custom type > errors (under "in flight, but likely to make it"). It shouldn't be a > problem to make all changes needed by the end of November. > > Ther phabricator link is this: > https://phabricator.haskell.org/D1236 > > The ticket is here: > https://ghc.haskell.org/trac/ghc/ticket/9637 > > > Disclaimer: I don't really understand the phabricator work-flow, I just > blindly followed the instructions on the wiki to create this, but I don't > really know how to update it or make changes to it. I'd be happy to push a > standard git branch, if that would be useful for you. It certainly would be > easier for me, as I have a good mental model of what git does, but have only > very rudimentary understanding of phabricator. > > -Iavor > > > > > > On Tue, Oct 27, 2015 at 11:27 AM, Ben Gamari wrote: >> >> Iavor Diatchki writes: >> >> > Hello, >> > >> Hello! >> >> Very good timing on the message; we just finished discussing your work >> not more than an hour ago. You can disregard my message; I didn't notice >> yours before sending it. >> >> > On Thu, Oct 22, 2015 at 9:47 AM, Simon Peyton Jones >> > >> > wrote: >> > >> >> I?ve forgotten the state of your type-level error messages work. How?s >> >> it >> >> going? >> >> >> >> I think we should try to add it to 8.0.1. The current status is that >> >> the >> >> idea is implemented on a branch. Then, there were some comments and >> >> suggestions that maybe we should do things in a different way, >> >> implementation wise. I haven't had a chance to look into these in >> >> detail, >> >> or implement them, and as far as I know nobody else has stepped up to >> >> make >> >> the changes. So we could simply go with the current version, and if >> >> for >> >> some reason we want to change the implementation we could do it later, >> >> as I >> >> don't think the API will be affected in any way. When do the changes >> >> need to happen by, so that it makes it in 8.0? I have been a bit >> >> busy, >> >> but I could probably find some time to make whatever changes are >> >> required >> >> for this to be merged. >> >> >> >> OK good! In that case >> >> >> >> ? Add it to the hoped-for features in the GHC 8.01. status page >> >> >> > Where is the GHC 8.01 status page? >> > >> Here, >> >> https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1 >> >> > ? Write a wiki page with a specification >> >> >> >> Here is the specification: >> > https://ghc.haskell.org/trac/ghc/wiki/CustomTypeErros >> > >> Great! I have moved this to, >> >> https://ghc.haskell.org/trac/ghc/wiki/Proposal/CustomTypeErrors >> >> and left a redirect page in the old location. >> >> Is there a Trac ticket for this? >> >> > >> >> ? Announce the proposal and seek feedback >> >> >> > We already had a discussion about it, there are notes on the wiki. I >> > don't >> > think any of the comments were about the actual design, the comments >> > seem >> > to be more about the implementation. On that front, if I am to make the >> > necessary changes, maybe we could have a chat (or e-mail conversation) >> > to >> > make sure that I understand the changes and the motivation for >> > them---the >> > wiki is not a great media for question/answer type of discussions. >> > >> I'll let you and Simon work this out. >> >> >> ? Meanwhile make sure the branch reflects what you want to be >> >> in >> >> it >> >> >> >> I think that the branch should be in an OK state, except that it is not >> > merged with the latest HEAD. >> > >> Where can this branch be found? >> >> Cheers, >> >> - Ben > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From edzhavoronkov at gmail.com Tue Oct 27 21:29:46 2015 From: edzhavoronkov at gmail.com (=?UTF-8?B?0K3QtNCz0LDRgCDQltCw0LLQvtGA0L7QvdC60L7Qsg==?=) Date: Wed, 28 Oct 2015 00:29:46 +0300 Subject: Warning suppression pragmas In-Reply-To: <33F81532-8E7E-4873-A859-B6AA301DD664@yahoo.com> References: <87si4x4m0d.fsf@smart-cactus.org> <33F81532-8E7E-4873-A859-B6AA301DD664@yahoo.com> Message-ID: Hi Ben! I concreted some points in local warnings suppression pragmas wiki page with specification. https://ghc.haskell.org/trac/ghc/wiki/Design/LocalWarningPragmas Do you know something about defining custom pragmas in GHC? I suppose, i need to add it to the lexer and parser. In that case, how can i understand, that GHC recognizes my pragma? I want to try a few things on my local machine Thanks in advance! Cheers! --- ? ?????????, ?????????? ????? Best regards, Edgar A. Zhavoronkov 2015-10-27 2:35 GMT+03:00 Howard B. Golden : > On US TV, Archie Bunker said "Stifle!" > > Howard > > > On Oct 26, 2015, at 1:59 PM, Alexey Shmalko > wrote: > > > > Hi! > > > > I think SUPPRESS could be enough. > > > > Hope this helps > > > > On Mon, Oct 26, 2015 at 8:59 PM, ????? ?????????? > > wrote: > >> Hi Ben! > >> Thanks for your feedback > >> I thought a little and fixed some in wiki page > >> > >> In my opinion SUPPRESS_WARNINGS is not a real long name for pragma, but > i > >> can't come up with whort name that clearly describes purpose of such > pragma > >> =( > >> Your suggestions are really welcome) > >> > >> --- > >> ? ?????????, > >> ?????????? ????? > >> > >> Best regards, > >> Edgar A. Zhavoronkov > >> > >> 2015-10-26 19:45 GMT+03:00 Ben Gamari : > >>> > >>> ????? ?????????? writes: > >>> > >>>> Hello Richard! > >>>> > >>>> Can you take a look at some sort of specification i wrote week ago? > >>>> I placed it here: > >>>> https://ghc.haskell.org/trac/ghc/wiki/Design/LocalWarningPragmas > >>>> I can imagine only two use cases, and i'm not sure about correcteness > of > >>>> it > >>> Thanks for writing this up! > >>> > >>> The specification is a good start but it really needs more detail. For > >>> instance, what syntactic elements do you want this pragma to apply to? > >>> Bindings? Expressions? Top-level definitions like classes, types, and > >>> instances? Any lexical scope? > >>> > >>> It would be nice if the use-cases you mention were a bit more concrete. > >>> It wouldn't hurt to mention particular warnings that you might imagine > >>> that this would be useful for. > >>> > >>> It would likely be useful to draw inspiration from some of the schemes > >>> used by other languages listed on the ticket (Rust and C# IIRC). It > >>> wouldn't hurt to draw attention to the similarities and differences to > >>> these other schemes in the proposal text. > >>> > >>> On a more bike-shed-y note, `SUPPRESS_WARNINGS` is arguably a bit on > the > >>> long side. > >>> > >>> Personally I would prefer not to see the pragma be bracketed as you > >>> propose in your last example as its effect then becomes quite > >>> "non-local". This pragma should, in my opinion, be a tool of precision, > >>> used sparingly for well-understood reasons. Allowing bracketed regions > >>> makes it too easy for definitions to "sneak in" to the supressed > region, > >>> hiding legitimate warnings. In the interest of keeping the proposal > >>> concrete and concise I would either remove this alternative or move it > >>> to a dedicated "Alternatives" section. > >>> > >>> I'm looking forward to seeing what becomes of this. You might consider > >>> submitting the next iteration of the proposal to the Haskell subreddit > >>> to get a few more eyes on it. Onwards! > >>> > >>> Cheers, > >>> > >>> - Ben > >> > >> > >> _______________________________________________ > >> 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 Oct 27 21:33:01 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 27 Oct 2015 21:33:01 +0000 Subject: Type-level error messages In-Reply-To: References: <156b77b4a1a444c7a8d4465d4d941c9d@AM3PR30MB019.064d.mgd.msft.net> <8dd0d26809c543e88c9e2da6f91a8f2d@DB4PR30MB030.064d.mgd.msft.net> <878u6oxj3e.fsf@smart-cactus.org> Message-ID: It would be great to document some of these common workflows. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Matthew | Pickering | Sent: 27 October 2015 21:10 | To: Iavor Diatchki | Cc: ghc-devs at haskell.org | Subject: Re: Type-level error messages | | Hi Iavor, | | You can update your diff by using "arc diff --update D1236" | | Matt | | On Tue, Oct 27, 2015 at 8:48 PM, Iavor Diatchki | wrote: | > Hi Ben, | > | > I updated the wiki page for GHC 8.0.1 to add an entry for the custom type | > errors (under "in flight, but likely to make it"). It shouldn't be a | > problem to make all changes needed by the end of November. | > | > Ther phabricator link is this: | > https://phabricator.haskell.org/D1236 | > | > The ticket is here: | > https://ghc.haskell.org/trac/ghc/ticket/9637 | > | > | > Disclaimer: I don't really understand the phabricator work-flow, I just | > blindly followed the instructions on the wiki to create this, but I don't | > really know how to update it or make changes to it. I'd be happy to push a | > standard git branch, if that would be useful for you. It certainly would | be | > easier for me, as I have a good mental model of what git does, but have | only | > very rudimentary understanding of phabricator. | > | > -Iavor | > | > | > | > | > | > On Tue, Oct 27, 2015 at 11:27 AM, Ben Gamari wrote: | >> | >> Iavor Diatchki writes: | >> | >> > Hello, | >> > | >> Hello! | >> | >> Very good timing on the message; we just finished discussing your work | >> not more than an hour ago. You can disregard my message; I didn't notice | >> yours before sending it. | >> | >> > On Thu, Oct 22, 2015 at 9:47 AM, Simon Peyton Jones | >> > | >> > wrote: | >> > | >> >> I?ve forgotten the state of your type-level error messages work. How?s | >> >> it | >> >> going? | >> >> | >> >> I think we should try to add it to 8.0.1. The current status is that | >> >> the | >> >> idea is implemented on a branch. Then, there were some comments and | >> >> suggestions that maybe we should do things in a different way, | >> >> implementation wise. I haven't had a chance to look into these in | >> >> detail, | >> >> or implement them, and as far as I know nobody else has stepped up to | >> >> make | >> >> the changes. So we could simply go with the current version, and if | >> >> for | >> >> some reason we want to change the implementation we could do it later, | >> >> as I | >> >> don't think the API will be affected in any way. When do the changes | >> >> need to happen by, so that it makes it in 8.0? I have been a bit | >> >> busy, | >> >> but I could probably find some time to make whatever changes are | >> >> required | >> >> for this to be merged. | >> >> | >> >> OK good! In that case | >> >> | >> >> ? Add it to the hoped-for features in the GHC 8.01. status page | >> >> | >> > Where is the GHC 8.01 status page? | >> > | >> Here, | >> | >> https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1 | >> | >> > ? Write a wiki page with a specification | >> >> | >> >> Here is the specification: | >> > https://ghc.haskell.org/trac/ghc/wiki/CustomTypeErros | >> > | >> Great! I have moved this to, | >> | >> https://ghc.haskell.org/trac/ghc/wiki/Proposal/CustomTypeErrors | >> | >> and left a redirect page in the old location. | >> | >> Is there a Trac ticket for this? | >> | >> > | >> >> ? Announce the proposal and seek feedback | >> >> | >> > We already had a discussion about it, there are notes on the wiki. I | >> > don't | >> > think any of the comments were about the actual design, the comments | >> > seem | >> > to be more about the implementation. On that front, if I am to make the | >> > necessary changes, maybe we could have a chat (or e-mail conversation) | >> > to | >> > make sure that I understand the changes and the motivation for | >> > them---the | >> > wiki is not a great media for question/answer type of discussions. | >> > | >> I'll let you and Simon work this out. | >> | >> >> ? Meanwhile make sure the branch reflects what you want to be | >> >> in | >> >> it | >> >> | >> >> I think that the branch should be in an OK state, except that it is not | >> > merged with the latest HEAD. | >> > | >> Where can this branch be found? | >> | >> Cheers, | >> | >> - Ben | > | > | > | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs at haskell.org | > | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell. | org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c0e259c846f1d47ebdb3f08 | d2df12f101%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=jr88JSBHtublQ%2bsait% | 2bnkabrn56lpoCbOdzl7Wqx%2bYw%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%7c0e259c846f1d47ebdb3 | f08d2df12f101%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=jN7bTpuT1ogdIQqCHA | ughZRzNDkReaBHszrhyNlk6Mg%3d From simonpj at microsoft.com Tue Oct 27 21:39:15 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 27 Oct 2015 21:39:15 +0000 Subject: unboundKey and fromIntegerClassOpKey unique overlap? In-Reply-To: <87vb9svzk7.fsf@smart-cactus.org> References: <87vb9svzk7.fsf@smart-cactus.org> Message-ID: <416d6b69b2bb427588f1c069eefb4f6b@DB4PR30MB030.064d.mgd.msft.net> This is BAD. Do please fix! Thanks Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Ben Gamari | Sent: 27 October 2015 20:15 | To: GHC developers | Subject: unboundKey and fromIntegerClassOpKey unique overlap? | | Hello everyone, | | I noticed while looking through PrelNames that unboundKey and | fromIntegerClassOpKey appear to share a unique in the master branch. Is | this safe/expected? | | Cheers, | | - Ben From simonpj at microsoft.com Tue Oct 27 22:17:42 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 27 Oct 2015 22:17:42 +0000 Subject: GADT decls Message-ID: <525e5e79f90c4c45aa699c05d100e81d@DB4PR30MB030.064d.mgd.msft.net> Ahh. I think I get it. The trouble is that ConDecl doesn?t have the same structure as what the user wrote. Maybe we should just fix that? How about this declaration? Would that make the annotations easier? Ie simple and routine. Simon data ConDecl name | ConDeclGADT { con_names :: [Located name] , con_type :: LHsSigType name -- After the ?::? , con_doc :: Maybe LHsDocString , con_old_rec :: Bool } | ConDeclH98 { con_name :: Located name , con_implict :: HsImplicitBndrs () -- ^ Implicit binders, added by renamer , con_qvars :: Maybe [LHsTyVarBndr name] -- User-written foralls (if any) , con_cxt :: Maybe (LHsContext name) -- ^ User-written context (if any) , con_details :: HsConDeclDetails name -- ^ Arguments , con_doc :: Maybe LHsDocString -- ^ A possible Haddock comment. } deriving (Typeable) From: Alan & Kim Zimmerman [mailto:alan.zimm at gmail.com] Sent: 27 October 2015 21:36 To: Simon Peyton Jones Subject: Re: dll-split The problem comes in mkGadtDecl, I am pretty sure. If I compare your branch to master, I see that the old one was mkGadtDecl :: [Located RdrName] -> LHsType RdrName -- Always a HsForAllTy -> P ([AddAnn], ConDecl RdrName) mkGadtDecl names (L l ty) = do let (anns,ty') = flattenHsForAllTyKeepAnns ty gadt <- mkGadtDecl' names (L l ty') return (anns,gadt) where the flattenHsForAllTyKeepAnns explicitly pulls out annotations that will get lost when the original type gets broken apart and re-assembled as a ConDecl for the GADT. I do recall having to exercise particular care in this area the first time around, because of the way the original type is turned into a GADT constructor. If this does not help, I can try and dive into what you are doing in more detail tomorrow afternoon some time. Alan On Tue, Oct 27, 2015 at 11:22 PM, Simon Peyton Jones > wrote: Thanks. But why?! Here?s my reasoning, looking at Parser.y ? The RHS of the GADT signature is a ?ctype? ? That parses the ?forall v a.? , and then goes to type, then btype, then atype ? Now we get to the production ?(? ctype ?)? in atype ? And that has mop and mcp to record the location of the parens. It all looks right to me. But NB that now HsForAllTy and HsQualTy are split, so the parens will be attached to the HsQualTy sub-structure. Does that make a difference? Simon From: Alan & Kim Zimmerman [mailto:alan.zimm at gmail.com] Sent: 27 October 2015 21:04 To: Simon Peyton Jones Subject: Re: dll-split I have run the tests on your branch, and can report the following for the failing API annotations tests . T10268 [bad stdout] (normal) - Benign . T10354 [bad stdout] (normal) - Benign . T10396 [bad stdout] (normal) - Benign . T10399 [bad stdout] (normal) - Problem . listcomps [bad stdout] (normal) - Benign For T10399 the problem is the following are missing (AK Test10399.hs:(16,5)-(17,69) AnnCloseP = [Test10399.hs:17:69]) (AK Test10399.hs:(16,5)-(17,69) AnnOpenP = [Test10399.hs:16:27]) These are the outer parens in SetTo4 after the forall : data MaybeDefault v where SetTo :: forall v . ( Eq v, Show v ) => !v -> MaybeDefault v SetTo4 :: forall v a. (( Eq v, Show v ) => v -> MaybeDefault v -> a -> MaybeDefault [a]) I will be documenting the check-api-annotations usage soon, and as part of that will clean it up so that it does not emit gratuitous changes that are benign. Regards Alan On Tue, Oct 27, 2015 at 11:21 AM, Simon Peyton Jones > wrote: Incidentally, Alan, on this particular branch I have some api-annotations failures that I can?t figure out (lacking the user manual that you are writing). I wonder if you could help. Could you possibly build that branch for yourself too? wip/spj-wildcard-refactor Then I can ask you specifics and you?ll have a working branch to poke at. Thanks! Simon From: Alan & Kim Zimmerman [mailto:alan.zimm at gmail.com] Sent: 27 October 2015 09:12 To: Simon Peyton Jones Cc: ghc-devs at haskell.org; Ben Gamari Subject: Re: dll-split I think you need to remove Ctype and Lexer from https://github.com/ghc/ghc/blob/master/compiler/ghc.mk#L498 On 27 Oct 2015 11:06 AM, "Simon Peyton Jones" > wrote: It?s just not my day. Now, on Linux, on my branch wip/spj-wildcard-refactor, I get a failure in dll-split! Should dll-split be running at all on Linux???? The output it produces is below. I?m totally stuck. Help desperately needed. Simon inplace/bin/dll-split compiler/stage2/build/.depend-v-p-dyn.haskell "DynFlags" "Annotations ApiAnnotation Avail Bag BasicTypes Binary BooleanFormula BreakArray BufWrite Class CmdLineParser CmmType CoAxiom ConLike Coercion Config Constants CoreArity CoreFVs CoreSubst CoreSyn CoreTidy CoreUnfold CoreUtils CoreSeq CoreStats CostCentre Ctype DataCon Demand Digraph DriverPhases DynFlags Encoding ErrUtils Exception FamInstEnv FastFunctions FastMutInt FastString FastStringEnv FieldLabel Fingerprint FiniteMap ForeignCall Hooks HsBinds HsDecls HsDoc HsExpr HsImpExp HsLit PlaceHolder HsPat HsSyn HsTypes HsUtils HscTypes IOEnv Id IdInfo IfaceSyn IfaceType InstEnv Kind Lexeme Lexer ListSetOps Literal Maybes MkCore MkId Module MonadUtils Name NameEnv NameSet OccName OccurAnal OptCoercion OrdList Outputable PackageConfig Packages Pair Panic PatSyn PipelineMonad Platform PlatformConstants PprCore PrelNames PrelRules Pretty PrimOp RdrName Rules Serialized SrcLoc StaticFlags StringBuffer TcEvidence TcRnTypes TcType TrieMap TyCon Type TypeRep TysPrim TysWiredIn Unify UniqFM UniqSet UniqSupply Unique Util Var VarEnv VarSet Bitmap BlockId ByteCodeAsm ByteCodeInstr ByteCodeItbls CLabel Cmm CmmCallConv CmmExpr CmmInfo CmmMachOp CmmNode CmmSwitch CmmUtils CodeGen.Platform CodeGen.Platform.ARM CodeGen.Platform.ARM64 CodeGen.Platform.NoRegs CodeGen.Platform.PPC CodeGen.Platform.PPC_Darwin CodeGen.Platform.SPARC CodeGen.Platform.X86 CodeGen.Platform.X86_64 Hoopl Hoopl.Dataflow InteractiveEvalTypes MkGraph PprCmm PprCmmDecl PprCmmExpr Reg RegClass SMRep StgCmmArgRep StgCmmClosure StgCmmEnv StgCmmLayout StgCmmMonad StgCmmProf StgCmmTicky StgCmmUtils StgSyn Stream" Reachable modules from DynFlags out of date Please fix compiler/ghc.mk, or building DLLs on Windows may break (#7780) Redundant modules: Ctype Lexer simonpj at cam-05-unx:~/5builds/HEAD-2$ _______________________________________________ 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 Tue Oct 27 23:24:22 2015 From: ben at well-typed.com (Ben Gamari) Date: Wed, 28 Oct 2015 00:24:22 +0100 Subject: Warning suppression pragmas In-Reply-To: References: <87si4x4m0d.fsf@smart-cactus.org> <33F81532-8E7E-4873-A859-B6AA301DD664@yahoo.com> Message-ID: <87r3kfx5cp.fsf@smart-cactus.org> ????? ?????????? writes: > Hi Ben! > > I concreted some points in local warnings suppression pragmas wiki page > with specification. Hello! Things are definitely improving! I still think you should be more explicit about the possible uses here. In particular, what pain-points felt by users today does this proposal address? If I were you, I would try to collect some small examples of typical code snippets where you might want to put your pragma to use. The recent monad-of-no-return discussion might be a good place to start looking; you likely have some in your own code as well. Place these in the proposal and describe how your pragma would be employed to satisfy these cases. A few other points, * "... that can perform some unsafe actions(unsafe I/O maybe)": Unsafe I/O currently doesn't trigger any warnings that I can think of so this this might not be the best example to use here. * "... you don't want to read such long warning's texts": This also probably isn't the sort of use-case we'd want to design for. The typical use-case here is that you want to tell the compiler that you know something that it doesn't see. * "{-# SUPPRESS #-}": I'm not yet convinced that we want to allow such a blanket pragma. A specific example showing the benefit of such a large hammer would help. * "{-# SUPPRESS foo #-}" What is "foo" here? Be specific! What are the valid tokens you'd want to see here? You might consider having a look at some of the other proposals (e.g. the Custom Type Errors proposal [1]) for some inspiration on how to structure the document. > https://ghc.haskell.org/trac/ghc/wiki/Design/LocalWarningPragmas > Do you know something about defining custom pragmas in GHC? > I suppose, i need to add it to the lexer and parser. > Yes, this would be necessary. > In that case, how can i understand, that GHC recognizes my pragma? > > I want to try a few things on my local machine > Fair enough. Nevertheless, I would encourage you to take think carefully about the proposal before diving too deeply into the code. A bit of forethought can save substantial effort later on! Thanks again for your efforts! Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/wiki/Proposal/CustomTypeErrors -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From dan.doel at gmail.com Tue Oct 27 23:42:13 2015 From: dan.doel at gmail.com (Dan Doel) Date: Tue, 27 Oct 2015 19:42:13 -0400 Subject: Unlifted data types In-Reply-To: References: <1441353701-sup-9422@sabre> <6707b31c94d44af89ba2a90580ac46ce@DB4PR30MB030.064d.mgd.msft.net> <6e2bcecf1a284c62a656e80992e9862e@DB4PR30MB030.064d.mgd.msft.net> <0196B07B-156B-4731-B0A1-CE7A892E0680@cis.upenn.edu> <072d804f206c47aeb49ca7d610d120e5@DB4PR30MB030.064d.mgd.msft.net> <3481E4D1-F4DD-47BA-9818-665F22928CAD@cis.upenn.edu> <89504f03668b4bb18d9d2ef9c2fe5701@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Hello, I've added a section with my notes on the minimal semantics required to address what Haskell lacks with respect to strict types. Ed Kmett pointed me to some stuff that I think may fix all the problems with the !T sort of solution. It builds on the new constraint being considered for handling impredicativity. The quick sketch goes like this. Given the declaration: data Nat = Z | S !Nat then: Nat :: * !Nat :: Unlifted S :: Nat -> Nat But we also have: !Nat <~ Nat and the witness of this is just an identity function, because all values of type !Nat are legitimate values of type Nat. Then we can have: case n of S m -> ... Z -> ... where m has type !Nat, but we can still call `S m` and the like, because !Nat <~ Nat. If we do use `S m`, the S call will do some unnecessary evaluation of m, but this can (hopefully) be fixed with an optimization based on knowing that m has type !Nat, which we are weakening to Nat. Thoughts? -- Dan On Thu, Oct 8, 2015 at 8:36 AM, Richard Eisenberg wrote: > > On Oct 8, 2015, at 6:02 AM, Simon Peyton Jones wrote: > >> What's the wiki page? > > https://ghc.haskell.org/trac/ghc/wiki/UnliftedDataTypes From johnw at newartisans.com Wed Oct 28 02:35:09 2015 From: johnw at newartisans.com (John Wiegley) Date: Tue, 27 Oct 2015 19:35:09 -0700 Subject: dns issues with ghc.haskell.org In-Reply-To: <562190C7.7060403@informatik.uni-kiel.de> (lennart spitzner's message of "Sat, 17 Oct 2015 02:05:27 +0200") References: <562190C7.7060403@informatik.uni-kiel.de> Message-ID: >>>>> lennart spitzner writes: > I have not observed a failure of this kind for any other server. I don't > really know what could be the issue or how to diagnose this further. If it > helps, in this case (have not checked when this occurred previously): > "wrong" address 162.242.239.16 > "correct" 104.25.122.13 Hi Lennart, Can you use dig, or host, or dnstrace to determine which server is providing the information? It could be that that server is not updating. Find me as "johnw" on IRC, if you're around. John From ekmett at gmail.com Wed Oct 28 03:35:01 2015 From: ekmett at gmail.com (Edward Kmett) Date: Tue, 27 Oct 2015 23:35:01 -0400 Subject: Temporarily pinning a thread to a capability Message-ID: Would anything go wrong with a thread id if I pinned it to a capability after the fact? I could in theory do so just by setting tso->flags |= TSO_LOCKED and then disabling this later by restoring the TSO flags. I can't think of anything but I figured folks here might be able to think of invariants I don't know about. Usage scenario: I have a number of things where I can't afford a map from a ThreadId# or even its internal id to a per-thread value for bounded wait-free structures. On the other hand, I can afford one entry per capability and to make a handful of primitives that can't be preempted, letting me use normal writes, not even a CAS, to update the capability-local variable in a primitive (indexing into an array of size based on the number of capabilities). This lets me bound the amount of "helpers" to consider by the capability count rather than the potentially much larger and much more variable number of live threads. However, I may need to access this stuff in "pure" code that wasn't written with my needs in mind, so I need to at least temporarily pin the current thread to a fixed capability for the duration when that happens. This isn't perfect, it won't react to a growing number of capabilities nicely in the future, but it does handle a lot of things I can't do now at all without downgrading to lock-free and starving a lot of computations, so I'm hoping the answer is "it all works". =) -Edward -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Wed Oct 28 03:53:25 2015 From: ekmett at gmail.com (Edward Kmett) Date: Tue, 27 Oct 2015 23:53:25 -0400 Subject: Unlifted data types In-Reply-To: References: <1441353701-sup-9422@sabre> <6707b31c94d44af89ba2a90580ac46ce@DB4PR30MB030.064d.mgd.msft.net> <6e2bcecf1a284c62a656e80992e9862e@DB4PR30MB030.064d.mgd.msft.net> <0196B07B-156B-4731-B0A1-CE7A892E0680@cis.upenn.edu> <072d804f206c47aeb49ca7d610d120e5@DB4PR30MB030.064d.mgd.msft.net> <3481E4D1-F4DD-47BA-9818-665F22928CAD@cis.upenn.edu> <89504f03668b4bb18d9d2ef9c2fe5701@DB4PR30MB030.064d.mgd.msft.net> Message-ID: The idea of treating !S as a subtype of S and then relying on the potential for new impredicativity machinery to let us just talk about how !S <= S makes me really happy. data Nat = Z | S !Nat Pattern matching on S could give back the tighter type !Nat rather than Nat for the argument, and if we ever have to show that to a user, the 'approximation' machinery would show it to users as Nat, concealing this implementation detail. Similarly matching with an as-pattern as part of a pattern that evaluates could do the same. The constructor is a bit messier. It should really give back S :: Nat -> Nat as what the constructor should behave as rather than S :: !Nat -> Nat, because this will match existing behavior. Then the exposed constructor would force the argument before storing it away, just like we do today and we could recover via a sort of peephole optimization the elimination of the jump into the closure to evaluate when it is fed something known to be of type !Nat by some kind of "case/(!)-coercion" rule in the optimizer. I'm partial to those parts of the idea and think it works pretty well. I'm not sure how well it mixes with all the other discussions on levity polymorphism though. Notably: Trying to get to having !Nat live in an Unlifted kind, while Nat has a different kind seems likely to cause all sorts of headaches. =/ -Edward On Tue, Oct 27, 2015 at 7:42 PM, Dan Doel wrote: > Hello, > > I've added a section with my notes on the minimal semantics required > to address what Haskell lacks with respect to strict types. > > Ed Kmett pointed me to some stuff that I think may fix all the > problems with the !T sort of solution. It builds on the new constraint > being considered for handling impredicativity. The quick sketch goes > like this. Given the declaration: > > data Nat = Z | S !Nat > > then: > > Nat :: * > !Nat :: Unlifted > S :: Nat -> Nat > > But we also have: > > !Nat <~ Nat > > and the witness of this is just an identity function, because all > values of type !Nat are legitimate values of type Nat. Then we can > have: > > case n of > S m -> ... > Z -> ... > > where m has type !Nat, but we can still call `S m` and the like, > because !Nat <~ Nat. If we do use `S m`, the S call will do some > unnecessary evaluation of m, but this can (hopefully) be fixed with an > optimization based on knowing that m has type !Nat, which we are > weakening to Nat. > > Thoughts? > > -- Dan > > > On Thu, Oct 8, 2015 at 8:36 AM, Richard Eisenberg > wrote: > > > > On Oct 8, 2015, at 6:02 AM, Simon Peyton Jones > wrote: > > > >> What's the wiki page? > > > > https://ghc.haskell.org/trac/ghc/wiki/UnliftedDataTypes > _______________________________________________ > 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 Wed Oct 28 09:05:07 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 28 Oct 2015 09:05:07 +0000 Subject: Unlifted data types In-Reply-To: References: <1441353701-sup-9422@sabre> <6707b31c94d44af89ba2a90580ac46ce@DB4PR30MB030.064d.mgd.msft.net> <6e2bcecf1a284c62a656e80992e9862e@DB4PR30MB030.064d.mgd.msft.net> <0196B07B-156B-4731-B0A1-CE7A892E0680@cis.upenn.edu> <072d804f206c47aeb49ca7d610d120e5@DB4PR30MB030.064d.mgd.msft.net> <3481E4D1-F4DD-47BA-9818-665F22928CAD@cis.upenn.edu> <89504f03668b4bb18d9d2ef9c2fe5701@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <8544949590964b74a1733a053e362562@DB4PR30MB030.064d.mgd.msft.net> I'm out of bandwidth at the moment, but let me just remark that this is swampy territory. It's easy to mess up. A particular challenge is polymorphism: map :: forall a b. (a->b) -> [a] -> [b] map f (x:xs) = (f x) : (map f xs) In the compiled code for map, is a thunk built for (f x), or is it evaluated eagerly. Well, if you can instantiate the 'b' with !Int, say, then it should be evaluated eagerly. But if you instantiate with Int, then build a thunk. So, we really need two compiled versions of 'map'. Or perhaps four if we take 'b' into account. In general an exponential number. That's one reason that GHC doesn't let you instantiate a polymorphic type variable with an unlifted type, even if it is boxed. That is the reason that in "Types are calling conventions" we turn the entire intermediate language around, to make it call-by-value; and add a lazy type constructor. Not Int and (Strict Int), but rather Int and (Lazy Int). Another big issue is that *any* mixture of subtyping and (Haskell-style) parametric polymorphism gets very complicated very fast. Especially when you add higher kinds. (Then you need variance annotations, and before long you want variance polymorphism.) I'm extremely dubious about adding subtyping to Haskell. That's one reason Scala is so complicated. As a way to keep the discussion sane, I'd suggest focusing initially on the *intermediate language*, ignoring the source-language issues. That's what we did in "Types as calling conventions". There is a chance of writing out a complete syntax, a complete type system, and a complete operational semantics; and proving soundness etc. Once that foundation is done we can think about the source language. Finally, there may be low-hanging fruit to be had. Maybe we can get a lot more benefit without completely re-imagining GHC! Let's do that first. (I think that some of the proposals on the wiki page were in that direction.) But even for the low hanging fruit, getting the intermediate language changes (Core) nailed first would be good. Bur re-imagining GHC is good too. Swampy territory it may be, but it's also important, and there really *ought* to be a more seamless of combining strictness and laziness. Simon | -----Original Message----- | From: Dan Doel [mailto:dan.doel at gmail.com] | Sent: 27 October 2015 23:42 | To: Richard Eisenberg | Cc: Simon Peyton Jones; ghc-devs | Subject: Re: Unlifted data types | | Hello, | | I've added a section with my notes on the minimal semantics required to | address what Haskell lacks with respect to strict types. | | Ed Kmett pointed me to some stuff that I think may fix all the problems with | the !T sort of solution. It builds on the new constraint being considered | for handling impredicativity. The quick sketch goes like this. Given the | declaration: | | data Nat = Z | S !Nat | | then: | | Nat :: * | !Nat :: Unlifted | S :: Nat -> Nat | | But we also have: | | !Nat <~ Nat | | and the witness of this is just an identity function, because all values of | type !Nat are legitimate values of type Nat. Then we can | have: | | case n of | S m -> ... | Z -> ... | | where m has type !Nat, but we can still call `S m` and the like, because | !Nat <~ Nat. If we do use `S m`, the S call will do some unnecessary | evaluation of m, but this can (hopefully) be fixed with an optimization | based on knowing that m has type !Nat, which we are weakening to Nat. | | Thoughts? | | -- Dan | | | On Thu, Oct 8, 2015 at 8:36 AM, Richard Eisenberg wrote: | > | > On Oct 8, 2015, at 6:02 AM, Simon Peyton Jones | wrote: | > | >> What's the wiki page? | > | > https://ghc.haskell.org/trac/ghc/wiki/UnliftedDataTypes From ekmett at gmail.com Wed Oct 28 09:48:39 2015 From: ekmett at gmail.com (Edward Kmett) Date: Wed, 28 Oct 2015 05:48:39 -0400 Subject: Unlifted data types In-Reply-To: <8544949590964b74a1733a053e362562@DB4PR30MB030.064d.mgd.msft.net> References: <1441353701-sup-9422@sabre> <6707b31c94d44af89ba2a90580ac46ce@DB4PR30MB030.064d.mgd.msft.net> <6e2bcecf1a284c62a656e80992e9862e@DB4PR30MB030.064d.mgd.msft.net> <0196B07B-156B-4731-B0A1-CE7A892E0680@cis.upenn.edu> <072d804f206c47aeb49ca7d610d120e5@DB4PR30MB030.064d.mgd.msft.net> <3481E4D1-F4DD-47BA-9818-665F22928CAD@cis.upenn.edu> <89504f03668b4bb18d9d2ef9c2fe5701@DB4PR30MB030.064d.mgd.msft.net> <8544949590964b74a1733a053e362562@DB4PR30MB030.064d.mgd.msft.net> Message-ID: On Wed, Oct 28, 2015 at 5:05 AM, Simon Peyton Jones wrote: > I'm out of bandwidth at the moment, but let me just remark that this is > swampy territory. It's easy to mess up. > > A particular challenge is polymorphism: > > map :: forall a b. (a->b) -> [a] -> [b] > map f (x:xs) = (f x) : (map f xs) > > In the compiled code for map, is a thunk built for (f x), or is it > evaluated eagerly. Well, if you can instantiate the 'b' with !Int, say, > then it should be evaluated eagerly. But if you instantiate with Int, then > build a thunk. So, we really need two compiled versions of 'map'. Or > perhaps four if we take 'b' into account. In general an exponential number. > That's one reason that GHC doesn't let you instantiate a polymorphic type > variable with an unlifted type, even if it is boxed. > This is one of the things we'd like to be able to fix. Right now I have a small explosion of code going on that is being duplicated over and over to parameterize over different unlifted types. In the discussions about levity/lifting so far Dan and I have been trying to tease apart what cases can be handled "forall" style rather than "pi" style to borrow the split from Richard's presentation, just to get at a sense of what really could be talked about without needing different calling conventions, despite lifting. There are situations where we are truly polymorphic in lifting, e.g. (==) from Eq and compare from Ord don't care if the arguments of type 'a' are lifted or not. Until you go to write a function application that returns a value of that type. If all you do is rearrange them then that machinery can be parametric in the choice. `map` on the other hand, cares about the selection because of the `f x` application. (Similarly, `min` and `max` from Ord do care about the convention on hand.) One could see a world wherein you could parameterize such an instance on levity explicitly, but it is pretty exhausting to think about. > Another big issue is that *any* mixture of subtyping and (Haskell-style) > parametric polymorphism gets very complicated very fast. Especially when > you add higher kinds. (Then you need variance annotations, and before long > you want variance polymorphism.) I'm extremely dubious about adding > subtyping to Haskell. That's one reason Scala is so complicated. > I was actually quite surprised to see a subtyping relationship rear its head in: https://ghc.haskell.org/trac/ghc/attachment/wiki/ImpredicativePolymorphism/Impredicative-2015/impredicativity.pdf But re-imagining GHC is good too. Swampy territory it may be, but it's > also important, and there really *ought* to be a more seamless of combining > strictness and laziness. I'm somewhat dubious of most approaches that try to mix strictness and laziness under one umbrella. That is why trying to tease out the small handful of cases where we are truly parametric in levity seems interesting. Finding out some situations existed where we really don't care if a type is lifted or not was eye opening to me personally, at least. -Edward > | -----Original Message----- > | From: Dan Doel [mailto:dan.doel at gmail.com] > | Sent: 27 October 2015 23:42 > | To: Richard Eisenberg > | Cc: Simon Peyton Jones; ghc-devs > | Subject: Re: Unlifted data types > | > | Hello, > | > | I've added a section with my notes on the minimal semantics required to > | address what Haskell lacks with respect to strict types. > | > | Ed Kmett pointed me to some stuff that I think may fix all the problems > with > | the !T sort of solution. It builds on the new constraint being > considered > | for handling impredicativity. The quick sketch goes like this. Given the > | declaration: > | > | data Nat = Z | S !Nat > | > | then: > | > | Nat :: * > | !Nat :: Unlifted > | S :: Nat -> Nat > | > | But we also have: > | > | !Nat <~ Nat > | > | and the witness of this is just an identity function, because all > values of > | type !Nat are legitimate values of type Nat. Then we can > | have: > | > | case n of > | S m -> ... > | Z -> ... > | > | where m has type !Nat, but we can still call `S m` and the like, because > | !Nat <~ Nat. If we do use `S m`, the S call will do some unnecessary > | evaluation of m, but this can (hopefully) be fixed with an optimization > | based on knowing that m has type !Nat, which we are weakening to Nat. > | > | Thoughts? > | > | -- Dan > | > | > | On Thu, Oct 8, 2015 at 8:36 AM, Richard Eisenberg > wrote: > | > > | > On Oct 8, 2015, at 6:02 AM, Simon Peyton Jones > > | wrote: > | > > | >> What's the wiki page? > | > > | > https://ghc.haskell.org/trac/ghc/wiki/UnliftedDataTypes > _______________________________________________ > 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 Oct 28 11:39:38 2015 From: ben at well-typed.com (Ben Gamari) Date: Wed, 28 Oct 2015 12:39:38 +0100 Subject: Type-level error messages In-Reply-To: References: <156b77b4a1a444c7a8d4465d4d941c9d@AM3PR30MB019.064d.mgd.msft.net> <8dd0d26809c543e88c9e2da6f91a8f2d@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <87d1vzw7b9.fsf@smart-cactus.org> Iavor Diatchki writes: >> I think that the branch should be in an OK state, except that it is not >> merged with the latest HEAD. > It does look pretty reasonable but keep in mind that there are a number of comments on the Phabricator Diff that still need to be addressed. Thanks! - 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 Wed Oct 28 13:19:14 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Wed, 28 Oct 2015 09:19:14 -0400 Subject: Unlifted data types In-Reply-To: References: <1441353701-sup-9422@sabre> <6707b31c94d44af89ba2a90580ac46ce@DB4PR30MB030.064d.mgd.msft.net> <6e2bcecf1a284c62a656e80992e9862e@DB4PR30MB030.064d.mgd.msft.net> <0196B07B-156B-4731-B0A1-CE7A892E0680@cis.upenn.edu> <072d804f206c47aeb49ca7d610d120e5@DB4PR30MB030.064d.mgd.msft.net> <3481E4D1-F4DD-47BA-9818-665F22928CAD@cis.upenn.edu> <89504f03668! b4bb18d9d2ef9c2fe5701@DB4PR30MB030.064d.mgd.msft.net> <8544949590964b74a1733a053e362562@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <440230C1-0744-43C4-B1DD-158032BA92CD@cis.upenn.edu> I don't have terribly much to add, but I do want to counter one point: On Oct 28, 2015, at 5:48 AM, Edward Kmett wrote: > There are situations where we are truly polymorphic in lifting, e.g. (==) from Eq and compare from Ord don't care if the arguments of type 'a' are lifted or not. But these do, I think. In running code, if (==) is operating over a lazy type, it has to check if the pointer points to a thunk. If (==) is operating over a strict one, it can skip the check. This is not a big difference, but it *is* a difference. A little more thinking about this has led here: The distinction isn't really forall vs. pi. That is, in the cases where the levity matters, we don't really need to pi-quantify. Instead, it's exactly like type classes. Imagine, for a moment, that we have an alternate universe where strict is the default, and we have > data Lazy a = Thunk (() -> a) | WHNF a The WHNF is a bit of a lie, because this representation would mean that the contents of a WHNF are fully evaluated. But let's not get hung up on that point. Then, we have > type family BaseType a where > BaseType (Lazy a) = a > BaseType a = a > > class Forceable a where > force :: a -> BaseType a > > instance Forceable a where > force = id > > instance Forceable (Lazy a) where > force (Thunk f) = f () > force (WHNF a) = a Things that need to behave differently depending on strictness just take a dictionary of the Forceable class. Equivalently, they make a runtime decision of whether to force or not. So we don't need an exponential number of maps. We need a map that makes some runtime decisions. And the optimizer can be taught that specializing these decisions may be helpful. Of course, none of this would be exposed. And I'm not suggesting that we need to make the core language strict-by-default. But it clarified things, for me at least, when I realized this is regular old ad-hoc polymorphism, not something fancier. Richard From eir at cis.upenn.edu Wed Oct 28 13:23:35 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Wed, 28 Oct 2015 09:23:35 -0400 Subject: Type-level error messages In-Reply-To: <87d1vzw7b9.fsf@smart-cactus.org> References: <156b77b4a1a444c7a8d4465d4d941c9d@AM3PR30MB019.064d.mgd.msft.net> <8dd0d26809c543e88c9e2da6f91a8f2d@DB4PR30MB030.064d.mgd.msft.net> <87d1vzw7b9.fsf@smart-cactus.org> Message-ID: <67A9BC36-A272-4D61-8025-216E0ED0241A@cis.upenn.edu> On Oct 28, 2015, at 7:39 AM, Ben Gamari wrote: > It does look pretty reasonable but keep in mind that there are a number > of comments on the Phabricator Diff that still need to be addressed. And I have three burning questions at the bottom of the wiki page https://ghc.haskell.org/trac/ghc/wiki/Proposal/CustomTypeErrors. The first, in particular, needs to be addressed to make this feature useful. Richard From eir at cis.upenn.edu Wed Oct 28 14:07:10 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Wed, 28 Oct 2015 10:07:10 -0400 Subject: Type-level error messages In-Reply-To: <22B950C955F8AB4196E72698FBD00002D02ABFAB@UKWPIPXMB01A.zone1.scb.net> References: <156b77b4a1a444c7a8d4465d4d941c9d@AM3PR30MB019.064d.mgd.msft.net> <8dd0d26809c543e88c9e2da6f91a8f2d@DB4PR30MB030.064d.mgd.msft.net> <87d1vzw7b9.fsf@smart-cactus.org> <67A9BC36-A272-4D61-8025-216E0ED0241A@cis.upenn.edu> <22B950C955F8AB4196E72698FBD00002D02ABFAB@UKWPIPXMB01A.zone1.scb.net> Message-ID: On Oct 28, 2015, at 10:02 AM, "Augustsson, Lennart" wrote: > I've put in my answers to your questions. And I've responded. From alan.zimm at gmail.com Wed Oct 28 14:20:21 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Wed, 28 Oct 2015 16:20:21 +0200 Subject: GADT decls In-Reply-To: <525e5e79f90c4c45aa699c05d100e81d@DB4PR30MB030.064d.mgd.msft.net> References: <525e5e79f90c4c45aa699c05d100e81d@DB4PR30MB030.064d.mgd.msft.net> Message-ID: I think this is a good idea Alan On Wed, Oct 28, 2015 at 12:17 AM, Simon Peyton Jones wrote: > Ahh. I think I get it. The trouble is that ConDecl doesn?t have the same > structure as what the user wrote. > > > > Maybe we should just fix that? How about this declaration? Would that > make the annotations easier? Ie simple and routine. > > > > Simon > > > > data ConDecl name > > | ConDeclGADT > > { con_names :: [Located name] > > , con_type :: LHsSigType name -- After the ?::? > > , con_doc :: Maybe LHsDocString > > , con_old_rec :: Bool } > > > > | ConDeclH98 > > { con_name :: Located name > > > > , con_implict :: HsImplicitBndrs () > > -- ^ Implicit binders, added by renamer > > > > , con_qvars :: Maybe [LHsTyVarBndr name] > > -- User-written foralls (if any) > > > > , con_cxt :: Maybe (LHsContext name) > > -- ^ User-written context (if any) > > > > , con_details :: HsConDeclDetails name > > -- ^ Arguments > > > > , con_doc :: Maybe LHsDocString > > -- ^ A possible Haddock comment. > > } deriving (Typeable) > > > > *From:* Alan & Kim Zimmerman [mailto:alan.zimm at gmail.com] > *Sent:* 27 October 2015 21:36 > *To:* Simon Peyton Jones > *Subject:* Re: dll-split > > > > The problem comes in mkGadtDecl, I am pretty sure. > > If I compare your branch to master, I see that the old one was > > mkGadtDecl :: [Located RdrName] > -> LHsType RdrName -- Always a HsForAllTy > -> P ([AddAnn], ConDecl RdrName) > mkGadtDecl names (L l ty) = do > let > (anns,ty') = flattenHsForAllTyKeepAnns ty > gadt <- mkGadtDecl' names (L l ty') > return (anns,gadt) > > where the flattenHsForAllTyKeepAnns explicitly pulls out annotations that > will get lost when the original type gets broken apart and re-assembled as > a ConDecl for the GADT. > > I do recall having to exercise particular care in this area the first time > around, because of the way the original type is turned into a GADT > constructor. > > If this does not help, I can try and dive into what you are doing in more > detail tomorrow afternoon some time. > > Alan > > > > > > > > On Tue, Oct 27, 2015 at 11:22 PM, Simon Peyton Jones < > simonpj at microsoft.com> wrote: > > Thanks. But why?! Here?s my reasoning, looking at Parser.y > > > > ? The RHS of the GADT signature is a ?ctype? > > ? That parses the ?forall v a.? , and then goes to type, then > btype, then atype > > ? Now we get to the production ?(? ctype ?)? in atype > > ? And that has mop and mcp to record the location of the parens. > > > > It all looks right to me. But NB that now HsForAllTy and HsQualTy are > split, so the parens will be attached to the HsQualTy sub-structure. Does > that make a difference? > > > > Simon > > > > *From:* Alan & Kim Zimmerman [mailto:alan.zimm at gmail.com] > *Sent:* 27 October 2015 21:04 > *To:* Simon Peyton Jones > *Subject:* Re: dll-split > > > > I have run the tests on your branch, and can report the following for the > failing API annotations tests > > . T10268 [bad stdout] (normal) - Benign > . T10354 [bad stdout] (normal) - Benign > . T10396 [bad stdout] (normal) - Benign > . T10399 [bad stdout] (normal) - Problem > . listcomps [bad stdout] (normal) - Benign > > For T10399 the problem is the following are missing > > (AK Test10399.hs:(16,5)-(17,69) AnnCloseP = [Test10399.hs:17:69]) > (AK Test10399.hs:(16,5)-(17,69) AnnOpenP = [Test10399.hs:16:27]) > > These are the outer parens in SetTo4 after the forall : > > data MaybeDefault v where > SetTo :: forall v . ( Eq v, Show v ) => !v -> MaybeDefault v > SetTo4 :: forall v a. (( Eq v, Show v ) => v -> MaybeDefault v > -> a -> MaybeDefault [a]) > > I will be documenting the check-api-annotations usage soon, and as part of > that will clean it up so that it does not emit gratuitous changes that are > benign. > > Regards > > Alan > > > > > > > > On Tue, Oct 27, 2015 at 11:21 AM, Simon Peyton Jones < > simonpj at microsoft.com> wrote: > > Incidentally, Alan, on this particular branch I have some api-annotations > failures that I can?t figure out (lacking the user manual that you are > writing). I wonder if you could help. Could you possibly build that > branch for yourself too? wip/spj-wildcard-refactor > > > > Then I can ask you specifics and you?ll have a working branch to poke at. > Thanks! > > > > Simon > > > > > > *From:* Alan & Kim Zimmerman [mailto:alan.zimm at gmail.com] > *Sent:* 27 October 2015 09:12 > *To:* Simon Peyton Jones > *Cc:* ghc-devs at haskell.org; Ben Gamari > *Subject:* Re: dll-split > > > > I think you need to remove Ctype and Lexer from > https://github.com/ghc/ghc/blob/master/compiler/ghc.mk#L498 > > > On 27 Oct 2015 11:06 AM, "Simon Peyton Jones" > wrote: > > It?s just not my day. > > Now, on Linux, on my branch wip/spj-wildcard-refactor, I get a failure in > dll-split! Should dll-split be running at all on Linux???? > > The output it produces is below. > > I?m totally stuck. Help desperately needed. > > Simon > > > > inplace/bin/dll-split compiler/stage2/build/.depend-v-p-dyn.haskell > "DynFlags" "Annotations ApiAnnotation Avail Bag BasicTypes Binary > BooleanFormula BreakArray BufWrite Class CmdLineParser CmmType CoAxiom > ConLike Coercion Config Constants CoreArity CoreFVs CoreSubst CoreSyn > CoreTidy CoreUnfold CoreUtils CoreSeq CoreStats CostCentre Ctype DataCon > Demand Digraph DriverPhases DynFlags Encoding ErrUtils Exception FamInstEnv > FastFunctions FastMutInt FastString FastStringEnv FieldLabel Fingerprint > FiniteMap ForeignCall Hooks HsBinds HsDecls HsDoc HsExpr HsImpExp HsLit > PlaceHolder HsPat HsSyn HsTypes HsUtils HscTypes IOEnv Id IdInfo IfaceSyn > IfaceType InstEnv Kind Lexeme Lexer ListSetOps Literal Maybes MkCore MkId > Module MonadUtils Name NameEnv NameSet OccName OccurAnal OptCoercion > OrdList Outputable PackageConfig Packages Pair Panic PatSyn PipelineMonad > Platform PlatformConstants PprCore PrelNames PrelRules Pretty PrimOp > RdrName Rules Serialized SrcLoc StaticFlags StringBuffer TcEvidence > TcRnTypes TcType TrieMap TyCon Type TypeRep TysPrim TysWiredIn Unify UniqFM > UniqSet UniqSupply Unique Util Var VarEnv VarSet Bitmap BlockId ByteCodeAsm > ByteCodeInstr ByteCodeItbls CLabel Cmm CmmCallConv CmmExpr CmmInfo > CmmMachOp CmmNode CmmSwitch CmmUtils CodeGen.Platform CodeGen.Platform.ARM > CodeGen.Platform.ARM64 CodeGen.Platform.NoRegs CodeGen.Platform.PPC > CodeGen.Platform.PPC_Darwin CodeGen.Platform.SPARC CodeGen.Platform.X86 > CodeGen.Platform.X86_64 Hoopl Hoopl.Dataflow InteractiveEvalTypes MkGraph > PprCmm PprCmmDecl PprCmmExpr Reg RegClass SMRep StgCmmArgRep StgCmmClosure > StgCmmEnv StgCmmLayout StgCmmMonad StgCmmProf StgCmmTicky StgCmmUtils > StgSyn Stream" > > Reachable modules from DynFlags out of date > > Please fix compiler/ghc.mk > , > or building DLLs on Windows may break (#7780) > > Redundant modules: Ctype Lexer > > simonpj at cam-05-unx:~/5builds/HEAD-2$ > > > _______________________________________________ > 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 dan.doel at gmail.com Wed Oct 28 15:03:23 2015 From: dan.doel at gmail.com (Dan Doel) Date: Wed, 28 Oct 2015 11:03:23 -0400 Subject: Unlifted data types In-Reply-To: <8544949590964b74a1733a053e362562@DB4PR30MB030.064d.mgd.msft.net> References: <1441353701-sup-9422@sabre> <6707b31c94d44af89ba2a90580ac46ce@DB4PR30MB030.064d.mgd.msft.net> <6e2bcecf1a284c62a656e80992e9862e@DB4PR30MB030.064d.mgd.msft.net> <0196B07B-156B-4731-B0A1-CE7A892E0680@cis.upenn.edu> <072d804f206c47aeb49ca7d610d120e5@DB4PR30MB030.064d.mgd.msft.net> <3481E4D1-F4DD-47BA-9818-665F22928CAD@cis.upenn.edu> <89504f03668b4bb18d9d2ef9c2fe5701@DB4PR30MB030.064d.mgd.msft.net> <8544949590964b74a1733a053e362562@DB4PR30MB030.064d.mgd.msft.net> Message-ID: On Wed, Oct 28, 2015 at 5:05 AM, Simon Peyton Jones wrote: > I'm out of bandwidth at the moment, but let me just remark that this is swampy territory. It's easy to mess up. > > A particular challenge is polymorphism: > > map :: forall a b. (a->b) -> [a] -> [b] > map f (x:xs) = (f x) : (map f xs) > > In the compiled code for map, is a thunk built for (f x), or is it evaluated eagerly. Well, if you can instantiate the 'b' with !Int, say, then it should be evaluated eagerly. But if you instantiate with Int, then build a thunk. So, we really need two compiled versions of 'map'. Or perhaps four if we take 'b' into account. In general an exponential number. You can't insantiate `b` to `!Int` without map quantifying over levity, which is somewhat orthogonal (although it would have interactions). Without that, b has kind *, and !Int has kind Unlifted, so this is a kind error. Or, map is explicitly written having b :: Unlifted, in which case it already has the right calling convention. > That's one reason that GHC doesn't let you instantiate a polymorphic type variable with an unlifted type, even if it is boxed. It's a reason to not put boxed, unlifted types in *. I don't think it's a reason not to allow quantifying over a separate kind of uniformly represented, unlifted types (i.e. doesn't include Int#, Double#, etc.). > Another big issue is that *any* mixture of subtyping and (Haskell-style) parametric polymorphism gets very complicated very fast. Especially when you add higher kinds. (Then you need variance annotations, and before long you want variance polymorphism.) I'm extremely dubious about adding subtyping to Haskell. That's one reason Scala is so complicated. I'm not sure how much of this would be required. But how are you saved from this in the impredicativity proposal, which is already attempting to handle more of the induced subtyping of higher-rank types? I would guess it's mostly a matter of, "we're not going to support all that." Which might be fine for the unlifted stuff as well. Richard wrote: > But these do, I think. In running code, if (==) is operating over a lazy type, it has to check if the pointer points to a thunk. If (==) is operating over a strict one, it can skip the check. This is not a big difference, but it *is* a difference. Yeah. It's not that (==) is parametric really. It's that Eq might be able to be parameterized on levity. But this is very useful, since it allows you to instantiate Eq on a bunch of unlifted reference types instead of having to use one-off functions like sameMutableArray#. > A little more thinking about this has led here: The distinction isn't really forall vs. pi. That is, in the cases where the levity matters, we don't really need to pi-quantify. Instead, it's exactly like type classes. Yes, I think so, too. It is ad-hoc polymorphism that can be handled by type classes. There is no reason for an explicit value-level witness of levity that can be cased on, which is presumably what pi would allow. From ekmett at gmail.com Wed Oct 28 15:49:15 2015 From: ekmett at gmail.com (Edward Kmett) Date: Wed, 28 Oct 2015 11:49:15 -0400 Subject: Unlifted data types In-Reply-To: <440230C1-0744-43C4-B1DD-158032BA92CD@cis.upenn.edu> References: <1441353701-sup-9422@sabre> <6707b31c94d44af89ba2a90580ac46ce@DB4PR30MB030.064d.mgd.msft.net> <6e2bcecf1a284c62a656e80992e9862e@DB4PR30MB030.064d.mgd.msft.net> <0196B07B-156B-4731-B0A1-CE7A892E0680@cis.upenn.edu> <072d804f206c47aeb49ca7d610d120e5@DB4PR30MB030.064d.mgd.msft.net> <3481E4D1-F4DD-47BA-9818-665F22928CAD@cis.upenn.edu> <8544949590964b74a1733a053e362562@DB4PR30MB030.064d.mgd.msft.net> <440230C1-0744-43C4-B1DD-158032BA92CD@cis.upenn.edu> Message-ID: On Wed, Oct 28, 2015 at 9:19 AM, Richard Eisenberg wrote: > I don't have terribly much to add, but I do want to counter one point: > > On Oct 28, 2015, at 5:48 AM, Edward Kmett wrote: > > There are situations where we are truly polymorphic in lifting, e.g. > (==) from Eq and compare from Ord don't care if the arguments of type 'a' > are lifted or not. > > But these do, I think. In running code, if (==) is operating over a lazy > type, it has to check if the pointer points to a thunk. If (==) is > operating over a strict one, it can skip the check. This is not a big > difference, but it *is* a difference. > Yes, but this is the job of the particular instance. Remember the instance gets to know the type it is working at, and its corresponding levity. class Eq (l :: Levity) (t :: Type l) where (==) :: a -> a -> Bool instance Eq @Unlifted (SmallMutableArray s a) where (==) = sameSmallMutableArray instance Eq @Lifted [] where (==) = ... Your objection arises for things like instance Eq @l (Foo @l) Where the same code has to execute with different levities, but if I can't even case or seq on a value with polymorphic levity, and can't construct such a value but merely pass it around then such code is still sound. It isn't safe to write functions that return values of polymorphic levity. I can however hand them back as (# a #). This is how we handle indexing into a array today. If we had a Maybe that was levity polymorphic in its argument Maybe :: forall (l :: Levity). Type l -> Lifted instance Eq @l a => Eq @Lifted (Maybe @l a) where Just a == Just b = a == b _ == _ = False is still okay under these rules, it never case analyzes a value of polymorphic levity, never seq's it. Neither of those things is legal because you can't 'enter' the closure. If it was levity polymorphic in the result type Maybe :: forall (i :: Levity) (j :: Levity). Type i -> Type j then your objection comes true. I can't naively write: instance Eq @i a => Eq j (Maybe @i @j a) where Just a == Just b = a == b _ == _ = False without compiling the same code twice, because of the act of case analysis. If we don't have real 'strict data types' in Lifted this situation never arises though. Even if we do I can write separate: instance Eq @i a => Eq Lifted (Maybe @i Lifted a) instance Eq @i a => Eq Unlifted (Maybe @i Unlifted a) instances, unless we can do better by writing a class constraint on the levity that we can use in a clever way here. I'm mostly concerned with the middle case where we don't overload data types on their levity, and try to recover the ability to talk about strict data types by other more explicit means, but rather permit them to accept arguments of different levities. There none of the code I care about actually needs to act differently based on levity. Anything that results in a function space there has to care about levity, but until a type occurs on the right hand side of an (->) or I go to seq a value of that type or case analyze it, I don't need to care about if its lifted or unlifted. With Dan's (!S) then things get more complicated in ways I don't fully understand the ramifications of yet, as you might be able to lift some of those restrictions. A little more thinking about this has led here: The distinction isn't > really forall vs. pi. That is, in the cases where the levity matters, we > don't really need to pi-quantify. Instead, it's exactly like type classes. > In many ways pi comes down to doing typeclass like things, you're tracking information from the type system. The vehicle we have for doing that today is typeclasses. I've been thinking about anything that i have that actually needs the "pi" there as a form of "constraint" passing all along, with the constraint being whatever introspection you need to allow on the type to carry on. Imagine, for a moment, that we have an alternate universe where strict is > the default, and we have > > > data Lazy a = Thunk (() -> a) | WHNF a > > The WHNF is a bit of a lie, because this representation would mean that > the contents of a WHNF are fully evaluated. But let's not get hung up on > that point. > > Then, we have > > > type family BaseType a where > > BaseType (Lazy a) = a > > BaseType a = a > > > > class Forceable a where > > force :: a -> BaseType a > > > > instance Forceable a where > > force = id > > > > instance Forceable (Lazy a) where > > force (Thunk f) = f () > > force (WHNF a) = a > > Things that need to behave differently depending on strictness just take a > dictionary of the Forceable class. Equivalently, they make a runtime > decision of whether to force or not. So we don't need an exponential number > of maps. We need a map that makes some runtime decisions. And the optimizer > can be taught that specializing these decisions may be helpful. > > Of course, none of this would be exposed. And I'm not suggesting that we > need to make the core language strict-by-default. But it clarified things, > for me at least, when I realized this is regular old ad-hoc polymorphism, > not something fancier. Yep. -Edward -------------- next part -------------- An HTML attachment was scrubbed... URL: From iavor.diatchki at gmail.com Wed Oct 28 17:17:54 2015 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Wed, 28 Oct 2015 10:17:54 -0700 Subject: Type-level error messages In-Reply-To: References: <156b77b4a1a444c7a8d4465d4d941c9d@AM3PR30MB019.064d.mgd.msft.net> <8dd0d26809c543e88c9e2da6f91a8f2d@DB4PR30MB030.064d.mgd.msft.net> <87d1vzw7b9.fsf@smart-cactus.org> <67A9BC36-A272-4D61-8025-216E0ED0241A@cis.upenn.edu> <22B950C955F8AB4196E72698FBD00002D02ABFAB@UKWPIPXMB01A.zone1.scb.net> Message-ID: I have also written my thoughts on the questions posed by Richard on the wiki page. On Wed, Oct 28, 2015 at 7:07 AM, Richard Eisenberg wrote: > > On Oct 28, 2015, at 10:02 AM, "Augustsson, Lennart" < > Lennart.Augustsson at sc.com> wrote: > > > I've put in my answers to your questions. > > And I've responded. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fryguybob at gmail.com Wed Oct 28 20:28:10 2015 From: fryguybob at gmail.com (Ryan Yates) Date: Wed, 28 Oct 2015 16:28:10 -0400 Subject: Temporarily pinning a thread to a capability In-Reply-To: References: Message-ID: A thread with TSO_LOCKED can be migrated if the number of capabilities decreases. Ryan On Tue, Oct 27, 2015 at 11:35 PM, Edward Kmett wrote: > Would anything go wrong with a thread id if I pinned it to a capability > after the fact? > > I could in theory do so just by setting > > tso->flags |= TSO_LOCKED > > and then disabling this later by restoring the TSO flags. > > I can't think of anything but I figured folks here might be able to think > of invariants I don't know about. > > Usage scenario: > > I have a number of things where I can't afford a map from a ThreadId# or > even its internal id to a per-thread value for bounded wait-free > structures. > > On the other hand, I can afford one entry per capability and to make a > handful of primitives that can't be preempted, letting me use normal > writes, not even a CAS, to update the capability-local variable in a > primitive (indexing into an array of size based on the number of > capabilities). This lets me bound the amount of "helpers" to consider by > the capability count rather than the potentially much larger and much more > variable number of live threads. > > However, I may need to access this stuff in "pure" code that wasn't > written with my needs in mind, so I need to at least temporarily pin the > current thread to a fixed capability for the duration when that happens. > > This isn't perfect, it won't react to a growing number of capabilities > nicely in the future, but it does handle a lot of things I can't do now at > all without downgrading to lock-free and starving a lot of computations, so > I'm hoping the answer is "it all works". =) > > -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 ekmett at gmail.com Wed Oct 28 20:43:49 2015 From: ekmett at gmail.com (Edward Kmett) Date: Wed, 28 Oct 2015 16:43:49 -0400 Subject: Temporarily pinning a thread to a capability In-Reply-To: References: Message-ID: If the number of capabilities is increased or decreased while everything I have here is running I'm going to have to blow up the world anyways. Basically I'll need to rely on an invariant that setNumCapabilities is called before you spin up these Par-like computations. -Edward On Wed, Oct 28, 2015 at 4:28 PM, Ryan Yates wrote: > A thread with TSO_LOCKED can be migrated if the number of capabilities > decreases. > > Ryan > > On Tue, Oct 27, 2015 at 11:35 PM, Edward Kmett wrote: > >> Would anything go wrong with a thread id if I pinned it to a capability >> after the fact? >> >> I could in theory do so just by setting >> >> tso->flags |= TSO_LOCKED >> >> and then disabling this later by restoring the TSO flags. >> >> I can't think of anything but I figured folks here might be able to think >> of invariants I don't know about. >> >> Usage scenario: >> >> I have a number of things where I can't afford a map from a ThreadId# or >> even its internal id to a per-thread value for bounded wait-free >> structures. >> >> On the other hand, I can afford one entry per capability and to make a >> handful of primitives that can't be preempted, letting me use normal >> writes, not even a CAS, to update the capability-local variable in a >> primitive (indexing into an array of size based on the number of >> capabilities). This lets me bound the amount of "helpers" to consider by >> the capability count rather than the potentially much larger and much more >> variable number of live threads. >> >> However, I may need to access this stuff in "pure" code that wasn't >> written with my needs in mind, so I need to at least temporarily pin the >> current thread to a fixed capability for the duration when that happens. >> >> This isn't perfect, it won't react to a growing number of capabilities >> nicely in the future, but it does handle a lot of things I can't do now at >> all without downgrading to lock-free and starving a lot of computations, so >> I'm hoping the answer is "it all works". =) >> >> -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 fryguybob at gmail.com Wed Oct 28 20:49:54 2015 From: fryguybob at gmail.com (Ryan Yates) Date: Wed, 28 Oct 2015 16:49:54 -0400 Subject: Temporarily pinning a thread to a capability In-Reply-To: References: Message-ID: I figured as much :D On Wed, Oct 28, 2015 at 4:43 PM, Edward Kmett wrote: > If the number of capabilities is increased or decreased while everything I > have here is running I'm going to have to blow up the world anyways. > > Basically I'll need to rely on an invariant that setNumCapabilities is > called before you spin up these Par-like computations. > > -Edward > > On Wed, Oct 28, 2015 at 4:28 PM, Ryan Yates wrote: > >> A thread with TSO_LOCKED can be migrated if the number of capabilities >> decreases. >> >> Ryan >> >> On Tue, Oct 27, 2015 at 11:35 PM, Edward Kmett wrote: >> >>> Would anything go wrong with a thread id if I pinned it to a capability >>> after the fact? >>> >>> I could in theory do so just by setting >>> >>> tso->flags |= TSO_LOCKED >>> >>> and then disabling this later by restoring the TSO flags. >>> >>> I can't think of anything but I figured folks here might be able to >>> think of invariants I don't know about. >>> >>> Usage scenario: >>> >>> I have a number of things where I can't afford a map from a ThreadId# or >>> even its internal id to a per-thread value for bounded wait-free >>> structures. >>> >>> On the other hand, I can afford one entry per capability and to make a >>> handful of primitives that can't be preempted, letting me use normal >>> writes, not even a CAS, to update the capability-local variable in a >>> primitive (indexing into an array of size based on the number of >>> capabilities). This lets me bound the amount of "helpers" to consider by >>> the capability count rather than the potentially much larger and much more >>> variable number of live threads. >>> >>> However, I may need to access this stuff in "pure" code that wasn't >>> written with my needs in mind, so I need to at least temporarily pin the >>> current thread to a fixed capability for the duration when that happens. >>> >>> This isn't perfect, it won't react to a growing number of capabilities >>> nicely in the future, but it does handle a lot of things I can't do now at >>> all without downgrading to lock-free and starving a lot of computations, so >>> I'm hoping the answer is "it all works". =) >>> >>> -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 nikita at karetnikov.org Wed Oct 28 21:30:56 2015 From: nikita at karetnikov.org (Nikita Karetnikov) Date: Thu, 29 Oct 2015 00:30:56 +0300 Subject: Proposal: accept pull requests on GitHub In-Reply-To: <55E60DAD.503@nh2.me> ("Niklas \=\?utf-8\?Q\?Hamb\=C3\=BCchen\=22's\?\= message of "Tue, 01 Sep 2015 22:42:21 +0200") References: <55E60DAD.503@nh2.me> Message-ID: <874mha65pr.fsf@karetnikov.org> > I would recommend against moving code reviews to Github. > I like it and use it all the time for my own projects, but for a large > project like GHC, its code reviews are too basic (comments get lost in > multi-round reviews), and its customisation an process enforcement is > too weak; but that has all been mentioned already on the > https://ghc.haskell.org/trac/ghc/wiki/WhyNotGitHub page you linked. At least you're able to submit comments! I just had my second interaction with arc/phab and I have to say that I really hate both now. The former is not flexible enough and lacks documentation, the latter is just plain confusing. I was trying to update an existing phab diff (D1334), but I had no idea what would be submitted, and I'm still not sure whether I did that okay or not. Oh, slyfox tells me that I overwrote my previous changes, nice! In the process, I also created a new revision by mistake. The web UI didn't help either since there's so much stuff: diffs, revisions, ids. Is it okay to have multiple diffs in a single phab differential after updating? No idea. After that I was struggling to reply to rwbarton. I hit "Done" and added my comment, but both things were marked as "Unsubmitted" (or something). After a while I decided to click on the button at the bottom of the page. Looks like it did the trick, but I have no idea whether it's the right way or not. Not that I'm saying that GitHub is perfect, but at least it works instead of messing up with the work I carefully tested. From marlowsd at gmail.com Wed Oct 28 23:40:39 2015 From: marlowsd at gmail.com (Simon Marlow) Date: Wed, 28 Oct 2015 19:40:39 -0400 Subject: Temporarily pinning a thread to a capability In-Reply-To: References: Message-ID: <56315CF7.9070301@gmail.com> If you don't mind threads moving around between calls to your primitives, this should be ok. Cheers, Simon On 27/10/2015 23:35, Edward Kmett wrote: > Would anything go wrong with a thread id if I pinned it to a capability > after the fact? > > I could in theory do so just by setting > > tso->flags |= TSO_LOCKED > > and then disabling this later by restoring the TSO flags. > > I can't think of anything but I figured folks here might be able to > think of invariants I don't know about. > > Usage scenario: > > I have a number of things where I can't afford a map from a ThreadId# or > even its internal id to a per-thread value for bounded wait-free > structures. > > On the other hand, I can afford one entry per capability and to make a > handful of primitives that can't be preempted, letting me use normal > writes, not even a CAS, to update the capability-local variable in a > primitive (indexing into an array of size based on the number of > capabilities). This lets me bound the amount of "helpers" to consider by > the capability count rather than the potentially much larger and much > more variable number of live threads. > > However, I may need to access this stuff in "pure" code that wasn't > written with my needs in mind, so I need to at least temporarily pin the > current thread to a fixed capability for the duration when that happens. > > This isn't perfect, it won't react to a growing number of capabilities > nicely in the future, but it does handle a lot of things I can't do now > at all without downgrading to lock-free and starving a lot of > computations, so I'm hoping the answer is "it all works". =) > > -Edward From simonpj at microsoft.com Thu Oct 29 11:10:33 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 29 Oct 2015 11:10:33 +0000 Subject: Compiling without -O Message-ID: <51929bd0607445c0be01f18e475f5c62@DB4PR30MB030.064d.mgd.msft.net> I want to validate, but to compile my stage-1 compiler with -O0. How do I do that? I used to add GhcStage1HcOpts += -DDEBUG -O0 to mk/validate.mk, but that doesn't seem to work any more. What now? Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Oct 29 12:03:35 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 29 Oct 2015 12:03:35 +0000 Subject: Documenting record pattern synonyms Message-ID: <5f5e775368904dd384a29d9e964def55@DB4PR30MB030.064d.mgd.msft.net> Matthew: Could you please write the user-manual sections that you have promised? That is, the *specification* this feature. Currently, so far as I can see, there is literally NO user manual documentation. No changes to docs/users_guide whatsoever. We have discussed this on several occasions, and you agreed to do it. I sat with you in person and showed you what I have in mind. There is a sketch on the wiki page. I did not intend this patch to land until the user documentation was done. Now I feel as if I've lost my leverage :-). But it really really really really needs doing. Please. I'm begging you. Compared to what you have already done, it's easy. Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf Of | git at git.haskell.org | Sent: 29 October 2015 11:25 | To: ghc-commits at haskell.org | Subject: [commit: ghc] master: Record pattern synonyms (2a74a64) | | Repository : ssh://git at git.haskell.org/ghc | | On branch : master | Link : | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fghc.haskell. | org%2ftrac%2fghc%2fchangeset%2f2a74a64e8329ab9e0c74bec47198cb492d25affb%2fgh | c&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c0deecf24e85641ff3abb08d2 | e05387f2%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=nEAgwVmvFQNgN%2bANGD4H | z1flN%2fucKSRFoZMdhRqQKSM%3d | | >--------------------------------------------------------------- | | commit 2a74a64e8329ab9e0c74bec47198cb492d25affb | Author: Matthew Pickering | Date: Mon Oct 19 21:17:29 2015 +0100 | | Record pattern synonyms | | This patch implements an extension to pattern synonyms which allows user | to specify pattern synonyms using record syntax. Doing so generates | appropriate selectors and update functions. | | === Interaction with Duplicate Record Fields === | | The implementation given here isn't quite as general as it could be with | respect to the recently-introduced `DuplicateRecordFields` extension. | | Consider the following module: | | {-# LANGUAGE DuplicateRecordFields #-} | {-# LANGUAGE PatternSynonyms #-} | | module Main where | | pattern S{a, b} = (a, b) | pattern T{a} = Just a | | main = do | print S{ a = "fst", b = "snd" } | print T{ a = "a" } | | In principle, this ought to work, because there is no ambiguity. But at | the moment it leads to a "multiple declarations of a" error. The problem | is that pattern synonym record selectors don't do the same name mangling | as normal datatypes when DuplicateRecordFields is enabled. They could, | but this would require some work to track the field label and selector | name separately. | | In particular, we currently represent datatype selectors in the third | component of AvailTC, but pattern synonym selectors are just represented | as Avails (because they don't have a corresponding type constructor). | Moreover, the GlobalRdrElt for a selector currently requires it to have | a parent tycon. | | (example due to Adam Gundry) | | === Updating Explicitly Bidirectional Pattern Synonyms === | | Consider the following | | ``` | pattern Silly{a} <- [a] where | Silly a = [a, a] | | f1 = a [5] -- 5 | | f2 = [5] {a = 6} -- currently [6,6] | ``` | | === Fixing Polymorphic Updates === | | They were fixed by adding these two lines in `dsExpr`. This might break | record updates but will be easy to fix. | | ``` | + ; let req_wrap = mkWpTyApps (mkTyVarTys univ_tvs) | | - , pat_wrap = idHsWrapper } | +, pat_wrap = req_wrap } | ``` | | === Mixed selectors error === | | Note [Mixed Record Field Updates] | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | | Consider the following pattern synonym. | | data MyRec = MyRec { foo :: Int, qux :: String } | | pattern HisRec{f1, f2} = MyRec{foo = f1, qux=f2} | | This allows updates such as the following | | updater :: MyRec -> MyRec | updater a = a {f1 = 1 } | | It would also make sense to allow the following update (which we | reject). | | updater a = a {f1 = 1, qux = "two" } ==? MyRec 1 "two" | | This leads to confusing behaviour when the selectors in fact refer the | same field. | | updater a = a {f1 = 1, foo = 2} ==? ??? | | For this reason, we reject a mixture of pattern synonym and normal | record selectors in the same update block. Although of course we still | allow the following. | | updater a = (a {f1 = 1}) {foo = 2} | | > updater (MyRec 0 "str") | MyRec 2 "str" | | | >--------------------------------------------------------------- | | 2a74a64e8329ab9e0c74bec47198cb492d25affb | compiler/basicTypes/ConLike.hs | 86 +++++++- | compiler/basicTypes/ConLike.hs-boot | 18 ++ | compiler/basicTypes/Id.hs | 31 ++- | compiler/basicTypes/IdInfo.hs | 21 +- | compiler/basicTypes/PatSyn.hs | 51 +++-- | compiler/deSugar/Coverage.hs | 11 +- | compiler/deSugar/DsExpr.hs | 79 ++++--- | compiler/deSugar/DsMeta.hs | 2 +- | compiler/hsSyn/Convert.hs | 10 +- | compiler/hsSyn/HsBinds.hs | 67 +++++- | compiler/hsSyn/HsExpr.hs | 35 +++- | compiler/hsSyn/HsUtils.hs | 21 +- | compiler/hsSyn/PlaceHolder.hs | 6 +- | compiler/iface/BuildTyCl.hs | 7 +- | compiler/iface/IfaceSyn.hs | 17 +- | compiler/iface/MkIface.hs | 11 +- | compiler/iface/TcIface.hs | 12 +- | compiler/main/HscTypes.hs | 15 +- | compiler/parser/Parser.y | 28 ++- | compiler/parser/RdrHsSyn.hs | 2 +- | compiler/prelude/TysWiredIn.hs | 2 +- | compiler/rename/RnBinds.hs | 18 +- | compiler/rename/RnExpr.hs | 8 +- | compiler/rename/RnNames.hs | 30 +-- | compiler/rename/RnSource.hs | 52 ++++- | compiler/typecheck/TcBinds.hs | 6 +- | compiler/typecheck/TcExpr.hs | 231 +++++++++++++++--- | --- | compiler/typecheck/TcHsSyn.hs | 10 +- | compiler/typecheck/TcPat.hs | 6 +- | compiler/typecheck/TcPatSyn.hs | 124 ++++++++--- | compiler/typecheck/TcPatSyn.hs-boot | 8 +- | compiler/typecheck/TcRnDriver.hs | 3 +- | compiler/typecheck/TcTyClsDecls.hs | 39 ++-- | compiler/types/TyCon.hs | 7 +- | compiler/types/TypeRep.hs | 2 +- | compiler/types/TypeRep.hs-boot | 1 + | testsuite/tests/patsyn/should_compile/all.T | 7 +- | .../tests/patsyn/should_compile/records-compile.hs | 11 + | .../tests/patsyn/should_compile/records-poly.hs | 16 ++ | .../patsyn/should_compile/records-prov-req.hs | 26 +++ | .../patsyn/should_compile/records-req-only.hs | 16 ++ | .../tests/patsyn/should_compile/records-req.hs | 14 ++ | testsuite/tests/patsyn/should_fail/all.T | 7 + | .../should_fail/mixed-pat-syn-record-sels.hs | 9 + | .../should_fail/mixed-pat-syn-record-sels.stderr | 5 + | .../tests/patsyn/should_fail/records-check-sels.hs | 10 + | .../patsyn/should_fail/records-check-sels.stderr | 3 + | .../tests/patsyn/should_fail/records-exquant.hs | 10 + | .../patsyn/should_fail/records-exquant.stderr | 11 + | .../patsyn/should_fail/records-mixing-fields.hs | 12 ++ | .../should_fail/records-mixing-fields.stderr | 17 ++ | .../patsyn/should_fail/records-no-uni-update.hs | 7 + | .../should_fail/records-no-uni-update.stderr | 5 + | .../patsyn/should_fail/records-no-uni-update2.hs | 11 + | .../should_fail/records-no-uni-update2.stderr | 5 + | .../patsyn/should_fail/records-poly-update.hs | 13 ++ | .../patsyn/should_fail/records-poly-update.stderr | 5 + | testsuite/tests/patsyn/should_run/all.T | 1 + | testsuite/tests/patsyn/should_run/records-run.hs | 14 ++ | .../tests/patsyn/should_run/records-run.stdout | 5 + | 60 files changed, 1055 insertions(+), 262 deletions(-) | | Diff suppressed because of size. To see it, use: | | git diff-tree --root --patch-with-stat --no-color --find-copies-harder - | -ignore-space-at-eol --cc 2a74a64e8329ab9e0c74bec47198cb492d25affb | _______________________________________________ | ghc-commits mailing list | ghc-commits at haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell | .org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | commits&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c0deecf24e85641ff3a | bb08d2e05387f2%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ymzeKEsSAnOhr4QL | ngFKt0e8B84voue20%2bCyMPwWf%2fQ%3d From simonpj at microsoft.com Thu Oct 29 12:04:22 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 29 Oct 2015 12:04:22 +0000 Subject: Compiling without -O In-Reply-To: References: <51929bd0607445c0be01f18e475f5c62@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <016068105803458897a458f31021c374@DB4PR30MB030.064d.mgd.msft.net> I suspect you are trying to run 'make 1' after a validate failure, and those settings don't get applied. I have put https://phabricator.haskell.org/D1383 up for review to bring 'mk/are-validating.mk' back, which should fix that. Correct! I can?t wait ? Simon From: Thomas Miedema [mailto:thomasmiedema at gmail.com] Sent: 29 October 2015 11:43 To: Simon Peyton Jones Subject: Re: Compiling without -O validate uses options from mk/validate.mk as always. Nothing should have changed there. You say it doesn't work anymore. How do you know? I suspect you are trying to run 'make 1' after a validate failure, and those settings don't get applied. I have put https://phabricator.haskell.org/D1383 up for review to bring 'mk/are-validating.mk' back, which should fix that. On Thu, Oct 29, 2015 at 12:10 PM, Simon Peyton Jones > wrote: I want to validate, but to compile my stage-1 compiler with ?O0. How do I do that? I used to add GhcStage1HcOpts += -DDEBUG -O0 to mk/validate.mk, but that doesn?t seem to work any more. What now? 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 thomasmiedema at gmail.com Thu Oct 29 12:36:00 2015 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Thu, 29 Oct 2015 13:36:00 +0100 Subject: Compiling without -O In-Reply-To: <016068105803458897a458f31021c374@DB4PR30MB030.064d.mgd.msft.net> References: <51929bd0607445c0be01f18e475f5c62@DB4PR30MB030.064d.mgd.msft.net> <016068105803458897a458f31021c374@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Simon, things should be back to normal, after a 'git pull'. Thomas On Thu, Oct 29, 2015 at 1:04 PM, Simon Peyton Jones wrote: > I suspect you are trying to run 'make 1' after a validate failure, and > those settings don't get applied. I have put > https://phabricator.haskell.org/D1383 up for review to bring 'mk/ > are-validating.mk > ' > back, which should fix that. > > Correct! > > > > I can?t wait J > > > > Simon > > > > *From:* Thomas Miedema [mailto:thomasmiedema at gmail.com] > *Sent:* 29 October 2015 11:43 > *To:* Simon Peyton Jones > *Subject:* Re: Compiling without -O > > > > validate uses options from mk/validate.mk > > as always. Nothing should have changed there. You say it doesn't work > anymore. How do you know? > > > > I suspect you are trying to run 'make 1' after a validate failure, and > those settings don't get applied. I have put > https://phabricator.haskell.org/D1383 up for review to bring 'mk/ > are-validating.mk > ' > back, which should fix that. > > > > On Thu, Oct 29, 2015 at 12:10 PM, Simon Peyton Jones < > simonpj at microsoft.com> wrote: > > I want to validate, but to compile my stage-1 compiler with ?O0. How do I > do that? > > I used to add > > GhcStage1HcOpts += -DDEBUG -O0 > > to mk/validate.mk > , > but that doesn?t seem to work any more. > > What now? > > 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 matthewtpickering at gmail.com Thu Oct 29 18:56:54 2015 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Thu, 29 Oct 2015 18:56:54 +0000 Subject: Documenting record pattern synonyms In-Reply-To: <5f5e775368904dd384a29d9e964def55@DB4PR30MB030.064d.mgd.msft.net> References: <5f5e775368904dd384a29d9e964def55@DB4PR30MB030.064d.mgd.msft.net> Message-ID: The documentation is in D1325 - https://phabricator.haskell.org/D1325 I added a specification to the wiki page - https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms/RecordPatternSynonyms On Thu, Oct 29, 2015 at 12:03 PM, Simon Peyton Jones wrote: > Matthew: > > Could you please write the user-manual sections that you have promised? That is, the *specification* this feature. > > Currently, so far as I can see, there is literally NO user manual documentation. No changes to docs/users_guide whatsoever. > > We have discussed this on several occasions, and you agreed to do it. I sat with you in person and showed you what I have in mind. There is a sketch on the wiki page. > > I did not intend this patch to land until the user documentation was done. Now I feel as if I've lost my leverage :-). But it really really really really needs doing. > > Please. I'm begging you. Compared to what you have already done, it's easy. > > Simon > > | -----Original Message----- > | From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf Of > | git at git.haskell.org > | Sent: 29 October 2015 11:25 > | To: ghc-commits at haskell.org > | Subject: [commit: ghc] master: Record pattern synonyms (2a74a64) > | > | Repository : ssh://git at git.haskell.org/ghc > | > | On branch : master > | Link : > | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fghc.haskell. > | org%2ftrac%2fghc%2fchangeset%2f2a74a64e8329ab9e0c74bec47198cb492d25affb%2fgh > | c&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c0deecf24e85641ff3abb08d2 > | e05387f2%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=nEAgwVmvFQNgN%2bANGD4H > | z1flN%2fucKSRFoZMdhRqQKSM%3d > | > | >--------------------------------------------------------------- > | > | commit 2a74a64e8329ab9e0c74bec47198cb492d25affb > | Author: Matthew Pickering > | Date: Mon Oct 19 21:17:29 2015 +0100 > | > | Record pattern synonyms > | > | This patch implements an extension to pattern synonyms which allows user > | to specify pattern synonyms using record syntax. Doing so generates > | appropriate selectors and update functions. > | > | === Interaction with Duplicate Record Fields === > | > | The implementation given here isn't quite as general as it could be with > | respect to the recently-introduced `DuplicateRecordFields` extension. > | > | Consider the following module: > | > | {-# LANGUAGE DuplicateRecordFields #-} > | {-# LANGUAGE PatternSynonyms #-} > | > | module Main where > | > | pattern S{a, b} = (a, b) > | pattern T{a} = Just a > | > | main = do > | print S{ a = "fst", b = "snd" } > | print T{ a = "a" } > | > | In principle, this ought to work, because there is no ambiguity. But at > | the moment it leads to a "multiple declarations of a" error. The problem > | is that pattern synonym record selectors don't do the same name mangling > | as normal datatypes when DuplicateRecordFields is enabled. They could, > | but this would require some work to track the field label and selector > | name separately. > | > | In particular, we currently represent datatype selectors in the third > | component of AvailTC, but pattern synonym selectors are just represented > | as Avails (because they don't have a corresponding type constructor). > | Moreover, the GlobalRdrElt for a selector currently requires it to have > | a parent tycon. > | > | (example due to Adam Gundry) > | > | === Updating Explicitly Bidirectional Pattern Synonyms === > | > | Consider the following > | > | ``` > | pattern Silly{a} <- [a] where > | Silly a = [a, a] > | > | f1 = a [5] -- 5 > | > | f2 = [5] {a = 6} -- currently [6,6] > | ``` > | > | === Fixing Polymorphic Updates === > | > | They were fixed by adding these two lines in `dsExpr`. This might break > | record updates but will be easy to fix. > | > | ``` > | + ; let req_wrap = mkWpTyApps (mkTyVarTys univ_tvs) > | > | - , pat_wrap = idHsWrapper } > | +, pat_wrap = req_wrap } > | ``` > | > | === Mixed selectors error === > | > | Note [Mixed Record Field Updates] > | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > | > | Consider the following pattern synonym. > | > | data MyRec = MyRec { foo :: Int, qux :: String } > | > | pattern HisRec{f1, f2} = MyRec{foo = f1, qux=f2} > | > | This allows updates such as the following > | > | updater :: MyRec -> MyRec > | updater a = a {f1 = 1 } > | > | It would also make sense to allow the following update (which we > | reject). > | > | updater a = a {f1 = 1, qux = "two" } ==? MyRec 1 "two" > | > | This leads to confusing behaviour when the selectors in fact refer the > | same field. > | > | updater a = a {f1 = 1, foo = 2} ==? ??? > | > | For this reason, we reject a mixture of pattern synonym and normal > | record selectors in the same update block. Although of course we still > | allow the following. > | > | updater a = (a {f1 = 1}) {foo = 2} > | > | > updater (MyRec 0 "str") > | MyRec 2 "str" > | > | > | >--------------------------------------------------------------- > | > | 2a74a64e8329ab9e0c74bec47198cb492d25affb > | compiler/basicTypes/ConLike.hs | 86 +++++++- > | compiler/basicTypes/ConLike.hs-boot | 18 ++ > | compiler/basicTypes/Id.hs | 31 ++- > | compiler/basicTypes/IdInfo.hs | 21 +- > | compiler/basicTypes/PatSyn.hs | 51 +++-- > | compiler/deSugar/Coverage.hs | 11 +- > | compiler/deSugar/DsExpr.hs | 79 ++++--- > | compiler/deSugar/DsMeta.hs | 2 +- > | compiler/hsSyn/Convert.hs | 10 +- > | compiler/hsSyn/HsBinds.hs | 67 +++++- > | compiler/hsSyn/HsExpr.hs | 35 +++- > | compiler/hsSyn/HsUtils.hs | 21 +- > | compiler/hsSyn/PlaceHolder.hs | 6 +- > | compiler/iface/BuildTyCl.hs | 7 +- > | compiler/iface/IfaceSyn.hs | 17 +- > | compiler/iface/MkIface.hs | 11 +- > | compiler/iface/TcIface.hs | 12 +- > | compiler/main/HscTypes.hs | 15 +- > | compiler/parser/Parser.y | 28 ++- > | compiler/parser/RdrHsSyn.hs | 2 +- > | compiler/prelude/TysWiredIn.hs | 2 +- > | compiler/rename/RnBinds.hs | 18 +- > | compiler/rename/RnExpr.hs | 8 +- > | compiler/rename/RnNames.hs | 30 +-- > | compiler/rename/RnSource.hs | 52 ++++- > | compiler/typecheck/TcBinds.hs | 6 +- > | compiler/typecheck/TcExpr.hs | 231 +++++++++++++++--- > | --- > | compiler/typecheck/TcHsSyn.hs | 10 +- > | compiler/typecheck/TcPat.hs | 6 +- > | compiler/typecheck/TcPatSyn.hs | 124 ++++++++--- > | compiler/typecheck/TcPatSyn.hs-boot | 8 +- > | compiler/typecheck/TcRnDriver.hs | 3 +- > | compiler/typecheck/TcTyClsDecls.hs | 39 ++-- > | compiler/types/TyCon.hs | 7 +- > | compiler/types/TypeRep.hs | 2 +- > | compiler/types/TypeRep.hs-boot | 1 + > | testsuite/tests/patsyn/should_compile/all.T | 7 +- > | .../tests/patsyn/should_compile/records-compile.hs | 11 + > | .../tests/patsyn/should_compile/records-poly.hs | 16 ++ > | .../patsyn/should_compile/records-prov-req.hs | 26 +++ > | .../patsyn/should_compile/records-req-only.hs | 16 ++ > | .../tests/patsyn/should_compile/records-req.hs | 14 ++ > | testsuite/tests/patsyn/should_fail/all.T | 7 + > | .../should_fail/mixed-pat-syn-record-sels.hs | 9 + > | .../should_fail/mixed-pat-syn-record-sels.stderr | 5 + > | .../tests/patsyn/should_fail/records-check-sels.hs | 10 + > | .../patsyn/should_fail/records-check-sels.stderr | 3 + > | .../tests/patsyn/should_fail/records-exquant.hs | 10 + > | .../patsyn/should_fail/records-exquant.stderr | 11 + > | .../patsyn/should_fail/records-mixing-fields.hs | 12 ++ > | .../should_fail/records-mixing-fields.stderr | 17 ++ > | .../patsyn/should_fail/records-no-uni-update.hs | 7 + > | .../should_fail/records-no-uni-update.stderr | 5 + > | .../patsyn/should_fail/records-no-uni-update2.hs | 11 + > | .../should_fail/records-no-uni-update2.stderr | 5 + > | .../patsyn/should_fail/records-poly-update.hs | 13 ++ > | .../patsyn/should_fail/records-poly-update.stderr | 5 + > | testsuite/tests/patsyn/should_run/all.T | 1 + > | testsuite/tests/patsyn/should_run/records-run.hs | 14 ++ > | .../tests/patsyn/should_run/records-run.stdout | 5 + > | 60 files changed, 1055 insertions(+), 262 deletions(-) > | > | Diff suppressed because of size. To see it, use: > | > | git diff-tree --root --patch-with-stat --no-color --find-copies-harder - > | -ignore-space-at-eol --cc 2a74a64e8329ab9e0c74bec47198cb492d25affb > | _______________________________________________ > | ghc-commits mailing list > | ghc-commits at haskell.org > | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell > | .org%2fcgi-bin%2fmailman%2flistinfo%2fghc- > | commits&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c0deecf24e85641ff3a > | bb08d2e05387f2%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ymzeKEsSAnOhr4QL > | ngFKt0e8B84voue20%2bCyMPwWf%2fQ%3d From iavor.diatchki at gmail.com Thu Oct 29 20:23:36 2015 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Thu, 29 Oct 2015 13:23:36 -0700 Subject: Type-level error messages In-Reply-To: References: <156b77b4a1a444c7a8d4465d4d941c9d@AM3PR30MB019.064d.mgd.msft.net> <8dd0d26809c543e88c9e2da6f91a8f2d@DB4PR30MB030.064d.mgd.msft.net> <87d1vzw7b9.fsf@smart-cactus.org> <67A9BC36-A272-4D61-8025-216E0ED0241A@cis.upenn.edu> <22B950C955F8AB4196E72698FBD00002D02ABFAB@UKWPIPXMB01A.zone1.scb.net> Message-ID: Hello, I've updated the implementation to match the discussion from this morning. The idea is that `TypeError msd` is a type-family that can never be reduced, similar to `Any`. We don't do anything special in the constraint solver, however when printing errors, if we encounter any constraints of the form: * TypeError msg * TypeError msg ~ Something * Something ~ TypeError msg Then we evaluate `msg` and use it as the error message. This is fairly simple, and appears to work quite well. The implementation is on branch `wip/custom-type-errors` ( https://github.com/ghc/ghc/tree/wip/custom-type-errors). == Arc Difficulties Below === I tried to update the Phabricator patch but failed. This is what I did: 1. arc diff master --update D1236 --head custom-type-errors Exception ERR-CONDUIT-CALL: API Method "differential.creatediff" does not define these parameters: 'arcanistProject'. (Run with `--trace` for a full exception trace.) 2. I thought that maybe I need to update `arcanist`, so I pulled the latest version for git. 3. arc diff master --update D1236 --head custom-type-errors Exception Failed to load class or interface 'PhutilClassMapQuery': the class or interface 'PhutilClassMapQuery' is not defined in the library map for any loaded phutil library. If this symbol was recently added or moved, your library map may be out of date. You can rebuild the map by running 'arc liberate'. For more information, see: http://www.phabricator.com/docs/phabricator/article/libphutil_Libraries_User_Guide.html (Run with `--trace` for a full exception trace.) 4. arc liberate Exception Failed to load class or interface 'PhutilClassMapQuery': the class or interface 'PhutilClassMapQuery' is not defined in the library map for any loaded phutil library. If this symbol was recently added or moved, your library map may be out of date. You can rebuild the map by running 'arc liberate'. For more information, see: http://www.phabricator.com/docs/phabricator/article/libphutil_Libraries_User_Guide.html (Run with `--trace` for a full exception trace.) Any advice on what I am doing wrong? -Iavor On Wed, Oct 28, 2015 at 10:17 AM, Iavor Diatchki wrote: > I have also written my thoughts on the questions posed by Richard on the > wiki page. > > > > > On Wed, Oct 28, 2015 at 7:07 AM, Richard Eisenberg > wrote: > >> >> On Oct 28, 2015, at 10:02 AM, "Augustsson, Lennart" < >> Lennart.Augustsson at sc.com> wrote: >> >> > I've put in my answers to your questions. >> >> And I've responded. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at sandbergericsson.se Thu Oct 29 20:44:43 2015 From: adam at sandbergericsson.se (Adam Sandberg Eriksson) Date: Thu, 29 Oct 2015 21:44:43 +0100 Subject: Type-level error messages In-Reply-To: References: <156b77b4a1a444c7a8d4465d4d941c9d@AM3PR30MB019.064d.mgd.msft.net> <8dd0d26809c543e88c9e2da6f91a8f2d@DB4PR30MB030.064d.mgd.msft.net> <87d1vzw7b9.fsf@smart-cactus.org> <67A9BC36-A272-4D61-8025-216E0ED0241A@cis.upenn.edu> <22B950C955F8AB4196E72698FBD00002D02ABFAB@UKWPIPXMB01A.zone1.scb.net> Message-ID: <1446151483.2129194.424005513.493F7E30@webmail.messagingengine.com> When you pulled the latest version from git did you pull both arcanist and libphutil? I think I saw a similar error when I missed one. Also `arc upgrade` should do the right thing for you (in the future). ~adam On Thu, 29 Oct 2015, at 09:23 PM, Iavor Diatchki wrote: > Hello, > > I've updated the implementation to match the discussion from this > morning.? The idea is that `TypeError msd` is a type-family that can > never be reduced, similar to `Any`.? We don't do anything special in > the constraint solver, however when printing errors, if we encounter > any constraints of the form:? * TypeError msg? * TypeError msg ~ > Something? * Something ~ TypeError msg > > Then we evaluate `msg` and use it as the error message. > > This is fairly simple, and appears to work quite well.? The > implementation is on branch `wip/custom-type-errors` > (https://github.com/ghc/ghc/tree/wip/custom-type-errors). > > > == Arc Difficulties Below === > > I tried to update the Phabricator patch but failed.? This is > what I did: > > 1. arc diff master --update D1236 --head custom-type-errors > > Exception ERR-CONDUIT-CALL: API Method "differential.creatediff" does > not define these parameters: 'arcanistProject'. (Run with `--trace` > for a full exception trace.) > > 2. I thought that maybe I need to update `arcanist`, so I pulled the > latest version for git. > > 3.arc diff master --update D1236 --head custom-type-errors > > Exception Failed to load class or interface 'PhutilClassMapQuery': the > class or interface 'PhutilClassMapQuery' is not defined in the library > map for any loaded phutil library. If this symbol was recently added > or moved, your library map may be out of date. You can rebuild the map > by running 'arc liberate'. For more information, see: > http://www.phabricator.com/docs/phabricator/article/libphutil_Libraries_User_Guide.html > (Run with `--trace` for a full exception trace.) > > 4.arc liberate > > Exception Failed to load class or interface 'PhutilClassMapQuery': the > class or interface 'PhutilClassMapQuery' is not defined in the library > map for any loaded phutil library. If this symbol was recently added > or moved, your library map may be out of date. You can rebuild the map > by running 'arc liberate'. For more information, see: > http://www.phabricator.com/docs/phabricator/article/libphutil_Libraries_User_Guide.html > (Run with `--trace` for a full exception trace.) > > > Any advice on what I am doing wrong? > > -Iavor > > > > > > > > > > > > > > > > > > > > > On Wed, Oct 28, 2015 at 10:17 AM, Iavor Diatchki > wrote: >> I have also written my thoughts on the questions posed by Richard on >> the wiki page. >> >> >> >> >> On Wed, Oct 28, 2015 at 7:07 AM, Richard Eisenberg >> wrote: >>> >>> On Oct 28, 2015, at 10:02 AM, "Augustsson, Lennart" wrote: >>> >>> > I've put in my answers to your questions. >>> >>> And I've responded. > _________________________________________________ > 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 Oct 30 11:15:53 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 30 Oct 2015 11:15:53 +0000 Subject: Documenting record pattern synonyms In-Reply-To: References: <5f5e775368904dd384a29d9e964def55@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Excellent Can I suggest that (as we discussed in person) you look at 3.17.2 of the language specification https://www.haskell.org/onlinereport/haskell2010/haskellch3.html#x8-580003.17 and add new numbered items for pattern synonyms? And ditto 3.17.3. The language there is chosen to be consistent, and at least somewhat precise and unambiguous. If you simply put your stuff in that language and form, as a delta to the existing semantics, that'll go a long way. You can put that in the user manual! By way of an example https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/interactive-evaluation.html#extended-default-rules the "Type defaulting in GHCi" section explains how the rules in the report are changed. Thanks Simon | -----Original Message----- | From: Matthew Pickering [mailto:matthewtpickering at gmail.com] | Sent: 29 October 2015 18:57 | To: Simon Peyton Jones | Cc: ghc-devs at haskell.org | Subject: Re: Documenting record pattern synonyms | | The documentation is in D1325 - https://phabricator.haskell.org/D1325 | | I added a specification to the wiki page - | https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms/RecordPatternSynonyms | | | On Thu, Oct 29, 2015 at 12:03 PM, Simon Peyton Jones | wrote: | > Matthew: | > | > Could you please write the user-manual sections that you have promised? | That is, the *specification* this feature. | > | > Currently, so far as I can see, there is literally NO user manual | documentation. No changes to docs/users_guide whatsoever. | > | > We have discussed this on several occasions, and you agreed to do it. I | sat with you in person and showed you what I have in mind. There is a | sketch on the wiki page. | > | > I did not intend this patch to land until the user documentation was done. | Now I feel as if I've lost my leverage :-). But it really really really | really needs doing. | > | > Please. I'm begging you. Compared to what you have already done, it's | easy. | > | > Simon | > | > | -----Original Message----- | > | From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On | > | Behalf Of git at git.haskell.org | > | Sent: 29 October 2015 11:25 | > | To: ghc-commits at haskell.org | > | Subject: [commit: ghc] master: Record pattern synonyms (2a74a64) | > | | > | Repository : ssh://git at git.haskell.org/ghc | > | | > | On branch : master | > | Link : | > | | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fghc.haskell. | > | | > | org%2ftrac%2fghc%2fchangeset%2f2a74a64e8329ab9e0c74bec47198cb492d25a | > | ffb%2fgh | > | | > | c&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c0deecf24e85641ff | > | 3abb08d2 | > | e05387f2%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=nEAgwVmvFQNgN% | > | 2bANGD4H | > | z1flN%2fucKSRFoZMdhRqQKSM%3d | > | | > | >--------------------------------------------------------------- | > | | > | commit 2a74a64e8329ab9e0c74bec47198cb492d25affb | > | Author: Matthew Pickering | > | Date: Mon Oct 19 21:17:29 2015 +0100 | > | | > | Record pattern synonyms | > | | > | This patch implements an extension to pattern synonyms which allows | user | > | to specify pattern synonyms using record syntax. Doing so generates | > | appropriate selectors and update functions. | > | | > | === Interaction with Duplicate Record Fields === | > | | > | The implementation given here isn't quite as general as it could be | with | > | respect to the recently-introduced `DuplicateRecordFields` | extension. | > | | > | Consider the following module: | > | | > | {-# LANGUAGE DuplicateRecordFields #-} | > | {-# LANGUAGE PatternSynonyms #-} | > | | > | module Main where | > | | > | pattern S{a, b} = (a, b) | > | pattern T{a} = Just a | > | | > | main = do | > | print S{ a = "fst", b = "snd" } | > | print T{ a = "a" } | > | | > | In principle, this ought to work, because there is no ambiguity. | But at | > | the moment it leads to a "multiple declarations of a" error. The | problem | > | is that pattern synonym record selectors don't do the same name | mangling | > | as normal datatypes when DuplicateRecordFields is enabled. They | could, | > | but this would require some work to track the field label and | selector | > | name separately. | > | | > | In particular, we currently represent datatype selectors in the | third | > | component of AvailTC, but pattern synonym selectors are just | represented | > | as Avails (because they don't have a corresponding type | constructor). | > | Moreover, the GlobalRdrElt for a selector currently requires it to | have | > | a parent tycon. | > | | > | (example due to Adam Gundry) | > | | > | === Updating Explicitly Bidirectional Pattern Synonyms === | > | | > | Consider the following | > | | > | ``` | > | pattern Silly{a} <- [a] where | > | Silly a = [a, a] | > | | > | f1 = a [5] -- 5 | > | | > | f2 = [5] {a = 6} -- currently [6,6] | > | ``` | > | | > | === Fixing Polymorphic Updates === | > | | > | They were fixed by adding these two lines in `dsExpr`. This might | break | > | record updates but will be easy to fix. | > | | > | ``` | > | + ; let req_wrap = mkWpTyApps (mkTyVarTys univ_tvs) | > | | > | - , pat_wrap = idHsWrapper } | > | +, pat_wrap = req_wrap } | > | ``` | > | | > | === Mixed selectors error === | > | | > | Note [Mixed Record Field Updates] | > | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | > | | > | Consider the following pattern synonym. | > | | > | data MyRec = MyRec { foo :: Int, qux :: String } | > | | > | pattern HisRec{f1, f2} = MyRec{foo = f1, qux=f2} | > | | > | This allows updates such as the following | > | | > | updater :: MyRec -> MyRec | > | updater a = a {f1 = 1 } | > | | > | It would also make sense to allow the following update (which we | > | reject). | > | | > | updater a = a {f1 = 1, qux = "two" } ==? MyRec 1 "two" | > | | > | This leads to confusing behaviour when the selectors in fact refer | the | > | same field. | > | | > | updater a = a {f1 = 1, foo = 2} ==? ??? | > | | > | For this reason, we reject a mixture of pattern synonym and normal | > | record selectors in the same update block. Although of course we | still | > | allow the following. | > | | > | updater a = (a {f1 = 1}) {foo = 2} | > | | > | > updater (MyRec 0 "str") | > | MyRec 2 "str" | > | | > | | > | >--------------------------------------------------------------- | > | | > | 2a74a64e8329ab9e0c74bec47198cb492d25affb | > | compiler/basicTypes/ConLike.hs | 86 +++++++- | > | compiler/basicTypes/ConLike.hs-boot | 18 ++ | > | compiler/basicTypes/Id.hs | 31 ++- | > | compiler/basicTypes/IdInfo.hs | 21 +- | > | compiler/basicTypes/PatSyn.hs | 51 +++-- | > | compiler/deSugar/Coverage.hs | 11 +- | > | compiler/deSugar/DsExpr.hs | 79 ++++--- | > | compiler/deSugar/DsMeta.hs | 2 +- | > | compiler/hsSyn/Convert.hs | 10 +- | > | compiler/hsSyn/HsBinds.hs | 67 +++++- | > | compiler/hsSyn/HsExpr.hs | 35 +++- | > | compiler/hsSyn/HsUtils.hs | 21 +- | > | compiler/hsSyn/PlaceHolder.hs | 6 +- | > | compiler/iface/BuildTyCl.hs | 7 +- | > | compiler/iface/IfaceSyn.hs | 17 +- | > | compiler/iface/MkIface.hs | 11 +- | > | compiler/iface/TcIface.hs | 12 +- | > | compiler/main/HscTypes.hs | 15 +- | > | compiler/parser/Parser.y | 28 ++- | > | compiler/parser/RdrHsSyn.hs | 2 +- | > | compiler/prelude/TysWiredIn.hs | 2 +- | > | compiler/rename/RnBinds.hs | 18 +- | > | compiler/rename/RnExpr.hs | 8 +- | > | compiler/rename/RnNames.hs | 30 +-- | > | compiler/rename/RnSource.hs | 52 ++++- | > | compiler/typecheck/TcBinds.hs | 6 +- | > | compiler/typecheck/TcExpr.hs | 231 | +++++++++++++++--- | > | --- | > | compiler/typecheck/TcHsSyn.hs | 10 +- | > | compiler/typecheck/TcPat.hs | 6 +- | > | compiler/typecheck/TcPatSyn.hs | 124 ++++++++--- | > | compiler/typecheck/TcPatSyn.hs-boot | 8 +- | > | compiler/typecheck/TcRnDriver.hs | 3 +- | > | compiler/typecheck/TcTyClsDecls.hs | 39 ++-- | > | compiler/types/TyCon.hs | 7 +- | > | compiler/types/TypeRep.hs | 2 +- | > | compiler/types/TypeRep.hs-boot | 1 + | > | testsuite/tests/patsyn/should_compile/all.T | 7 +- | > | .../tests/patsyn/should_compile/records-compile.hs | 11 + | > | .../tests/patsyn/should_compile/records-poly.hs | 16 ++ | > | .../patsyn/should_compile/records-prov-req.hs | 26 +++ | > | .../patsyn/should_compile/records-req-only.hs | 16 ++ | > | .../tests/patsyn/should_compile/records-req.hs | 14 ++ | > | testsuite/tests/patsyn/should_fail/all.T | 7 + | > | .../should_fail/mixed-pat-syn-record-sels.hs | 9 + | > | .../should_fail/mixed-pat-syn-record-sels.stderr | 5 + | > | .../tests/patsyn/should_fail/records-check-sels.hs | 10 + | > | .../patsyn/should_fail/records-check-sels.stderr | 3 + | > | .../tests/patsyn/should_fail/records-exquant.hs | 10 + | > | .../patsyn/should_fail/records-exquant.stderr | 11 + | > | .../patsyn/should_fail/records-mixing-fields.hs | 12 ++ | > | .../should_fail/records-mixing-fields.stderr | 17 ++ | > | .../patsyn/should_fail/records-no-uni-update.hs | 7 + | > | .../should_fail/records-no-uni-update.stderr | 5 + | > | .../patsyn/should_fail/records-no-uni-update2.hs | 11 + | > | .../should_fail/records-no-uni-update2.stderr | 5 + | > | .../patsyn/should_fail/records-poly-update.hs | 13 ++ | > | .../patsyn/should_fail/records-poly-update.stderr | 5 + | > | testsuite/tests/patsyn/should_run/all.T | 1 + | > | testsuite/tests/patsyn/should_run/records-run.hs | 14 ++ | > | .../tests/patsyn/should_run/records-run.stdout | 5 + | > | 60 files changed, 1055 insertions(+), 262 deletions(-) | > | | > | Diff suppressed because of size. To see it, use: | > | | > | git diff-tree --root --patch-with-stat --no-color | > | --find-copies-harder - -ignore-space-at-eol --cc | > | 2a74a64e8329ab9e0c74bec47198cb492d25affb | > | _______________________________________________ | > | ghc-commits mailing list | > | ghc-commits at haskell.org | > | | > | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail | > | .haskell | > | .org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | > | | > | commits&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c0deecf24e8 | > | 5641ff3a | > | bb08d2e05387f2%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ymzeKEsS | > | AnOhr4QL | > | ngFKt0e8B84voue20%2bCyMPwWf%2fQ%3d From hvr at gnu.org Fri Oct 30 22:24:02 2015 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Fri, 30 Oct 2015 23:24:02 +0100 Subject: [commit: ghc] master: Kill redundant import (da58d15) In-Reply-To: <20151030112730.655A13A300@ghc.haskell.org> (git-4Dsf34iY's message of "Fri, 30 Oct 2015 11:27:30 +0000 (UTC)") References: <20151030112730.655A13A300@ghc.haskell.org> Message-ID: <87h9l8ov0d.fsf@gnu.org> originally, http://git.haskell.org/ghc.git/commitdiff/7eb5e29b4a7b6fef55512bc7bf3308e712ca3eba the import looked like this: import qualified HsSyn -- hack as we want to reexport the whole module import HsSyn hiding ((<.>)) so it wasn't redundant back then at least. > commit da58d1517ce9c57514f7b2bd7d444c9e3051a717 > Author: Simon Peyton Jones > Date: Fri Oct 30 09:45:16 2015 +0000 > > Kill redundant import > > I don't really understand this. GHC.hs had: > > module GHC( ..., module HsSyn, ... ) where > import HsSyn > import qualified HsSyn -- hack as we want to reexport the whole module > > GHC now reports the 'import qualified' line as redundant; and it certainly > is, because 'import HsSyn' brings everything into scope qualified *and* > unqualified. I have no idea why the "hack" was necessary before, but > following my refactoring of tcg_used_gres (previous commit), it's reported > as redundant, so I've deleted it. > > I'm making it a separate commit because it seems a bit mysterious and I > wanted to draw attention to it. From dongen at cs.ucc.ie Tue Oct 20 08:34:18 2015 From: dongen at cs.ucc.ie (dongen) Date: Tue, 20 Oct 2015 08:34:18 -0000 Subject: Unsubscribe Message-ID: <20151020084351.GA6206@csmvddesktop> Unsubscribe